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."
The research firm reports that over 41 percent of the 666 developers surveyed use Perl, 32 percent use PHP, and 15.6 percent use Python
The Number of the Devil of Programmers.. looks like it's as I always said, scripting languages are evil..
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
I have often wondered what makes a particular language a "scripting" language v.s. a "real" language. One thing scripting languages all have in common is that they are interpreted. However Basic is interpreted (even though some may dissagree that it is a "real" language), and there have been interpreted versions of Pascal and others.
The best I can come up with is that a scripting language is an interpreted language that is normally attached to an application in order to allow the end user to automate functions within that app. So for example BASH programming is "scripting" since most of what you do is items that would normally be done at the command line. Same with Word/Excel macros. Also, TCL was designed to be attached to other programs (although the typical use is stand-alone). But I wouldn't put PERL in that catagory, anymore than GW-Basic or interpreted Pascal are scripting languages.
So, what does a language need to be called a "real" language, other than being compiled?
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
This article:
0 0.asp
http://www.devsource.com/article2/0,1759,1778148,
talks about some of the cool stuff that Tcl does. My favorite thing about the language is that it hits a real sweet spot with its level of abstraction. Python has an event loop now, in Twisted, but Tcl's had the same thing for ages, and it's very easy to use.
http://www.welton.it/davidw/
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 have a final project in my computer engineering diploma in which we are trying to monitor and control a few security devices over the web. The focus is about split equally between design of a PCB w/ microcontroller and getting the code written. Since my only formal training was in C, and at first I considered using C for the majority of the programming. However after some research I stumbled upon scripting languages.
The result is that instead of a cumbersome 1000 line C program which would be a huge time sink, I have several small C programs connected with script. I'm using a combination of Bash script, PERL, and Java. I had to learn the basics of each but in the end that was faster and easy to debug. The time I saved went into more hardware hacking and making sure that the electronics portion worked better. In the end it made for a project that was much more fun.
I don't think it's necessarily a question of project size, though, so much as the nature of a project. I have worked on some very large tools for which a scripting language is a much better choice. As far as I am concerned, C is best used when you're working with very large and rapidly changing data sets (C structs will probably always be lighter weight than objects) or you need to crunch a lot of numbers really fast.
I think the way of the future is static languages like C for critical stuff, and dynamic languages like Ruby, Io, or some functional language for most of the program. . . much the way that programs used to be written in C with some inline assembler for the performance-critical stuff.
Yes, but BASH is a manly scripting language, where as...
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
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.
The usual cases are:
But even if you can always rely on one of these solutions, you're missing out on the beauty of statically typed languages: IDEs. By formally typing objects in the language grammar, you have not just documented your code to your peers, but to the machine itself. And allowing the machine to reason about your code means it can help you write it. It keeps you in the code, with instant access to API, documentation, and refactoring. Now you have mentally stepped beyond the code into the problem space.
Anyone who has written Java in a solid IDE like Eclipse can atest to this. I've had I've had people look over my shoulder in amazement as "the computer writes [my] code" for me. Every function appropriate to the context (and their documentation) usually within 6 keystrokes, without memorization.
Even the best Python IDEs (strongly typed, but still dynamically typed) pale in comparison to this experience.
When will the scripting world learn what they're missing?
Anm
(For the record, my prefered langauge is Java, but my current work has me doing C, C++, Python, and Perl as necessary. While I haven't worked in it, I assume C# is in the same boat as Java: statically typed, runtime reflexective, dynamically loadable, useful exceptions/stack traces, and large library including the source compiler itself.)
It's entirely possible that a small number of individual problems is easier to maintain than one large one that does the same thing. In this case, it might be easier to do the coordination between the C programs in $SCRIPTING_LANG than it would be in C, if for no other reason than it might be easier to write and maintain the coordination script in $SCRIPTING_LANG than C. If the C programs do sufficiently small and simple tasks, but the coordination is easier to code in $SCRIPTING_LANG there definitely could be benefits to doing it that way.
Ruby has RubyScript2Exe to collect a script and all dependencies includint the Ruby interpreter into a single Windows .exe file.
.exe.
AllInOneRuby uses the same technique to package the Ruby interpreter and core and standard libraries into a single
I'm not sure if Perl and Python have something similar.
Dan Bernstein is a proponent of this approach, as can be seen by looking at the approach taken in his programs such as Qmail.
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
I think he's referring to the idea of 'microcode'. If you look at older 8 bit CPUs (eg z80, 6809, 6510, etc) - there's a decent link between the bits in the instruction and what the instructions do. Microcode based CPUs, even the 8086/8088, are a little different: each instruction triggers a series of instructions which in turn make the CPU logic do something (latch register X onto databus, add to accumulator, etc..). So, when you execute an instruction on a microcode CPU you're triggering off a series of actions for the CPU to perform. You could replace the instruction set the CPU runs by changing the microcode.
To clarify this post a bit.
You feed a modern processor (assuming x86 compatible) x86 assembly, but internally it executes it's own format of operations. During the fetch/decode stage the x86 operations are "translated" into the internal micro-ops format.
As such one x86 op may correspond to many internal micro-ops. This is done for several reasons, one of the more fundamental being that x86 asm is now a horrible mess that is not suitable to feed into an extremely optimised processor core.
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/
that being said, i love perl for quick stuff, i/o and text processing, and lots of other things. php is great for web and i am definitely interested in looking into python...