
In Praise of Scripting: Real Programming Pragmatism - mariorz
http://www.cse.wustl.edu/~loui/praiseieee.html
======
jsomers
Good essay.

I liken the difference between Python and Java to internships at small and
large companies, respectively. In the small company, you can do meaningful
work in any department—you can be the cook, accountant, and network engineer
in the same day, just as you can parse XML, send automated e-mails, and invert
large matrices in Python with plug-and-play modules. At a small company
everything's transparent, and on a scale you can understand; there's no
organization for organization's sake, no vapid meetings or processes, just
problems that need to be solved and the tools you need to solve them.

It is only when the small company grows, when the founders can't interview
every new employee and the clients aren't recognizable by name, when managers
and engineers are disjoint groups, that one needs all the stuff they teach you
at business school. To round out the conceit: the Java curriculum is that
stuff. And to a kid just learning to program, it's cruft.

------
wwalker3
Interesting essay, but it sounds like to the author, programming is merely
glueing together things that someone else has written, or writing a few pages
of code to translate some text from one format to another.

For small-scale projects like that, scripting languages are great. But on
larger projects, the advantages of scripting languages turn into
disadvantages.

For example, say you're writing a short program in Perl that just has to work
right now. If you discover that in some corner case, you need to shove another
data member into one of your objects, you don't have to go back and fix your
object definition -- you can just cram it into an instance and have done with
it.

But large programs are very hard to understand if objects don't have a
coherent identity over time. Scripting languages give you the freedom to "just
make it work now", but they don't give you the ability to make decisions about
your program's inner structure and enforce them. This inner structure is what
makes a large program understandable and maintainable.

~~~
gaius
Python (et al) people have a different mindset to many traditional languages.
If you're into Java then you (probably - the people who develop Java itself
certainly do) think it's important that a language be self-hosting. Python and
Tcl people think that doing the heavy lifting in C (ie. another language) is
perfectly normal. The schism between "scripting" and compiled languages is a
false one.

------
trezor
Not to sound like a bitter C# programmer (formerly Java) not "getting" the
whole fascination with weak typing and scripting languages, but I thought this
piece was pretty much junk. It very much felt like the underdog defending his
position by attacking his perceived opponent. It's full of assertions of
superiority and little to back it up.

It may simply be a matter of taste, but I prefer a strictly typed environment.
Code which can be compiled, and errors which can be caught before a single
line is executed. I _like_ making classes which abstracts the underlying work,
hence improving (local) code readability.

Granted, quite a few of the popular scripting languages does support OOP these
days, but the usage among the hackers out there seem to vary greatly.

Ofcourse, the degree of abstraction _needed_ will vary from problem to
problem. If you can fit your solution into one page of code (like he
mentions), the problem probably isn't that big to begin with. If you are
working on a more complex project, spanning thousands of lines of code, the
benefits touted here seems less credible.

Also, for a guy advocating that the main benefit of so called scripting
languages are that they allow short, concise and straight to the point code:
He might try to transfer that to his writing. That piece was anything but
short, concise or straight to the point.

~~~
anamax
> I like making classes which abstracts the underlying work, hence improving
> (local) code readability.

Where did you get the impression that scripting folks don't do that?

> Code which can be compiled, and errors which can be caught before a single
> line is executed.

I find that most of the errors caught by compilers is in code that I had to
insert to make the compiler happy while I worked on the actual problem. Yes,
it's "just a little effort" to write stubs, but much of that work is wasted
and it has to be done at the wrong time.

It is much better to simply allow missing methods, etc. and trap on use.

