10 Forces Guiding the Future of Scripting 190
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."
Fast javascript (Score:5, Interesting)
hey ho. (Score:5, Interesting)
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 (Score:0, Interesting)
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?
Re:Fast javascript (Score:5, Interesting)
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.
Computer languages evolve like natural languages (Score:2, Interesting)
Re:Computer languages evolve like natural language (Score:1, Interesting)
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)
Re:Fast javascript (Score:3, Interesting)
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 (Score:5, Interesting)
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.