How to justify using a scripting language as part of a project

Question

I have a specific project in which I want to use either a scripting language + C, or as an alternative a 100% Java solution.

The program adapts a legacy system for use with other moderns systems.

Basically, I have few choices as to what language I can use. I have C/C++, Java 1.4, and I have also compiled the Lua for this environment.

The program does 'screen scraping' and has to deal with alot of strings. That part of the code is highly variable.

Most of the developers at my company use C, so - my original design was to write some portions in C, and use Lua for the part that dealt with strings and changed freqently. I was told 'You have to justify your use of the scripting language.' So i reworked my design using 100% Java, and was told - Java wont have enough performance. You should do the whole thing in C.

I'm not controlling lasers or doing image processing - just some screen scraping. I still have to provide justification for using anything but C - so what justification can I provide?

Answer 1

Evaluate how much time (time==money$) each solution will take. That should help.

Answer 2

You could hack a prototype in some thing like Perl, Python or other script language and show off how easy and fast it can be done.

Answer 3

You need to justify this in terms of the cost of implementation in C (time/money) vs. the cost in the higher level scripting language. I would put together a couple of examples/scenarios to demonstrate potential savings.

It sounds like you work in quite a conservative environment. Note that people may be concerned at introducing an unknown technology that they don't understand or have experience in. For that reason you may wish to a) introduce something well known and documented b) initially not use any esoteric features. Hopefully you can demonstrate that they can make a return on this and, going forward, pick it up.

Answer 4

The justification (if it's true) is that Java is faster for what you're doing. (Is it? - Like Martin said, try to prototype it in Python and evaluate how long it would take.)

Answer 5

In this case, you could also argument with higher robustness, since string handling in C is cumbersome and frequently leads to programming errors (buffer overflows etc.)

Answer 6

Since:

The program does 'screen scraping' and has to deal with alot of strings

Perl would have probably been the best option, if only you had it as a choice.

Answer 7

The big advantage of an embeded script language is tha ability to examine and modify the data while the program is running.
As for the speed, IMO Lua is the number one choice among game developers and thats because it's fast and light.

(you can embed Lua in no time and you won't even notice it's there ;)

Answer 8

I think the cost angle is probably always going to lose based on the fact that your group has incumbent C expertise, so the savings are offset by the cost of learning a new language.

More compelling for me (as someone who has had to make these trade-offs in the past) would be the flexibility and speed of response to changes. C will have to be compiled and deployed whereas you can drop a new python script into your environment in 10 seconds. If the pages you scrape are changing it seems that your development and deployment environment ought to match that flexibility, and that means a scripting language.

BTW the "Java is slower" argument is only trotted out by people who are stuck in C. It hasn't been true for quite a while, and there are myriad independent test which prove it.

Answer 9

Demonstrate the ease of adding new (or user-customized) by allowing your app to load and run a bit of scriptage at run-time, compared to the normal design-develop-deploy cycle.

Answer 10

My suggestions:

1) Think of a couple string operations you would need to do in the scraping process. Write those up in C and then in Lua. I wrote up examples at one point which were 30-40 lines of C compared with 1-2 of Lua.

2) Try to rapidly prototype some aspect of your system in Lua and then in C to compare and contrast. Only you can determine if this prototyping time would be acceptable to your manager or not.

3) Find a like minded ally (or two or three) in your team to show examples and talking points to. They can help support you if you need to do a design review.

4) Be prepared to accept that while you might have a very good design solution, it might not be right for your organization. Not everyone wants to learn or try something new. If a bunch of 'hostiles' have to use or maintain your project, you could be opening yourself to more trouble than its worth.

Answer 11

Parsing strings, HTML, XML etc is slow, no matter which language you use.

There are plenty of free components for your problem, so tool cost is not an issue.

String parsing and screen scraping is one of those problems where your understanding of the parsing requirements keeps changing and takes a long time to stabilize. Therefore, you need the ability to write screen scraping software, try it, fail, and learn, and you need to be able to do this quickly.

Your best bets in either case would be Perl and Ruby. Perl is legendary for string parsing. Ruby is good too, and it has a screen scraping library such as (scrAPI).

The business justification for Perl or Ruby is low cost (free tools), and greatly reduced development time. Using a scripting language enables you to rapidly make and test changes to your scraping software until you get it right. If you can go from code change to test in 10 minutes with C/C++, you can usually do the same with Perl/Ruby in about a minute. Long-term, that could yield a 50% labour cost saving.

Answer 12

Future expansibility.

If you adopt a scripting language you may expand your project in a future at a much lower cost.

Answer 13

my answer is to google it!

Answer 14

Configuration. Lua was created to be a configuration/data-description language. Your program might function this way as well, with a C core and then configuration via a lua interface. How much you leave configurable is up to you, but it can change with time.