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."
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/
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.
If you say "perl mycode.pl", mycode.pl is still a text file.
If you have file with "#!/bin/perl" at the top it is still a text file if you run it directly.
Doesn't matter how you call it, it is still a text file.
Yes, PERL is a scripting language.
But what if I use py2exe for windows and transform my python program into a windows .exe file? Is python still a scripting language then?
"Piter, too, is dead."
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.
Your CS professor only discussed simple RISC processor where the control signals are hard-wired to be generated directly from the machine instructions. However many modern processors use microcode to translate the machine instructions to actual control signals. This level of translation is what Thomas is talking about.
In the article, van Rossum defines a scripting language as one that lacks compile time checking. Pall includes as part of the definition the fact that in these languages memory management is handled
by the interpreter.
Hobbs refers the interview reader to a whitepaper which defines scripting languages as follows:
"There is a category of programming languages which share the properties of being high-level, dynamically typed and open source. These languages have been referred to in the past by some
as "scripting languages," and by others as "general-purpose programming languages". Neither moniker accurately represents the true strengths of these languages. We propose the term dynamic languages as a compact term which evokes both the technical strengths of the languages and the social strengths of their communities of contributors and users."
One statement that Pall makes is great: "As more programming is done with scripting languages, doing memory management yourself, or implementing yet another LZW-based compression library will be seen as a risky proposition when deadlines approach."
I totally agree with this; given that an interpreter manages memory decently, why reinvent the wheel? It is like building your own spark plugs from scratch when you want to do a tune up on your car.
"Lack of technical competence coupled with the arrogance of power, as usual, leads to no good end."
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.