Slashdot Mirror
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."
seriously, i am trying not to troll here but why would i want to use a language with no strict typing on the server to generate html+js text when i can use lots of great languages with typing that can do that very well and are not scripting languages? o.O
maybe i am missing the point here.
I'm surprised there was no mention of Lua. Besides Javascript, Lua is probably the most widely used scripting language out there. Usually its use is hidden from the end-user but it's in everything from embedded devices to World of Warcraft.
It has a very simple design and is very fast (especially with LuaJIT). The semantics are similar to Javascript but Lua is a lot more pure and simple. There probably will never be a Javascript engine as fast as the fastest Lua engines.
from TFA:
And then there are others who see languages such as JavaScript rising from the browser and colonizing the server. A unified platform makes everything simpler. Yes, Netscape wanted this to happen years ago, but thanks to the lightning performance of the new JavaScript semi-compilers, the language is bound to look even more attractive.
See, MS crushed your dreams too :-)
Also, it can be useful if you write a fairly sophisticated filtering function to make sure that someone doesn't input the wrong answer. You can run it on the client, but it might make sense to run it at the server at other times.
i totally disagree here. i would NEVER run any validation code on the client.
still eager to follow the upcoming comments ^^
rgds from vienna (no, the one in yrp XD)
Well, yes, you can't trust the client. But there's a big advantage if you can run the validation code there before the person runs submit. That saves the load on your server and it makes everything more responsive for the user. (Javascript, no matter how slow, is usually faster than a roundtrip on the Internet.)
But still you can verify on the server too-- another argument for running the same code on the server and the client.
1) So, Perl which came along long before the existence of Python, stole from Python?
Nope, this guy didn't do any research:
Python reached version 1.0 in January 1994
...
Perl 5 was released on October 17, 1994. It was a nearly complete rewrite of the interpreter, and added many new features to the language, including objects,
I sort of agree - but I'd phrase it as "I'd never rely solely on client-side validation".
I get your point, though, and would mod you up if I had points tonight.
Gruss Gott von England :)
One swallow does not a fellatrix make
As someone with a BA in Linguistics, I call BS on the natural language part of your post. The biggest mistake you have made is that you failed to distinguish between written grammar guides, and an actual grammar for a language, which is in each person's head and is quite complete and well-formed. So much so that we have yet to fully elucidate the complexities therein.
I don't think "John and I" is even arguably correct, since "I" is subjective.
Dewey, what part of this looks like authorities should be involved?
So, I read the rest of the article, to see if he got anything else right. Well...
But will PHP be able to shake the casual structure that encourages beginners to whip up spaghetti code? Will it be able to continue to mix the presentation layer and the application layer without driving everyone insane?
It's true that PHP encourages this, and I find it a little disturbing that people are building web frameworks in what is essentially a Turing-complete template language. It would be as if the next big thing was written in PostScript.
But in a larger sense, this isn't nearly as relevant as how you use it. Drupal is proof that you can do good things with PHP.
However, I do prefer to work in a language that helps, rather than hinders, such a design.
Some want to place their bets on Ruby on Rails, a striking and elegant solution that produces sophisticated results in no time.... This simplicity often turns into shackles when the programmers reach the edge of the framework's capabilities. Changing little details or producing slightly unorthodox output can be maddening.
That's downright flamebait.
I suspect that many Rails developers do feel this way, for the same reason that many PHP programs are useless spaghetti code -- as a complete side effect. Since Rails is so easy to get into, it's a rude awakening when you need to do something it doesn't provide -- you're finding out just how much work Rails has done for you.
But seriously, "slightly unorthodox output"? Are you serious? Probably one of the easiest things to do is add another view of the same data -- even in another format.
A programmer gets the rock-solid foundation of compiled Java code mixed with the flexibility to diddle with the Java objects in real time.
Maybe Groovy makes that easier, but Java already had reflection. Next!
thanks to the lightning performance of the new JavaScript semi-compilers, the language is bound to look even more attractive.... The semantic barriers won't be as important as the languages rush to steal good ideas from one and other.... 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.
Interesting ideas. None of which apply to Javascript, now or ever.
You see, Javascript client-side is a nightmare, because you have to make it work in several existing browsers, which don't always play nice with the standards.
And Javascript, the language, is evolving at an incredibly slow pace -- mostly because it's got the worst case of cruft of any language. Add an interesting feature in a browser, and you probably break some client code. Even if you're careful, as a developer, I can't use your feature if it isn't also present in other browsers.
So changing the core syntax of the language is right out. If we were to break backwards compatibility in such a dramatic way, it'd make a lot more sense to port Python to the browser.
In which case, we may as well use Java or Silverlight -- plenty of dynamic languages target these. My personal favorite would probably be JRuby in an applet.
Libraries such as Dojo and jQuery aren't just a set of helpful routines; they actively tweak the language and ask you to adopt a particular set of idioms.
True enough -- except that in the case of jQuery, it actually doesn't force anything. If you really like wasting time, you can write using the old idioms you learned. If you don't like jQuery, you can always rename the $ variable and pretend it doesn't exist.
The focus really should be on the next point, which is actually a good one:
Applications are becoming their own worlds.
Especially in a dynamic language, any body of code of sufficient size is going to have some idioms of its own.
The main reason frameworks are important
Don't thank God, thank a doctor!
A quick skim over the bloody summary shows that this is a "don't read the f-ing article" if there ever was one: "co-optation", "infusion of application development", "fast evolving beyond their traditional purpose", "the cloud", "code enablers".
I use perl daily, python when I need OO, and hack together most time-savers with bash. Like people did before me since the Bourne shell came out in 1977, and the more complicated scripting languages after that. In 30 years, people will probably still be doing the same. The only thing that might change is that more and more programs that are not depending on performance, might be completely written in scripting languages. As far as my work is concerned, the factor 20 or more speedup I get by actually programming in C will always be of use. It's not like we want to do the same with tomorrow's computing capacity as we can do now, we want to do more!
molmod.com - computing tips from a molecular modeling
To be fair to the author, I read his manuscript while it was in progress and this was not his wording. The original reads only that "Larry Wall says he nabbed Python's object model for Perl." Unfortunately, the current wording is an error that was introduced during the edit phase.
Why not?
Why have a round trip back to the server to find the error. Have the client notice it and report it without having the user submit and wait.
Obviously, you do the same check on the server with the standard round trip "you did this bit wrong, please try again" response.
So you would NEVER do that? Seems a strange religious believe to hold.
From the co-optation 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, ...
Honestly, for anyone who actually uses them to solve problems, the benefits of dynamic languages aren't hard to understand: they allow you to code easily and clearly, to debug quickly, and to expand from simple scripts to complex systems. And they're surrounded by supportive developer communities and code libraries.
Just like all the other great geek innovations... we don't need marketing types to notice in order to enjoy our toys :-)
My bicyles
Pestilence, Famine and War.