Lambda the Ultimate

inactiveTopic Tools for the short hike
started 2/26/2003; 12:32:51 AM - last post 2/26/2003; 2:44:42 PM
Dan Shappir - Tools for the short hike  blueArrow
2/26/2003; 12:32:51 AM (reads: 2138, responses: 24)
Tools for the short hike
Via Slashdot

... there is a level of quiet discomfort between the "scripting" versus "programming" factions in some corporate development environments in which I have participated. In some instances, executive-level technology management has held scripting languages in disdain as not being "real" languages for day-to-day problem solving, which has discouraged highly talented scripters on staff from practicing their craft.

Chad Dickerson seems to make the distinction between "scripters" and "programmers" solely on the basis of language used (programmers = C++, Java ; scripters = Perl, Python). For me, any real distinction can only based on formal training (which could be obtained by autodidaction). A programmer is someone how understands some basic tenants of program design, while a scripter (if you use the derogatory aspect of the term) is someone who just hacks out code.

Given this definition, I would certainly favor a programmer over a scripter, no mater which language either of them used.
Posted to critiques by Dan Shappir on 2/26/03; 12:35:54 AM

Dan Shappir - Re: Tools for the short hike  blueArrow
2/26/2003; 12:41:52 AM (reads: 1625, responses: 1)
Another point not discussed in Chad Dickerson's article is maintainability. Simply punching out the code as quickly as possible, while obviously important, is not the only consideration. Being able to correct bugs, add features and modify behavior is often as important for a project, unless it's just a one-time hack.

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.

Dan Shappir - Re: Tools for the short hike  blueArrow
2/26/2003; 1:00:13 AM (reads: 1618, responses: 0)
The company I work for provides a product which serves as an infrastructure for additional development performed by our own Professional Services group, System Integrators or even the end-customer if he has the proper resources / expertise.

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

Sjoerd Visscher - Re: Tools for the short hike  blueArrow
2/26/2003; 2:27:57 AM (reads: 1606, responses: 0)
I don't agree with your distinction between programmers and scripters. It's the tasks that have either a scripting nature or a programming nature. The difference between a programmer and a scripter is then only which of these tasks someone would prefer.

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

Ehud Lamm - Re: Tools for the short hike  blueArrow
2/26/2003; 2:28:44 AM (reads: 1655, responses: 0)
anybody who selects the wrong tool for the job just because it appears to be "more professional" is just plain unprofessional.

Ehud Lamm - Re: Tools for the short hike  blueArrow
2/26/2003; 2:31:43 AM (reads: 1600, responses: 0)
I find the distinction simplistic, and quite often wrong.

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.

Todd Coram - Re: Tools for the short hike  blueArrow
2/26/2003; 2:40:26 AM (reads: 1600, responses: 1)
There is another class of programmer that uses scripting languages: Those of us who are enamored with higher level programming techniques. You can find a lot of ideas from Lisp, Haskell, Eiffel and others embedded in scripting languages (often as part of the language syntax rather than just external libraries).

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

Todd Coram - Re: Tools for the short hike  blueArrow
2/26/2003; 2:47:29 AM (reads: 1603, responses: 0)
The US Postal Service's Mailing Online (a web service to allow small businesses to upload documents and have them mass printed and mailed) was written in Tcl (with Oracle for storage) from front end (AOLServer webpages) to back end (manipulating postscript/pdf, printing the envelopes, controlling the high speed printer and envelope sorter). A bit of VB was used to manipulate MS Word documents.

The developers were hardly scripters.

Ehud Lamm - Re: Tools for the short hike  blueArrow
2/26/2003; 2:49:26 AM (reads: 1647, responses: 0)
Those of us who are enamored with higher level programming techniques.

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.

Dan Shappir - Re: Tools for the short hike  blueArrow
2/26/2003; 3:02:42 AM (reads: 1576, responses: 1)
To clarify, I should have probably used the terminology hacker vs. programmer rather the scripter vs. programmer. Indeed, if you read my posts you'll see that I disagree with language based distinction, and focus instead on methodology (and lack thereof).

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

Dan Shappir - Re: Tools for the short hike  blueArrow
2/26/2003; 3:04:35 AM (reads: 1581, responses: 0)
OTOH if someone really lacks methodology, I might prefer him/her to use a language that has built-in, automatic, enforced resource management. That is, not C++.

