10 Forces Guiding the Future of Scripting

snydeq writes "InfoWorld examines the platforms and passions underlying today's popular dynamic languages, and though JavaScript, Perl, PHP, Python, Ruby, Groovy, and other scripting tools are fast achieving the critical mass necessary to flourish into the future, 10 forces in particular appear to be driving the evolution of this development domain. From the cooption of successful ideas across languages, to the infusion of application development into applications that are fast evolving beyond their traditional purpose, to the rise of frameworks, the cloud, and amateur code enablers, each will have a profound effect on the future of today's dynamic development tools."

Comments

Fast javascript

[cornicefire]

Does anyone know of a project to bring some of the fast Javascript implementations like V8 to the server? It could be like PHP or Perl, only very fast-- if the numbers hold out. I would like to write in the same language on the client and the server. (Java almost achieved that...)

Re:Fast javascript

[Cyberax]

Java HAS achieved that. See Google Web Toolkit - it compiles Java to _JavaScript_ which is executed inside your browser.

IMHO, it's THE best toolkit for rich AJAX applications now.

Re:Fast javascript

[ushering05401]

Everyone here is assuming persistent connectivity.

Client apps should always be written with the ability to dress, validate, and temporarily persist data before attempting to transmit, then the server should double check everything. Rejecting data on the server side, while necessary to prevent malicious injections, will always cost bandwidth or worse - it costs time if the client cannot reconnect for a set period to respond to results of server side validation.

Even if you don't care about bandwidth, reducing the need for client side modifications after the initial submit just seems wise.

If you are clever you might even omit a few key rules from your client side validation, leave an opening. Analyze any input that trips those rules on the server side for an ad-hoc Honeypot/Canary-in-the-Coal-Mine.

hey ho.

[apodyopsis]

I write embedded firmware for my job (predominantly C) - my code is tied to the hardware, I frequently code real-time stuff in assembler to get the maximum speed. I have no OS, and I write all the ISRs and schedulers myself.

On the other end of the spectrum is a friend of mine who is language and platform agnostic. Sways between a bunch of scripting languages on a number of operating systems and has probably never compiled an application in his life, interpreters are his tools.

My point - if there is one - is that each to their own, there will always be a requirement for different skill sets. In a way, software is software regardless of the language it is coded in. The same rules apply.

I love doing clever stuff with pointers (except when it goes wrong in style), and using neat mathematical tricks in assembler to speed up fixed divisions and run stuff faster - but as the same time when knocking up a test rig on a PC I can honestly appreciate stuff like a "foreach".

Hey ho. Ramble Ramble.