Slashdot Log In
10 Forces Guiding the Future of Scripting
Posted by
ScuttleMonkey
on Mon Oct 13, 2008 05:31 PM
from the blur-the-line dept.
from the blur-the-line dept.
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."
Related Stories
[+]
The State of Scripting Languages 415 comments
Esther Schindler writes to tell us that Lynn Greiner has another look at the state of the scripting universe as a follow on to the same topic three years ago. Greiner talks to major players from each of the main scripting languages (PHP, Perl, Tcl, Python, Ruby, and Javascript) to find out the current status and where they are headed in the future. "The biggest change since 2005 has been the growth of richer Web applications that perform more of their computations in the browser using JavaScript. The demand for these applications has forced developers to learn and use JavaScript much more than before. There's also been a lot of interest in Ruby, another dynamic language, spurred by the release and growth of Ruby on Rails. As a result of these changes, many developers are becoming more comfortable with dynamic languages."
[+]
Generic VMs Key To Future of Coding 139 comments
snydeq writes "Fatal Exception's Neil McAllister calls for generic VMs divorced from the syntactic details of specific languages in order to provide developers with some much-needed flexibility in the years ahead: 'Imagine being able to program in the language of your choice and then choose from any of several different underlying engines to execute your code, depending upon the needs of your application.' This 'next major stage in the evolution of programming' is already under way, he writes, citing Jim Hugunin's work with Python on the CLR, Microsoft's forthcoming Dynamic Language Runtime, Jython, Sun's Da Vinci Machine, and the long-delayed Perl/Python Parrot. And with modern JITs capable of outputting machine code almost as efficient as hand-coded C, the idea of running code through a truly generic VM may be yet another key factor that will shape the future of scripting."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Don't forget synergy... (Score:5, Funny)
And twitter.
Holy moly, that's a lot of buzzwords (Score:5, Insightful)
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 :-)
Parent
10 forces? (Score:5, Funny)
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.
Re: (Score:2, Informative)
A quick skim over the article reveals that these ten "forces" are just some common platitudes. The article itself is not that meaningful.
Re:10 forces? (Score:4, Informative)
It was a perfectly good joke, until you came and spoiled it!
Parent
Re:10 forces? (Score:5, Insightful)
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!
Parent
Re: (Score:3)
Are you sure about that factor of 20? Have you measured it in any real cases lately?
"C is always faster" is something of a myth. You need to be a pretty good C programmer to beat the perl-porters.
Fast javascript (Score:5, Interesting)
Re: (Score:2, Informative)
http://en.wikipedia.org/wiki/Server-side_JavaScript [wikipedia.org]
I don't know if any of those are good, but it's a start.
Re: (Score:2, Insightful)
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.
Re: (Score:2, Insightful)
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 :-)
Re: (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:4, Insightful)
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)
Parent
Re:Fast javascript (Score:5, Insightful)
But still you can verify on the server too-- another argument for running the same code on the server and the client.
Parent
Re:Fast javascript (Score:5, Insightful)
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 :)
Parent
Re: (Score:2)
I would run validation code on the client but .... the caveat is that its not as good or reliable validation that you will still do on the server. Think of it as filtering the truly bad input at source, the server still has to do the validation proper.
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.
Parent
Re: (Score:2)
i totally disagree here. i would NEVER run any validation code on the client.
Are you joking? I can't tell, but I think you should be ;)
Re:Fast javascript (Score:4, Insightful)
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.
Parent
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.
Parent
Re: (Score:2)
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 too, would like to write server side code in the same language as the client side code... I just wish it would be the client side that would change. That way I wouldn't have to touch javascript ever again.
Re:Fast javascript (Score:4, Funny)
Now, now, now, there's nothing wrong with JavaScript that smoking a little crack while severely hung over can't fix.... :-D
But seriously, client-side PHP would totally rock. Or heck, I'd settle for a universal bytecode runtime standard that we could compile Perl, PHP, Python, Ruby, etc. into for execution on any client. Kind of like Java, but without... you know, Java....
Parent
Re: (Score:3, Informative)
Ruby on Rails' RJS templates is exactly that. You write Ruby that is translated into Javascript calls. I've written a number of Javascript-driven Ruby on Rails apps without ever having written a single line of actual Javascript. You get a "page" object which represents the DOM, simple as can be.
http://www.google.com/search?q=rjs+templates [google.com]
Re: (Score:3, Informative)
Rhino [mozilla.org]
Attila Szegedi [szegedi.org]
Re:Fast javascript (Score:5, Informative)
The safari javascript engine is called SquirrelFish (And there's also SquirrelFish Extreme, which compiles javascript into machine code, with predictable speed increases.) and it is open-source as it's part of webkit.
http://webkit.org/ [webkit.org]
Parent
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.
Re: (Score:3, Funny)
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.
All... most... there... (Score:5, Funny)
Ya, once Perl is used in a few more places, it'll have critical mass.
Re: (Score:2)
Maybe De Beers could help?
Having had to wade through 100k lines of it... (Score:3, Funny)
...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.
Pure scripting: Lua (Score:5, Insightful)
I'm surprised there was no mention of Lua [lua.org]. 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.
Clueless. (Score:5, Informative)
Larry Wall nabbed Python's object system when he created Perl...
Erm, WTF? Perl was released in 1987; Python was 1991.
Re:Clueless. (Score:5, Informative)
Parent
Re:Clueless. (Score:5, Informative)
'I assume they mean some flavor of Perl 5, since the Perl didn't have objects prior to Perl 5. And Perl 5 released several years after Python.'
Indeed. According to Larry:
'After Tcl came Python, which in Guido's mind was inspired positively by ABC, but in the Python community's mind was inspired negatively by Perl. I'm not terribly qualified to talk about Python however. I don't really know much about Python. I only stole its object system for Perl 5. I have since repented.'
Parent
Re:Clueless. (Score:4, Funny)
perl history [wikipedia.org]
Parent
Still Clueless (Score:5, Insightful)
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
Parent
Re: (Score:3, Insightful)
I'm rooting for whatever to "win" that isn't brain damaged (not that any of the languages mentioned are)
I would say that all of them are, to a certain degree.
Most languages that aren't purely functional are also not trivially multicore. Of Ruby, Python, and Perl, only JRuby actually allows threads that can actually take advantage of multicore, and none of them have particularly elegant structures around threading. And most, I would think, would be very difficult to make work as well as Erlang does, because they have mutable data structures.
Of the languages that do, well, Haskell makes my head hurt -- maybe th
Computer languages evolve like natural languages (Score:2, Interesting)
Re:Computer languages evolve like natural language (Score:4, Insightful)
Parent
Re:Computer languages evolve like natural language (Score:5, Informative)
"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.
Parent
Re: (Score:3, Informative)
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: (Score:3, Insightful)
I don't think "John and I" is even arguably correct, since "I" is subjective.
"Co-optation"?? (Score:5, Funny)
Oh. My. God.
A million grammarians cried out in terror and were suddenly silenced.
Re:Religion (Score:5, Funny)
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.
Parent
Re: (Score:2, Funny)
Re:this guy didn't do any research (Score:4, Informative)
From Larry Wall's 2007 State of the Onion: [perl.com]
Parent
Re: (Score:2, Insightful)
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,
Re:the inevitability of an uber-scripting language (Score:4, Informative)
Parent
Re:Malda (Score:4, Insightful)
Pestilence, Famine and War.
Parent
Re:coldfusion (Score:4, Funny)
Parent