Dan Shappir - Re: Tools for the short hike  blueArrow
2/26/2003; 3:07:35 AM (reads: 1579, responses: 0)
And BTW, I'm a programmer and I love scripting languages.

Ehud Lamm - Re: Tools for the short hike  blueArrow
2/26/2003; 3:31:44 AM (reads: 1627, responses: 0)
It is a fact, however, that some languages force you to focus more on methodology than others.

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.

Luke Gorrie - Re: Tools for the short hike  blueArrow
2/26/2003; 4:41:34 AM (reads: 1553, responses: 0)
Saying "hacker vs. programmer" to distinguish sloppy from good programmers is unlikely to be less controversial :-).

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

Jeff Darcy - Re: Tools for the short hike  blueArrow
2/26/2003; 4:53:32 AM (reads: 1562, responses: 1)
While I mostly agree with the distinction between "programming for the long run" and "quick hacks" (Dan), with a nod toward the distinction between different types of programming tasks (Sjoerd), I think formal education has practically nothing to do with this. To me, the important distinction is that a scripter is someone whose programming universe is defined by the language(s) they use. There are a lot of Perl or VB or even Python programmers who could never write a device driver, because you can't do that in those languages. A JavaScript or PHP programmer might even be limited to stuff that runs on the web, and have trouble even writing a standalone application. A real programmer, on the other hand, can move between all of these different tasks and more, changing languages as they go because they don't see the world through language-colored glasses any more.

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.

Daniel Marlay - Re: Tools for the short hike  blueArrow
2/26/2003; 4:55:25 AM (reads: 1561, responses: 0)
As has been mentioned earlier, I'm not sure that the distinction of languages into "scripting" and "programming" is actually all that useful.

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.

Dan Shappir - Re: Tools for the short hike  blueArrow
2/26/2003; 7:35:39 AM (reads: 1528, responses: 1)
I believe that the distinction between "scripting" and "programming", as it is to be inferred from Chad Dickerson's article is more one of perception than anything else:

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.

Ehud Lamm - Re: Tools for the short hike  blueArrow
2/26/2003; 7:55:23 AM (reads: 1556, responses: 0)
It seems that we have a consensus that the distinction between "scripting" and "programming" is inadequate.

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

Ehud Lamm - Re: Tools for the short hike  blueArrow
2/26/2003; 8:06:44 AM (reads: 1557, responses: 0)
To me, the important distinction is that a scripter is someone whose programming universe is defined by the language(s) they use.

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.

Isaac Gouy - Re: Tools for the short hike  blueArrow
2/26/2003; 8:39:39 AM (reads: 1493, responses: 2)
Why are we stuck with simplistic slogans?
scripting vs programming !
real programmers!

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.

Ehud Lamm - Re: Tools for the short hike  blueArrow
2/26/2003; 9:36:15 AM (reads: 1529, responses: 0)
Let's try to remain civil, shall we.

This sort of post is not welcome here.

Isaac Gouy - Re: Tools for the short hike  blueArrow
2/26/2003; 10:09:32 AM (reads: 1438, responses: 0)
simplistic slogans
I am sorry if that seems offensive.
I intended it as a challenge: we repeatedly choose dichotomy instead of grappling with complexity. I believe we have to do better.

Ehud Lamm - Re: Tools for the short hike  blueArrow
2/26/2003; 1:25:01 PM (reads: 1451, responses: 0)
Ousterhout's paper is not new. It is interesting, but the analysis isn't very deep. Many arguments against its logic were raised.

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

Dominic Fox - Re: Tools for the short hike  blueArrow
2/26/2003; 2:21:48 PM (reads: 1374, responses: 0)
If I want to make an application "scriptable", I construct and expose an API which another language can interface with. For the purposes of the user of this API, that language is a scripting language, even if it is also used in other contexts to build applications which might themselves be scriptable in other languages.

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

Jeff Darcy - Re: Tools for the short hike  blueArrow
2/26/2003; 2:44:42 PM (reads: 1357, responses: 0)
Well put, Dominic. There might be more of a useful distinction between "scripting" and "programming" (activities) than between "scripting language" and "programming language" (things). In that context a "scripter" might be considered someone who engages - or is only capable of engaging - in scripting, and not the more inclusive/difficult task of programming, as opposed to someone who uses a so-called "scripting language". People can script in a programming language (e.g. customizing an app in Scheme) and program in a scripting language (e.g. a full-fledged application in Python).

I like it.