Lambda the Ultimate

By their very design, some script languages allow, even encourage, a programming style that can result in very hard to maintain code (Perl).

OTOH anybody who selects the wrong tool for the job just because it appears to be "more professional" is plain stupid.

Whenever I learn that the System Integrator or customer is using C++, I automatically become very afraid. I much prefer them to use a "scripting" language (ASP, JSP, VB, Perl, Python, even Java is better in this context than C++).

In all cases where C++ was used there were problems. Code snippets we received (in order to help track down problems in "your shoddy product") invariably contained lots of resource management bugs, copy and paste programming, and simply very bad code (and I’ve yet to encounter one who used STL).

I started out as a scripter, because I liked the quick automation boosts scripts can give you. As you grow more experienced, larger longer lived projects become more interesting, and I see myself more as a programmer than a scripter now.

As a result, I now find myself looking for more correctness checking than the scripting languages offer. However, Java and C++ only offer typing, for which correctness checking is more a side effect than a goal, and that's not what I'm looking for...

It also tends to focus the debate on ad hominem arguments.

I've met scripters, and people who coded in ultra-simple DSLs, that had amazing programmer intuition.

Some later moved on to study CS, and proved their keen isight in more traditional ways.

I could hardly write a better (general purpose) I/O library than the one in Tcl. And Python's class mechanism is flexible enough that I can concentrate on modelling the domain (not mapping the domain to the idiosyncracies of Java's class mechanism). I am not sure why Ruby and Python aren't considered general purpose programming languages.

Let us not forget that many of the language features in Perl, Python, Tcl, Ruby and others are time (and industry) tested C code that I rather not duplicate effort in developing for my projects.

I spend most of my programming day building mission critical software in scripting languages (dropping down to C/C++ only when speed is needed).

The developers were hardly scripters.

This raises an important point, that I wanted to address, seeing as this is a programming languages weblog...

It is quite wrong to assume the so called scripting languages are simple or trivial languages. In fact, the opposite is more often the case.

Many of these languages provide semantically rich language constructs, that are not directly available in more traditional ("3rd generation") languages. To add to the list already given think about real reflection and introspection support.

In fact, a related problem is that in some cases these constructs are implemented before we have the appropriate theory to analyze them.

It is a fact, however, that some languages force you to focus more on methodology than others. Scripting languages do sometime play fast and loose. That might be a great thing if you have the built-in checks and measures, otherwise ...

When giving out a task to a programmer, I would grant him the use of any language, provided he can explain his/her reasoning (in most cases I find they prefer to stick with the languages they know. And given the time constraints of the real world, I often let them do it).

This another matter altogether. There are language fatures that are important for Software-Eng, and not all programming languages support them equaly.

This Desing By Contract, think types (oh my god, not that again), think module systems (information hiding etc.)

Perl (a scripting language) has a built in module system; Scheme doesn't.

Obligatory Jargon File reference: http://www.science.uva.nl/~mes/jargon/h/hacker.html

This leads to a couple of controversial points. One is that Lisp-colored glasses are just as bad as VB-colored glasses, if they limit the kinds of programming tasks one can perform. The other is that some exposure, sometime, to one of the "difficult" languages - i.e. the ones without built-in resource management and higher-order data types - might actually be a necessary step on the way to programmerdom. I've never met someone who, once exposed to C or assembler, had any trouble at all picking up Python; I've met quite a few who have failed to make the reverse transition. Sometimes you have to experience the pain of doing something the hard way before you can truly appreciate the value of tools that let you do it an easier way.

For instance, if one is going to call perl a scripting language and scheme a programming language, where are the features that allow you identify the difference? Both languages are typically run in an interpreted / bytecode compiled format, both can be compiled to native code (or compiled to C and thence to a native executable), perl has most of the constructs that Scheme has.

Maybe it's a scripting language if it has a weak[1] typing system / a single type that holds numbers and strings and automatically. But then one has languages like C where the difference between a small integer and a character isn't all that well enforced.

Someone on the slashdot discussion suggested that a scripting language was one that had some form of "eval" function, but that would mean that we'd classify languages like scheme, smalltalk and CL as scripting languages.

Anyway, that's my two cents (and my first post to LtU)

[1] I'm not sure that I'm using the right terminology here.

Perl, Python and obviously JavaScript are perceived as scripting languages, while C++ and Java are "real" programming languages (I'd be surprised if Chad Dickerson actually encountered Lisp being used commercially be one of those companies.)

If I had to define some sort of distinction between scripting and non-scripting languages it would be amount of language overhead required to perform a task. For example, in C:

#include <stdio.h>

int main()
{
printf("hello world");
}

while in JavaScript:

alert("hello world");

If you think about it, the whole dynamic typing vs. static typing to a great extent plays to this issue as well.

One of my hardest mindset changes as a (very) young programmer was from Basic, which had very little overhead, to Pascal, which has a lot.

Each poster has, of course, his own opinion on what distinction we should talk about next...

That's a good point, and I agree.

Even programmers that are fluent in several languages, are often tied in their thinking habits.

That's why your argument, though correct in general, falls short when you talk about Scheme (as in "Lisp-colored glasses"). Scheme, beacuse it offers simplicity that is coupled with rich expressiveness, alows you to become aware of your own programming style and techniques, and start thinking more clearly about the language as an abstraction mechanism. That's where the power of SICP comes from.

If the experts on LtU are unable to invent programming language categories that are actually useful when choosing a language for a task, how can we expect managers and magazine commentators to do any better?

I am not sure why Ruby and Python aren't considered general purpose programming languages
Let me suggest one explanation - we don't have a cool phrase for "general purpose programming language", it just doesn't sound HOT!

"there are many interesting languages that can't be characterized cleanly as a system programming language or a scripting language"
Scripting: Higher Level Programming for the 21st Century
We need some good phrases for those many interesting languages.

a scripter is someone whose programming universe is defined by the language(s) they use
It seems to me that, many of us allow ourselves to be defined by our experience - someone who has only written device-drivers has a lot to learn before they could be effective writing dhtml, and vice versa. And that's fine.
The problems arise when we generalize beyond our experience and expertise.

This sort of post is not welcome here.

The paper was mentioned here a number of times in the past.

For instance, you can use Scheme - via Guile - to script the behaviour of programs written in C, but Scheme is hardly limited to this kind of usage. I'm not sure that the same can be said of PHP.

In this kind of context, scripting means using an interface that is supplied by some other application. If you build more than a layer or two up from that interface, you're probably going beyond scripting; after all, anything but the most low-level systems programming will involve building on existing layers of functionality. But a scripter will write code that sits fairly flatly on top of other code, and isn't really intended to support further layers above them. Programmers use cranes to build bigger cranes; scripters have less lofty ambitions (and a lot of the time, that's just fine).

I like it.