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.
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."
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."
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.