Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

10 Forces Guiding the Future of Scripting

ScuttleMonkey posted about 6 years ago | from the blur-the-line dept.

Perl 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."

Sorry! There are no comments related to the filter you selected.

Don't forget synergy... (5, Funny)

Anonymous Coward | about 6 years ago | (#25362333)

And twitter.

Holy moly, that's a lot of buzzwords (4, Insightful)

MoxFulder (159829) | about 6 years ago | (#25364763)

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 :-)

10 forces? (5, Funny)

CaptainPatent (1087643) | about 6 years ago | (#25362351)

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:10 forces? (2, Informative)

Anonymous Coward | about 6 years ago | (#25362409)

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? (3, Informative)

fm6 (162816) | about 6 years ago | (#25362727)

It was a perfectly good joke, until you came and spoiled it!

Re:10 forces? (0)

Anonymous Coward | about 6 years ago | (#25363203)

No, your joke was a bomb. Critical mass refers the mass of a fissionable material required to achieve criticality, i.e., self-sustaining chain reaction. It has nothing (well - very little) to do with gravity.

Re:10 forces? (1, Funny)

Profane MuthaFucka (574406) | about 6 years ago | (#25363447)

Confucius Say "Man who nitpick physics joke not fine man.

Re:10 forces? (4, Insightful)

pimpimpim (811140) | about 6 years ago | (#25363999)

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!

Re:10 forces? (1, Flamebait)

DiegoBravo (324012) | about 6 years ago | (#25364331)

Sadly I agree; from the article:

BEGIN-ARTICLE-EXCERPT
Rob Malda, one of the founders of Slashdot, says that he chose Perl for... ...All languages can handle the obvious things nice enough now."

... This is a nice, politically neutral statement, but it doesn't solve the problem that in many shops, there must be only one Highlander. Only a kindergarten teacher would smile and say that all are equally good.
END-OF-EXCERPT
(bold mine)

The writer comes from that group of people that argues that X is the best programming language, because "obviously" there must be a best programing language for whatever reason. Maybe editors should return to Kindergarten before submitting this kind of "article".

Re:10 forces? (0)

Anonymous Coward | about 6 years ago | (#25362485)

Hah. There's no gravity, life on earth just sucks.

Only ONE script matters --THE BIBLE (-1, Troll)

Anonymous Coward | about 6 years ago | (#25362353)

This is what it would be like, if the majority of people were atheists
ATHIEST KID: Mom, I'm going to go fuck a hooker.
ATHIEST MOM: Okay, son.
ATHIEST KID: Afterwards, I'm going to go smoke pot with my friends, since it's "not addictive."
ATHIEST MOM: Okay, come home soon!

The atheist kid leaves the room. The father comes home from work several minutes later.

ATHIEST DAD: Hey!
ATHIEST MOM: Hi, honey! I'm pregnant again. I guess I'll just get another abortion, since "fetuses don't count as human life."
ATHIEST DAD: Okay, get as many abortions as you want!
ATHIEST MOM: Oh, and don't go in the bedroom.
ATHIEST DAD: Why not?
ATHIEST MOM: There are two gay men fucking each other in there.
ATHIEST DAD: Why are they here?
ACHIEST MOM: I wanted to watch them do it for awhile. They just aren't finished yet.
ATHEIST DAD: Okay, that's fine with me!

Suddenly, their neighbor runs into the house.

ATHEIST NEIGHBOR: Come quick, there's a Christian outside!
ATHEIST MOM: We'll be right there!

The atheist couple quickly put on a pair of black robes and hoods. They then exit the house, and run into the street, where a Christian is nailed to a large, wooden X. He is being burned alive. A crowd of atheists stand around him, all wearing black robes and hoods.

RANDOM ATHEIST: Damn you, Christian! We hate you! We claim to be tolerant of all religions. But we really hate your's! That's because we atheists are hypocritical like that! Die, Christian!

THE END

Scary, isn't it?

Religion (-1)

Anonymous Coward | about 6 years ago | (#25362579)

AKA "my invisible imaginary friend is better than your invisible imaginary friend".

Most human wars throughout the ages are based on religion. Scary, isn't it?

Re:Religion (5, Funny)

thePowerOfGrayskull (905905) | about 6 years ago | (#25362639)

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.

Re:Religion (2, Funny)

thePowerOfGrayskull (905905) | about 6 years ago | (#25362765)

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.

Re:Religion (0)

Anonymous Coward | about 6 years ago | (#25362863)

Damn you, Perlist! We hate you! We claim to be tolerant of all scripting languages (except for VB). But we really hate your's! That's because we engineers are hypocritical like that! Die, Perlist!

Re:Religion (0)

dwarfsoft (461760) | about 6 years ago | (#25363769)

I use VB (or WSH) You Insensitive Clod!

Try scripted support of an organisation full of Windows XP machines using WMI without it. Its useful only because its native to that platform (and it ties into WMI nicely).

Its a balance of using the right scripting language for the right job.

Plus, too many peoples brains explode when they try and read a 2000 line Batch File with "functions", loops, and all manner of other obscenity.

Re:Religion (1)

morgan_greywolf (835522) | about 6 years ago | (#25364203)

One word. PowerShell.

That is all.

Re:Religion (1)

mangu (126918) | about 6 years ago | (#25364583)

One word. PowerShell.

That's actually two words, with a misspelling, if the lack of a space can be called a misspelling.

Seriously, though, I'd take Perl over PowerShell anytime. Reasons: 1) CPAN; 2) Data saved as text instead of binary objects. The Unix Philosophy [experiencefestival.com] runs around the use of small scripts which can be used standalone and reused chained together. Perl was designed around this principle, it's perfect for text input.

Re:Religion (0)

Anonymous Coward | about 6 years ago | (#25362899)

Not really, our financial industries are based on imaginary money. And run on imaginary software.

Re:Religion (0)

Anonymous Coward | about 6 years ago | (#25363953)

You have been trolled sucka! Oh, and have a nice day.

Re:Religion (0, Offtopic)

DragonWriter (970822) | about 6 years ago | (#25364459)

Most human wars throughout the ages are based on religion. Scary, isn't it?

Scary, perhaps, but not at all true. Almost every war is entered into for economic reasons by the decision makers; religion, nationalism, and other forms of identity appeals are often used in appeals to keep the masses behind the war, but they generally aren't the main reasons, and often not reasons at all, for the war.

Fast javascript (5, Interesting)

cornicefire (610241) | about 6 years ago | (#25362433)

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 (2, Insightful)

brezel (890656) | about 6 years ago | (#25362533)

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:Fast javascript (1)

cornicefire (610241) | about 6 years ago | (#25362593)

Well, yes, I love strict typing too. But hey, Java on the client isn't dominant. It often makes sense to run the same code on the server and the client. You can move code from the server to the client if you need to. And share code too.

Now if only all of the Javascript implementations agreed on a stable definition....

Re:Fast javascript (1)

brezel (890656) | about 6 years ago | (#25362617)

Well, yes, I love strict typing too. But hey, Java on the client isn't dominant.

agreed!

It often makes sense to run the same code on the server and the client. You can move code from the server to the client if you need to. And share code too.

hmmm, i cannot recall a single time i wanted to do that. but it might be that i am too much used to the client-server paradigma to see the possible advantages?

Now if only all of the Javascript implementations agreed on a stable definition....

oh well :D

Re:Fast javascript (1)

cornicefire (610241) | about 6 years ago | (#25362657)

Well, yes. It depends upon how you structure your code. If you're using a strict MVC paradigm, it often doesn't make much sense to do anything but the V at the client.

But I've also built some math tools. After I got the first version running on the server, someone suggested moving it to the client because the client has plenty of spare cycles. SO i rewrote it in Javascript.

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. If you can move them back and forth, then everything is consistent. (If the Javascript versions agree! :0)

Re:Fast javascript (4, Insightful)

brezel (890656) | about 6 years ago | (#25362699)

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)

Re:Fast javascript (5, Insightful)

cornicefire (610241) | about 6 years ago | (#25362731)

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.

Re:Fast javascript (1)

johanatan (1159309) | about 6 years ago | (#25364515)

Please mod this up as GP is dead wrong on this.

Re:Fast javascript (4, Insightful)

aproposofwhat (1019098) | about 6 years ago | (#25362747)

i totally disagree here. i would NEVER run any validation code on the client.

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 :)

Re:Fast javascript (0)

Anonymous Coward | about 6 years ago | (#25364637)

Client side validation helps increase the usability by preventing the post-back and letting the user know in real time that he is going wrong.

You can have client side validation code + server side validation code at the same time.

Or you can use Ajax which would be slower though.

Re:Fast javascript (1)

gbjbaanb (229885) | about 6 years ago | (#25362781)

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 (5, Interesting)

ushering05401 (1086795) | about 6 years ago | (#25363075)

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.

Re:Fast javascript (1)

ushering05401 (1086795) | about 6 years ago | (#25362855)

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 (1)

WTF Chuck (1369665) | about 6 years ago | (#25363637)

Actually, I do run some client-side validation, backed up by server-side validation afterwards. For a shopping cart, it can be useful to validate that a CC number wasn't entered incorrectly (CC Check Digit [beachnet.com] ) or isn't expired. I tried doing this server-side only, but too many people would miss the error message on the screen, and just move on to whatever else they wanted to do. The javascript pop-up that appears when they enter an invalid CC number gets their attention, and they re-enter the card number. This little feature saves merchant transaction charges for an incorrect card number, as well as time calling the customer to get the correct card number.

Re:Fast javascript (3, Insightful)

nedlohs (1335013) | about 6 years ago | (#25364501)

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.

Re:Fast javascript (1, Insightful)

gbjbaanb (229885) | about 6 years ago | (#25362631)

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:Fast javascript (2, Interesting)

abigor (540274) | about 6 years ago | (#25363011)

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 (1)

morgan_greywolf (835522) | about 6 years ago | (#25364231)

In fact, all the major scripting languages mentioned -- Perl, Python, Ruby, JavaScript, Groovy -- are all dynamically typed. Too bad they left out Tcl. That one's dynamically typed too. Well, if by dynamically-typed you mean "everything, including code, is a string" but still ... ;)

And I'm not even sayin' that 'cause I love Tcl. In fact, I hate Tcl. But I fail to see why it wasn't mentioned (aside from the fact that it sucks, that is ... :)

Re:Fast javascript (0, Flamebait)

Daniel Dvorkin (106857) | about 6 years ago | (#25363697)

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?

If you write code like you write English, maybe you need "strict typing" (by which you presumably mean static typing) to keep you from making obvious mistakes. Those of us who write more carefully don't need that kind of handholding.

Re:Fast javascript (0)

Anonymous Coward | about 6 years ago | (#25363911)

Those of us who write more carefully don't need that kind of handholding.

What a stupid argument.

Your "dynamic typed" languages are still *TYPED LANGUAGES*, your compiler is just not smart enough to tell you when you've screwed the pooch. Instead you get to wait until run-time.

That's a sign of amateur-hour language design, not cleverness!

Re:Fast javascript (1)

Tablizer (95088) | about 6 years ago | (#25364129)

why would i want to use a language with no strict typing on the server

Another typing fight! Hide the women and children.

     

Re:Fast javascript (0)

Anonymous Coward | about 6 years ago | (#25362561)

https://phobos.dev.java.net/

Phobos is a lightweight, scripting-friendly, web application environment running on the Java platform.

Any language that runs in the JVM can be used with Phobos (JavaScript, Python, Ruby, etc.), but they seem to have an emphasis on JavaScript.

If you download NetBeans 6.1 from http://netbeans.org, you can then choose to install the phobos and JavaScript plugins. You'll be off coding high-performance server-side JavaScript in a great IDE with intelligent auto-complete, a debugger, etc., in not time.

Very cool.

Re:Fast javascript (1)

cornicefire (610241) | about 6 years ago | (#25362575)

And there's also Tracemonkey from the Firefox crowd. I forgot that one. And heck, Apple's got their own engine in Safari. I wonder if they would spin it out? It's probably not open source so we would have to wait for them. :-(

Here are some benchmarks:

Re:Fast javascript (4, Informative)

compro01 (777531) | about 6 years ago | (#25362777)

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]

Re:Fast javascript (0)

Anonymous Coward | about 6 years ago | (#25362615)

The JavaScript implementations are improving but they're still terribly slow. PHP and Perl are both significantly faster than V8, Tracemonkey, Spidermonkey etc., and none of these are even remotely close to the JVM or the CLR.

P.S. For server side applications this is practically irrelevant because the bottleneck is almost always the database.

Re:Fast javascript (1)

brezel (890656) | about 6 years ago | (#25362715)

For server side applications this is practically irrelevant because the bottleneck is almost always the database.

this is not necessarily true. take a look at complex ajax applications and you will soon realize that of a 2 second response 1.5 sec might be the client rendering the changed DOM.

Re:Fast javascript (4, Interesting)

Cyberax (705495) | about 6 years ago | (#25362643)

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: MORE IMPORTANTLY? Secure DOM (0, Offtopic)

Anonymous Coward | about 6 years ago | (#25362703)

"Does anyone know of a project to bring some of the fast Javascript implementations like V8 to the server?" - by cornicefire (610241) on Monday October 13, @06:40PM (#25362433)

More importantly than speed, imo @ least, would be to create a less 'faulty' (insecure) implementation of the Document Object Model (DOM) behind javascript... & of javascript itself!

(After all, anybody can take a peek over @ SECUNIA.COM &/or SECURITYFOCUS.COM (just to name a couple reputable sites in regards to security) & see that the majority of attacks ARE javascript driven the past 3-4 years now (sometimes in combination with plugins & iframes) that have even extended to not only bad site's code, but also adbanners as well).

Speed's nice, but judging by the state of things, such as the recent "ClickJack" shenanigans going on out there (which YES, stalling javascript does help stop, despite the init. headline here in regards to this on Sept. 25th 2008 ->

----

Alarm Raised For "Clickjacking" Browser Exploit:

http://it.slashdot.org/comments.pl?sid=976325&threshold=-1&commentsort=0&mode=thread&no_d2=1&cid=25158835 [slashdot.org]

----

Which the /. article's poster had stated otherwise (verbatim: "The issue has nothing to do with JavaScript so turning JavaScript off in your browser will not help you", which is blatantly untrue, if you read on you will see why & from whom (makers of NoScript iirc)), at the close of its initial posting?

Well, guess again:

----

SALIENT QUOTE:

http://www.securityfocus.com/news/11534/2 [securityfocus.com]

"JavaScript increases the effectiveness of this attacks hugely, because it ensures that user will click our target no matter where he points -- that is, we can move the target around to stay always under the mouse pointer"

----

Thus, as you can see? Well, contrary to the "clickjack" article initially posted here @ /. on Sept. 25th & its headline here from its initial poster??

It actually HELPS to stop javascript vs. Clickjacks, too (see the reference to SECURITYFOCUS.COM there in that URL above)... once more, see the URL above in regards to that & despite others also stating that 'stopping javascript would stall framebusting code, as well!

Speed's nice guys, but it only means you will get infected/infested, THAT MUCH FASTER is all, nowadays (& for the past 3-4 yrs. now)... heck, & the security suite folks are failing vs. these things too, with this latest COMPUTERWORLD excerpt:

----

Top security suites fail exploit tests (COMPUTERWORLD):

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9117042&intsrc=news_ts_head [computerworld.com]

&/or

Top security suites fail exploit tests (SECUNIA):

http://secunia.com/blog/29/ [secunia.com]

----

The "old-school methods" (what security suites use, like virus signatures, which only work vs. KNOWN threats, when they ought to be concentrating on white or blacklisting sites &/or HEURISTICS levels of detection ("smells like a duck, tastes like a duck: IT MUST BE A DUCK!" type logic)) aren't working that well nowadays guys!

After all, you know it, & I know it - The REAL, TRUE threat's coming thru your email, webbrowser, instant messenger programs (& even Adobe .pdf files with javascript active in the program, & plugins like Adobe Flash (which I guessed correctly on above no less, as to the "mystery program" that was involved that J. Grossman & crew (discoverers of the clickjack issue) kept under covers, due to "responsible disclosure")...

APK

P.S.=> What works? Really, REALLY, works?? This does:

HOW TO SECURE Windows 2000/XP/Server 2003, & even VISTA, + make it "fun-to-do", via CIS Tool Guidance (& beyond):

http://www.tcmagazine.com/forums/index.php?s=74c7878b1c24e43e2935329261e24a5f&showtopic=2662 [tcmagazine.com]

apk

Re:Fast javascript (1)

spiffmastercow (1001386) | about 6 years ago | (#25363083)

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 (3, Funny)

dgatwood (11270) | about 6 years ago | (#25363225)

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.

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....

Re:Fast javascript (1)

Blakey Rat (99501) | about 6 years ago | (#25364837)

You don't like Javascript, but you do like PHP? Feh.

Personally, I love Javascript. Even with the somewhat limited implementations browsers have, it's extremely powerful. You have to remember that most of the limitations of "Javascript" are actually limitations in DOM-- even if you did write client-side Python, it still would have to deal with the same crappy DOM that JS does now.

Obviously opinions vary. I wouldn't mind using Javascript server-side, the way PHP or Ruby is used now. Is anybody working on that? It seems like a relatively easy win. Javascript + setInterval/setTimeout (from DOM, the only good parts) could rule the world.

Re:Fast javascript (0)

Anonymous Coward | about 6 years ago | (#25363223)

I remember hearing about some company based in London that used to develop such a thing. Last I heard it bacame defunct. If anyone know anything about this can you reply?

>I would like to write in the same language on the client and the server.

I think PyPy can compile Python into Javascript. You could look into that.

Re:Fast javascript (3, Informative)

destiney (149922) | about 6 years ago | (#25363367)

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]

hey ho. (4, Interesting)

apodyopsis (1048476) | about 6 years ago | (#25362523)

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.

Re:hey ho. (1)

JonLatane (750195) | about 6 years ago | (#25363131)

Or even a "for" loop, if you still have to program in C90. I suppose while loops is still better than BNEs though...

All... most... there... (5, Funny)

fahrbot-bot (874524) | about 6 years ago | (#25362535)

... Perl ... and other scripting tools are fast achieving the critical mass necessary to flourish into the future

Ya, once Perl is used in a few more places, it'll have critical mass.

Re:All... most... there... (1)

Yvan256 (722131) | about 6 years ago | (#25362599)

Maybe De Beers could help?

Re:All... most... there... (0)

Anonymous Coward | about 6 years ago | (#25363511)

Maybe De Beers could help?

Certainly can't hurt! I'll have some o' dose beers! Thanks!

Having had to wade through 100k lines of it... (2, Funny)

patio11 (857072) | about 6 years ago | (#25364123)

...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.

Re:Having had to wade through 100k lines of it... (1)

morgan_greywolf (835522) | about 6 years ago | (#25364277)

Damn! There's just something about Perl that makes its coders have a healthy sense of humor....damn....why are you looking at me like that? You're serious?

Re:Having had to wade through 100k lines of it... (1)

fahrbot-bot (874524) | about 6 years ago | (#25364339)

one horrific industrial accident involving a regexp gone horribly awry

Never send a boy to code a man's regexp.

Pure scripting: Lua (5, Insightful)

Anonymous Coward | about 6 years ago | (#25362585)

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.

Re:Pure scripting: Lua (1)

xant (99438) | about 6 years ago | (#25363721)

Lua is also uniquely capable in the area of being sandboxable. I'm looking forward to trying it out some day.

Re:Pure scripting: Lua (1)

belmolis (702863) | about 6 years ago | (#25364287)

Lua is widely used in games, but isn't Tcl more extensively used in embedded devices?

Clueless. (5, Informative)

SanityInAnarchy (655584) | about 6 years ago | (#25362607)

Larry Wall nabbed Python's object system when he created Perl...

Erm, WTF? Perl was released in 1987; Python was 1991.

Re:Clueless. (4, Informative)

ShadowRangerRIT (1301549) | about 6 years ago | (#25362665)

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.

Re:Clueless. (4, Informative)

RDW (41497) | about 6 years ago | (#25362941)

'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.'

Re:Clueless. (1)

morgan_greywolf (835522) | about 6 years ago | (#25364377)

I fail to see Python as being the anti-Perl. Python and Perl have many similarities, even outside the aforementioned Perl 5 object system. Both are dynamic languages, dynamically-typed, and both make using regular expressions to do nifty things nice and easy.

The main difference I see is that Python appears to be more organized, methodical and consistent, while Perl seems to be a bit schizophrenic. OTOH, you can find both descriptions can be applied to various aspects of both languages. ;)

I like Python, but I like Perl too. Lua is pretty cool, too. The only dynamic language I detest is Tcl.

Re:Clueless. (3, Funny)

Bill, Shooter of Bul (629286) | about 6 years ago | (#25362783)

I'm guessing that he meant to say " when Larry Wall decided to add an object system to Perl". As the Objects weren't added until 1994. So that's when the nabbing probably occurred. Well, either that or Larry Wall has an unpublished update to Physics::Lorentz.

perl history [wikipedia.org]

Re:Clueless. (0, Redundant)

sergstesh (929586) | about 6 years ago | (#25362813)

You are both right and wrong.

Perl 4 was released before Python and Perl 4 did not have OO model.

Perl 5 was released well after Python (1997 ?) and Larry Wall now regrets about borrowing OO model from Python.

Still Clueless (5, Insightful)

SanityInAnarchy (655584) | about 6 years ago | (#25363069)

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 is that the community of developers for a given framework is likely to be bigger than that of a given application.

But that's a pretty meaningless distinction. When an application becomes big enough, it starts being called a framework. The Drupal About page [drupal.org] (down at time of writing; Google Cache here [74.125.95.104] ) doesn't contain the words "application" or "program" -- instead, words like "package" are used. The slogan is "Community Plumbing".

Communities will be more important.

Good point.

Unfortunately, his example is the iPhone, which isn't a community -- it's a product. Is his point that gadgets will drive framework adoption?

The Web and the cloud are the ultimate platform.

Sure, if we can define them.

Google's App Engine sparked a huge burst of interest in Python. Perl and PHP were early favorites because they were so well integrated with Apache, a Web server that was both free and easy to configure.

These are actually not going to be as influential in the future as they are now -- languages can push back.

See, we still have clouds like Amazon EC2, which runs any language you want it to. Not that this has to be hard -- Heroku [heroku.com] makes it trivial for a Rails app.

And integration with webservers is no longer a huge deal -- technologies like FastCGI already made that a moot point. Then we got things like Mongrel, YAWS, and so on -- webservers integrated into the application, rather than the other way around.

After all, talking HTTP is probably the simplest part of any application.

Better language technology will make a difference.... The performance gains these browsers have brought to JavaScript have been dramatic, and they're already making some other scripting languages jealous.

Performance is actually of steadily decreasing importance. Write a good app in a language where it makes sense, and write it to be horizontally scalable -- that way, you can just throw hardware at the problem, which is getting cheaper all the time.

One exception is actual client code. Here, those Javascript performance improvements matter -- but not much. Consider that Javascript pretty much sucked when we all started using Gmail.

All of the embedding makes it simpler for programming to escape the command line and start appearing in Web applications themselves. Some of the highly customizable platforms, such as WordPress and some Drupal plug-ins, let you add custom code in a Web form.

This is a spectacularly bad idea.

A much better idea is to write your app cleanly enough that your users can write GreaseMonkey scripts. That way, it all stays client-side -- you don't have to let users upload executable code.

The rise of the amateurs may make much of dynamic programming irrelevant.

Yeah, yeah, we've heard it all before.

Thing is, we've seen the result of letting users program. From FileMaker to Excel, the result is inevitably a horrible, expensive mess. Occasionally it works -- far more often, you end up with something that no one remembers how to maintain anyway, so they call in the experts.

On the surface, it sounds like a good idea -- which could be said of a lot of what this article is suggesting. But it has consistently failed to put real programmers out of work.

Adaptability for modern architectures is key.

Indeed.

Strangely, everyone (including me) seems to want to adapt their own pet language to multicore, rather than start with a language that already scales well (Erlang).

There are some interesting things said here, but ultimately, this is a fluff article, and frequently quite wrong. It did get one thing right, though:

These principles don't lead to one clear answer for the path of dynamic languages and Web development.

That's because we don't know. We barely even know what we're looking for, and this author certainly doesn't.

this guy didn't do any research (0, Interesting)

Anonymous Coward | about 6 years ago | (#25362611)

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:this guy didn't do any research (4, Informative)

Anonymous Coward | about 6 years ago | (#25362707)

From Larry Wall's 2007 State of the Onion: [perl.com]

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.

Re:this guy didn't do any research (2, Insightful)

thePowerOfGrayskull (905905) | about 6 years ago | (#25362739)

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:this guy didn't do any research (1)

perlchild (582235) | about 6 years ago | (#25363431)

And perl1.0 was released on Dec 18th, 1984...

Some numbers just seem so way out there...

Nabbed from Python for Perl (1, Insightful)

Anonymous Coward | about 6 years ago | (#25364127)

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.

Computer languages evolve like natural languages (2, Interesting)

Anik315 (585913) | about 6 years ago | (#25362677)

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 (1, Interesting)

Anonymous Coward | about 6 years ago | (#25362837)

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:Computer languages evolve like natural language (2, Insightful)

Just Some Guy (3352) | about 6 years ago | (#25363041)

I don't think "John and I" is even arguably correct, since "I" is subjective.

Re:Computer languages evolve like natural language (3, Insightful)

siride (974284) | about 6 years ago | (#25362985)

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.

Re:Computer languages evolve like natural language (1)

Estanislao Martnez (203477) | about 6 years ago | (#25363375)

As somebody with an A.B.D. in Linguistics, I'm not sure your criticism of GP is correct, because I can't see that GP is saying what you attribute to them. This is mostly because GP isn't being very clear about what they mean, I'll grant you.

It all comes down to what GP means by "formal grammar." In your response, you have assumed that this means "grammar guides," apparently of the prescriptive sort, but GP's example is Panini, and Europeans' discovery thereof. This is one of the key historical events that launched modern European linguistics, since it provided both a clear example of a family relationship between very far-flung languages, but also because Paninian grammar is far more technical and precise than anything that Europe had ever produced. The statement that European languages "didn't have formal grammar" until the discovery of Panini's work sounds very much like a claim that the European discipline of linguistics only really took off after the discovery of Sanskrit.

Though even reading it charitably in this way, GP's statement is still very garbled. The discovery of Sanskrit eventually started an ongoing change of grammatical theory in Western science, but it didn't change the grammar of the languages.

Re:Computer languages evolve like natural language (1)

siride (974284) | about 6 years ago | (#25363423)

Well, if that is what he meant, then I think you have a fair point. I'm just so used to people saying blatantly incorrect things about the way language works that I probably assumed he meant the more ignorant of the two interpretations.

Re:Computer languages evolve like natural language (1)

Estanislao Martnez (203477) | about 6 years ago | (#25363443)

I don't know for sure what the guy meant. Again, it's pretty garbled, and the choice of example only makes it more so.

Re:Computer languages evolve like natural language (4, Informative)

turbidostato (878842) | about 6 years ago | (#25363045)

"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.

Re:Computer languages evolve like natural language (1)

Estanislao Martnez (203477) | about 6 years ago | (#25363277)

...and the ancient Greeks discussed grammar in their works, and the Romans had grammars of Latin, and in fact, those Latin grammars provided an important model for the European vernacular grammars that you mention. Hell, even modern-day linguists get a much bigger chunk of their grammatical terminology from Latin grammar than they do from Panini's Sanskrit grammar--even though the latter is much deeper than Latin grammar, and a bigger conceptual influence on modern linguistics.

Re:Computer languages evolve like natural language (1)

cbreaker (561297) | about 6 years ago | (#25363775)

I'm not a programmer, but I have been able to use PHP to make some pretty nice little dynamic web sites and mini-applications.

You don't have to be an expert to make effective use of it. You can open a PHP script and follow it.

The same can be true for many languages, I suppose - but for someone with practically no programming skills at all I've always found php to be the easiest to just pick up and do something useful with.

So, I'd say that one of the biggest reasons for it's popularity is that you can learn it very easily if you have no programming background. (I'm perhaps a special case, though - I consider myself to be a highly effective IT Systems Engineer with a great deal of background with computers so I pick these things up pretty quickly anyways.)

Re:Computer languages evolve like natural language (0)

Anonymous Coward | about 6 years ago | (#25363819)

Are you for cereal?
The real reason PHP is so popular is because of the kids who use it to make webpages.

OOP: use with care (0, Troll)

Tablizer (95088) | about 6 years ago | (#25364191)

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.

Some things work well as objects and some don't. Thus, its good to have a natural way to do procedural when needed. Languages created by object purists sometimes are difficult outside of object-land.

One thing I wish PHP had done was make no distinction between objects and associative arrays. Thus, foo.bar would be the same as the less natural foo['bar']. (The second needed if funny characters used.)
     

Re:Computer languages evolve like natural language (0)

Anonymous Coward | about 6 years ago | (#25364429)

As someone who started with PHP and now uses Ruby for professional web apps, I have to strongly disagree with your assertion about PHP being more like a natural language than Ruby. Also recall that Ruby started in Japan and is very big there, while PHP started in the West, so it is taking time for Ruby to make it's way over here (they started around the same time) and in the short period it has been here (in the West) it has exploded because of how easy it is to use.

Now I will say for a short little one or two page application it can still make sense to use PHP, but for anything more complex, espcially if it needs database access, Ruby is the way to go. Note, I didn't say Ruby on Rails, since there are a ton of different frameworks available (just as there are for PHP) from Merb to Camping, etc. Here's a short list for those interested:

http://accidentaltechnologist.com/ruby/10-alternative-ruby-web-frameworks/

"Co-optation"?? (4, Funny)

jamrock (863246) | about 6 years ago | (#25362773)

Oh. My. God.

A million grammarians cried out in terror and were suddenly silenced.

& 1 EDITOR: "horror" NOT "terror"!!!! (0)

Anonymous Coward | about 6 years ago | (#25364093)

HUMBUG.

d:

Tcl ignored again (0)

Anonymous Coward | about 6 years ago | (#25362843)

http://www.tcl.tk/

Still growing and getting better. Why is it so ignored? It rox for my work which is electronic hardware testing suites built with NI's LabWindows

Re:Tcl ignored again (1)

cbreaker (561297) | about 6 years ago | (#25363791)

I've played around with tcl/tk a bit and found it to be fun to use in the limited time I used it. You can get things up on the screen and do something useful with it almost immediately.

The only other language I've "programed" with is PHP.

Firefox vs. Chrome? (2)

heretichacker (1132337) | about 6 years ago | (#25363243)

The battle for supremacy between Mozilla's Firefox ("JavaScript, I am your father") and Google's Chrome ("Come live in thread harmony, Luke") is good for everyone.

With the story on Chrome having a 1.5% share [slashdot.org] earlier today, and Firefox having a 32% share [getclicky.com] , I don't see how there's a "battle for supremacy"...

What kind of force? (1)

gmuslera (3436) | about 6 years ago | (#25363549)

Don't use the forks, Luke (or Larry, or Guido, or Rasmus)

the inevitability of an uber-scripting language (1)

Tumbleweed (3706) | about 6 years ago | (#25363635)

It will wind up looking like what we all use as 'pseudo-code' when teaching someone something in a language-neutral way.

It will use real words or phrases as commands, instead of ridiculously stupid things like 'elif' or 'printf'. *sigh*

Re:the inevitability of an uber-scripting language (3, Informative)

sulfur (1008327) | about 6 years ago | (#25364747)

I think I've seen it somewhere [wikipedia.org] .

coldfusion (0)

Anonymous Coward | about 6 years ago | (#25364095)

what about coldfusion ?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?