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