in the meantime, a couple of answers to comments.

Mike: “I think it’s not the language that makes the software disposable, but rather the design/architecture that is commonly used when building ’scripting applications’ builds in disposability”

i think that’s mostly true, but i do think language has something to do with it. if we think of languages as a spectrum, and using for the sake of argument abstraction as a means of judging them, there is a clear progression. c is more abstract that assembler, java is more abstract than c, php/ruby/VB/etc are more abstract than java. as such, i do think there are indeed differences in a languages suitability to creating disposable applications. as an extreme example, i can tell you that the odds of me creating a one off app in assembler are pretty much zero (not that i could any more anyway).

Christopher: “Stephen’s argument isn’t reflexive. PHP is good for disposable software AND enterprise software, but Java is only good for enterprise software.”

i don’t know that i’d be that hard and fast about it - i’ve been on projects where Java apps were cranked out to solve a particular need - but you’re correct. that’s more or less what i’m saying.

“> We need less quick and dirty, and more quick and clean.

I love that.”

i agree. it’s one of the reasons that i find some of the new web frameworks so intriguing. not because they’re the solution to all problems, but rather because they are not. instead, they take a narrow spectrum of application types and make the development of a solution quick and (mostly) clean.

“The problem with disposable software is it isn’t disposed soon enough.”

partially agree. i’d merely add that in my experience, disposable software is often the result of earlier mistakes in design and execution. otherwise, i agree.

Stephen’s argument isn’t reflexive. PHP is good for disposable software AND enterprise software, but Java is only good for enterprise software.

> We need less quick and dirty, and more quick and clean.

I love that.

The problem with disposable software is it isn’t disposed soon enough.

What I think doesn’t fit with your argument are the Yahoo, Google, (insert big Fortune X company I’m not allowed to name) etc that actually built “enterprise applications” on PHP, Python, etc. I don’t think Yahoo Finance is “disposable software” for Yahoo. Often components are disposable, but the application is not. Which gets me to my particular thought after reading your post - is it that the software is disposable or just that the componentized architecture of PHP, Python, Ruby, heck open source applications lends better to “disposability” - even with the simples, small apps. I think it’s not the language that makes the software disposable, but rather the design/architecture that is commonly used when building “scripting applications” builds in disposability… that’s why my PHP3 app is still in use today (prob updated to PHP4 by now) - pieces of it were easily disposable/upgradeable - even though the software application as a whole is just as important today as it was 6 yrs ago.

We need less quick and dirty, and more quick and clean. Terms like extreme programming terrify me, but then maybe that is because Im just an enterprisey user…

Now that i have commented, I suppose I should listen to the podcast….!)

am i to understand that neither of you really sees any disparities between languages in terms of productivity and speed? in other words, given a quick and dirty job, it’s just as easy to knock it out in C++ or Java as it would be in, say, Perl or PHP - assuming equal language facility? there’s no delta in development speed? if so, i can’t really agree with that. there have been reasons over the course of my career that i had to develop in things like C, COBOL, or even - shudder - Assembler, but i would never try to argue that i could develop as quickly in those languages as i could with some of the more recent developments. hell, even compared to ASP - not ASP.Net - Ruby’s significantly quicker for me.

recent (and yes, often dynamic) languages abstract more from a development perspective, and while this does not come without cost it does allow for improvements in productivity.

does this mean that quick and dirty jobs cannot be done in things like C++ or Java? absolutely not. just that in my experience it’s far easier to do what Ryan describes above as disposable applications in something else. that’s also what i hear from a significant majority of the developers i speak with.

in other words, while i would never make the argument that language dictates life expectancy or longevity with high precision, neither do i think they’re unrelated.

to christopher’s question, here’s a different way of answering it that might be clearer. in an enterprise of a more recent vintage than the example i cited in the original entry, it’s likely that the EDI, inventory and other applications would be written in Java and housed within an application server of some sort. it’s equally likely that the local application with a GUI and a database would either be written in VB.NET (the one i actually built was actually an Access DB with some fancy macros, i’m ashamed to admit) or built as an online application (b/c availability is better today than it was at the time) using PHP, Ruby or something similar.

now could this ‘enterprise’ have built the local application in Java, and the EDI, etc apps in .NET or PHP/Python/Ruby? certainly.

but i’d contend that those use cases would be more atypical than not. and productivity - i.e. the time it takes me to churn out the local application in Java vs an alternative would be a factor. tooling might mitigate that to a certain extent, as the success of VB proved, but not completely.

does that answer the question better?

What am I missing? Is this the right interpretation of the post?

I’m sorry to keep coming back to this quote, but do you mean intranet web apps, command line apps, or external web apps?

Don’t get me wrong, I think there is a lot of genius in Python, but I don’t think I approach python apps that much differently than I do C++ or Java apps. Sometimes my python and C++ apps are one in the same.

I totally agree that there is value in the quick and dirty and vendors should support that paradigm, but I don’t necesarily see that tied to tool selection. The Unix command ‘tail’ for instance is a tiny app written in C, but it could have been written in any language.

where we might beg to differ is on the .NET v PHP, Ruby, et al bit. as mentioned above, .NET technologies are certainly a big part of that conversation, but i see an awful lot of PHP, Python and so on employed as well.

i’m not discounting the presence of .NET, and certainly not the rampant success of VB years ago, but neither would i discount the growing popularity of some of the so-called scripting languages. different tools for different jobs, as they say.

I’d say that the one off, short term type of work that you describe is not being done in PHP or Ruby, but .NET which has replaced VB. This has more to do with .NET tools and third party support than the static/dynamic nature of the language.