In Praise of Scripting: Real Programming Pragmatism
cse.wustl.edu
cse.wustl.edu
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.
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.
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.
For one value of 'better', the better a language is, the wider range of possibilities it will afford you, handling both the quick task and the Big Complex Program well.
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.