Jon Udell notes that a Scripting Language lets you "ship the Proto Type". In a world of distributed services in constant flux, when does exploration stop? Why would you ever want to switch from a codebase that is concise, malleable, and easily maintainable to one that isn't?... My point is that languages like PyThon, but also PeRl, Ruby, and Java Script/[JScript]/[Action Script]/[Ecma Script], are strategic in ways that we don't yet fully acknowledge. As I mentioned last time, the classic phased life cycle of software development - design/develop/test/deploy - is dissolving into a continuous process. Change is the only constant; the services we create and use are always exploratory. Languages that express programmers' intentions in fewer lines of code are a huge productivity win. The deliverable code is easier to understand and maintain - and so, crucially, is the test infrastructure that supports it.

Jon also specifically mentions ZoPe. Jeffrey P Shell concurs . Considering the architectural implementation, the requirements, the short time frame, and the very large possibility for expansion if the project in question actually gets used, I could not imagine doing what I just did in anything but PyThon, and with any Application Server but ZoPe. Fundamentally, I could have gone with the servlet based WebWare and delivered the same business objects, but I would have been on my own when it came to persistence, security, and user management... While the mode of development (at least, on project's that I maintain) vary from project to project, it's quite something to be able to show a milestone release instead of a prototype and be able to respond to changes in a timely manner; instead of showing the prototype, getting feedback, and using that feedback to make the "real project". In the last six years, especially, I have never seen one "throw-away prototype" (encouraged by some development processes) actually get thrown away.

User Options Recent Changes Help Page