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."
And twitter.
though JavaScript, Perl, PHP, Python, Ruby, Groovy, and other scripting tools are fast achieving the critical mass necessary to flourish into the future
I didn't read the article, but from the summary I'll assume one of the forces is gravity.
It's too bad it's such a weak force.
Well, back to rejecting software patent applications.
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...)
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.
Ya, once Perl is used in a few more places, it'll have critical mass.
It must have been something you assimilated. . . .
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.
Larry Wall nabbed Python's object system when he created Perl...
Erm, WTF? Perl was released in 1987; Python was 1991.
Don't thank God, thank a doctor!
Most human wars throughout the ages are based on religion. Scary, isn't it?
You think that's scary, you should've seen the camel wars.
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.
From Larry Wall's 2007 State of the Onion:
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,
Hm... I was offtopic to the post I was replying to? Or with the 'camel' reference, which is considered the symbol of the Perl language? Between those two, I managed to stay on topic both to this thread, and the article overall. (Didn't you wonder why the article was tagged with 'camel'?) Bah. Having to explain jokes just ruins the fun of 'em. I either need to learn to tell them better, or we need smarter moderators.
Oh. My. God.
A million grammarians cried out in terror and were suddenly silenced.
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?
"It wasn't until the Europeans discovered Sanskrit in the 18th century until European languages had any formal grammar."
Well, sure... It's only that the first printed greek grammar is from 1453; the first modern grammar, the Spanish one from Nebrija, dates from 1492; the first Italian one, that of Trissino, is from 1529, the Portuguesse one from Fernando de Oliveira is from 1536 and the French one from Louis Meigret was published on 1550.
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!
With the story on Chrome having a 1.5% share earlier today, and Firefox having a 32% share, I don't see how there's a "battle for supremacy"...
Website coming soon.
...it was a mass, and critical. This was one of those "If there is a bug in this program, somebody dies" applications. Granted, almost all of the deaths were maintenance programmers. You know the drill -- a sudden rash of suicides and one horrific industrial accident involving a regexp gone horribly awry.
Help poke pirates in the eyepatch, arr.
I think I've seen it somewhere.
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
PHP is no more like a natural human language than any other programming language. Did you never learn about the Chomsky hierarchy in your computer science classes? All programming languages are formal languages as they are at least regular languages. However it is not known whether human natural languages (or any other conceivably similar natural language) are entirely translatable to any formal language. The two cannot be assumed to be comparable until this can be proven, and as far as linguistics goes we're a long way from being able to even *nonmathematically* describe a single natural language, much less prove compatibility with formal languages. Hell, in linguistics we're not even sure what words even *are*, much less how to completely define the set of them.
As for your other commentary, you're talking complete and unfounded nonsense.
Pestilence, Famine and War.
Low energy nuclear reactions are useless when scripting
She made the willows dance
I've never come across an assembler instruction named "BNE". In x86 its "jne" and in Z80 IIRC its "jr". So save the patronising for someone who didn't do real assembler and keep your dumb made up opcodes to yourself
BNE is used in 6502 assembly. Keep your devilspawn CPUs to yourself.