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

[abigor]

I take it by "strict typing" you mean static typing? What's so great about it? Lots of server-side languages and frameworks (Python/Django, for example) are dynamically typed. I guess I'm not gettting what your point is here.

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.

this guy didn't do any research

[Anonymous Coward]

From the article:
"Larry Wall nabbed Python's object system when he created Perl, and he and his acolytes are committed to making sure that there are many ways to do anything you want to do in Perl."

1) So, Perl which came along long before the existence of Python, stole from Python? Hilarious.

Also from the article:
"Language committees are always debating how to weld a great idea from another language into the current one, and this will continue to happen. In five years, there's a good chance you'll be able to imagine you're writing Python while the code is interpreted by something called JavaScript."

2) Just what we need, to run Python on a slower JavaScript interpreter. Python has won several benchmarks as the #1 fastest (even more than Perl, sorry to say), with JavaScript engines being the slowest interpreters around.

Did this guy even research scripted languages before he wrote this terrible article?

Computer languages evolve like natural languages

[Anik315]

Languages such as PHP will always be more popular than languages such as Ruby, not because the former is any easier to learn or better designed, but because almost purely becuase PHP is much more like a natural human language, with all its flaws, than a language like Ruby. Most of the time you are scripting, you are hacking strings together and it doesn't really help if they are objects are not. I imagine that given the choice between a highly structured language and one that is at its core, hacked together, people will always choose the latter. It wasn't until the Europeans discovered Sanskrit in the 18th century until European languages had any formal grammar. If I were going to pick a "Highlander" for scripting languages, it would be JavaScript because it's highly structured and also very functional.

Re:Computer languages evolve like natural language

[Anonymous Coward]

European (and all) languages have always had a clear grammar, and formalizing them (i.e, "this is the one and only one correct form of $FOO in language $BAR") didn't change a thing.

Ironically, some amazing B.S. got put into English because of 'formal grammars.' People saying 'They met John and I' rather than the more natural and arguably more correct 'John and me,' or people complaining about split infinitives and prepositions at the end of sentences (avoiding both of which becomes unwieldy in complex sentences)