Slashdot Mirror
The State of the Scripting Universe
r.jimenezz writes "Via PragDave's blog I learned of an article by Lynn Greiner on the state of scripting languages, a.k.a. scripting dynamic languages. A number of influential personalities (Guido von Rossum, Damien Conway, PragDave himself and others) were interviewed and it's interesting to see how much their opinions coincide despite being interviewed separately. A lengthy but worthwhile reading."
Scripting languages will always have a place , Its a simple case of the right tool for the job. .If i do have a larger project that requires a bit more power then i can prototype it in perl or shell then easily transcribe it to C .
As a sysadmin most of my Programming is done in either ruby(im difrent) , shell(bash or ksh) or perl. Using C for most of the things i have to automate is as i said "Taking a sledge hammer to a penut" , It would be total overkill and waste my time and the systems and it would be more error prone
Scripting will always be an important part of my work , and with the increasing power and decresing price of computer equipment over the last few years , it has become viable to program many many things in languages such as python , things which would not so long ago, would have requierd the power of C/++.
Scripting is in a fine state , and will continue to fill its end of the market , just as compiled languages will always have their place
The only things certain in war are Propaganda and Death. You can never be sure which is which though
I'm not trying to be a wise-ass. I'm sincere here. Maybe a ratified standard by some authority is what sets COBOL, BASIC, and Ada apart from their more agile scripting counterparts, whether or not a compiler or interpreter implimentation exists.
Method of processing duck feet
For projects below a certain complexity level, I've always found scripting languages to be more productive for the programmer (very fast edit-run-debug cycles) even if they are less efficient for the CPU. And with the advent of JIT compilers, the efficiency of scripting is much improved.
Given the low-cost of fast CPUs and high-cost of programmers, I'd rather waste CPU cycles than waste developer labor.
Two wrongs don't make a right, but three lefts do.
I must say that this is the correct way to think about it , If it works and it works well then why switch to C for the job.
"Right tool for the job" is an important motif for efficent workmanship
The only things certain in war are Propaganda and Death. You can never be sure which is which though
I would consider any programming language directly run from a text file a scripting language.
Then what about interpreted Basic or Pascal? Both of these can be run the same way. Keep in mind I'm refering to the language, not the implimentation. :-)
Of course, some will argue that Basic is a scripting language (or not a language at all), but I won't go there
Also, even though Pascal is usually compiled, it used to exist primarily as an interpreted language.
I do agree that Perl is a scripting language, I just can't figure out why (since a perl script doesn't interact "control" another program), whereas a shell sciprt is a script because it is attached to and controls another program (the shell). Yet a Pascal or Basic program isn't a script even if it is run through an interpreter (although some dialects of Basic are scripts simply because of the primary purpose of the dialect, i.e. VB scripts atached to Excel macros).
You notice that all popular scripting languages are cross platform? Maybe, just maybe, that's why nobody wants to look at yours.
Are you talking about a BASIC program run with MS BASICA or something? That is a text file and a therefore a script.
Let's assume you are talking about Visual Basic. Yes, like Java, Visual Basic requires a runtime engine to execute. However, C++ and C require calls to the operating system. Try running a C++ program without an operating system and see how well it works. So in reality all progamming languages really require an "interperter" to execute. Maybe OS kernel code is the only real stand alone code.
>Lets say you have to added a feature to the following function:
>
> updateCustomerAccount( customer, newInfo )
>
>Looks nice, with very descriptive function name and parameters. But it isn't. Is customer a string name, a an accountId, or a data structure? Does it return anything (success or failure code)? And a little more debatable, does it throw any errors.
Ah. is customer an object? is the new info an object?
is it smart-merging "newInfo" to "customer"?
I can come up with a bunch of things that might affect how one uses this function that would not be infomationalized by the addition of types:
is it accessing an outside system, such as a database?
is it asynch?
Does it assume security of the user? In the Customer update log, what is the name of the person who entered the newInfo?
Is the newInfo an xml document with inbedded base64 pdf? (i've seen in, in mortgage systems)
Does it notify a third-party in case of failure, logging to the logger, and returning a "pending verification" semi-error code?
Does it allow for customer to be empty, and if so, does it create a new customer?
Does it allow either to be empty, thereby creating a new customer with blank, or default information?
if the newInfo contains a dataset with as-yet unknown fields, is the system desinged to automatically add the fields as xml tags in the customer xml storage?
Is the previous information in the customer file store elsewhere? as in a change log?
All functions need a solid API. Since you're going to have an API, you might as well put the type handling in it.
If a programmer can't be bothered to keep the API docs updated, he is not staying on my team.
To some questions, the answer is Python.
"Piter, too, is dead."
IMHO, all languages should be 'scripted' as well as 'compiled'. The same language syntax can be both. Why not use our advanced computational tools to do the grunt work of optimizing functionality? We've automated every other engineering discipline, but can't seem to do that for our own. (I know I'm overstating the argument, handwaving and idealizing - it's a dirty job, but somebody's gotta do it.)
What I'd like to see: As I enter code in the language, the system does syntax checking and builds the necessary data structures, prompting and possible asking questions about ambiguities and any necessary library functions either not found or not called correctly. In fact, this process might as well be graphical in nature - NeXTstep's Interface Builder perhaps came closest to this in my experience. The code should be runnable immediately, in an interpreted environment - a la Perl/Python/PHP etc.
Thus language processing system would act as an intelligent assistant, looking over the system as I design and build it and making suggestions. It might even make performance predictions based on its analysis of the code-so-far.
Once the functionality is complete, I can pass the system to an even smarter optimizing compiler function, which does the necessary things to make it efficient, small, fast, etc. In the process the compiler may ask more questions about how to resolve various issues that didn't come up earlier. Since the functionality is already defined, the compilation has a mostly-known target for functionality. This process can take as long as necessary, perhaps while I go home for dinner; using more heuristics, AI, whatever, to further improve and clean up the system for the defined functionality.
Except for the AI features, this combined capability is actually old. Back in the Long Ago, Harris computers ran the Vulcan OS, which had a n interactive FORTRAN system. It did line-by-line compiling, doing syntax checking on each line and even running the code. Once your program was complete and ran, the interactive compiler could output correctly-formatted FORTRAN that could be compiled using the standard FORTRAN compiler.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
This is cool, the article author just eliminated one very commonly used scripting language by require it to be open source : Visual Basic.
Many widely used Microsoft applications has a scripting interface via Automation, and guess what, you can use Visual Basic for this! In general this works very well, actually, to well considering the number of scripting viruses. But as a scripting language with a common interface to other applications, it's very good.