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

Comments

Don't forget synergy...

[Anonymous Coward]

And twitter.

10 forces?

[CaptainPatent]

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?

[Anonymous Coward]

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?

[Anonymous Coward]

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

Re:10 forces?

[fm6]

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

Re:10 forces?

[Anonymous Coward]

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?

[Profane MuthaFucka]

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

Re:10 forces?

[pimpimpim]

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?

[DiegoBravo]

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?

[babblefrog]

I would say that in many shops, there can be only one because they don't want to have to support more than one. It's not that one is necessarily better than the other. This is a perfectly reasonable choice.

Re:10 forces?

[ultranova]

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.

Which assumes that said speedup will always be existent. There is nothing inherently slow in scripting languages; it's simply harder to write a reasonably good compiler for them than for C.

Re:10 forces?

[doom]

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

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.

Re:10 forces?

[pimpimpim]

Yes, I did. I am not the best perl or C programmer around, but when I ported my program which is a simple loop of additions from perl to C, I got a speedup of about 20. It was a pain to do the memory management in C, but I really needed the speedup. Actually if you look at fast perl packages like PDL, they are based around precompiled C or fortran code (LAPACK/BLAS).

Fast javascript

[cornicefire]

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

[JPortal]

http://en.wikipedia.org/wiki/Server-side_JavaScript

I don't know if any of those are good, but it's a start.

Re:Fast javascript

[brezel]

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

[Anonymous Coward]

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

[cornicefire]

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:

• from John Ressig
• from Darren Hobbs
• From Brendan
• SquirrelFish seems faster?

Re:Fast javascript

[cornicefire]

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

[Anonymous Coward]

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

[brezel]

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

[gbjbaanb]

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

[Cyberax]

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

[cornicefire]

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

[brezel]

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

[brezel]

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

[cornicefire]

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

[aproposofwhat]

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

[compro01]

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/

Re:Fast javascript

[gbjbaanb]

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

[ushering05401]

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

[abigor]

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

[ushering05401]

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

[spiffmastercow]

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

[Anonymous Coward]

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

[dgatwood]

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

[destiney]

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

Re:Fast javascript

[WTF Chuck]

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

[Daniel Dvorkin]

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

[Anonymous Coward]

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

[Tablizer]

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

[morgan_greywolf]

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

[nedlohs]

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

[johanatan]

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

Re:Fast javascript

[Anonymous Coward]

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

[Blakey Rat]

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

[I cant believe its n]

Attila Szegedi maintains Rhino which is javascript on the Java virtual machine. As secure as you decide, fast and portable.

Rhino
Attila Szegedi

Re:Fast javascript

[yk4ever]

http://en.wikipedia.org/wiki/Mozilla_Rhino

Re:Fast javascript

[ggvaidya]

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

Squack? Don't know about replacing Javascript clientside, though.

Re:Fast javascript

[Inda]

I was writing Javascript on the server and client 7 years ago. I stopped on the server because there was so little support on the net. It was really good fun until there was a problem I couldn't get my head round.

The server was IIS. The language was ASP. I swapped JS for VBS. I'll get my coat. Anyone want a lower than average Slashdot ID?

Re:Fast javascript

[kitgerrits]

So you want the client to be able to tell the server "Don't worry, I already checked it".
A very nice feature indeed.

Re:Fast javascript

[Anonymous Coward]

Look, dynamic typing is what makes things easy. Why I'm teaching myself Python right now. Look at how easy this is!

def parrot(voltage, state='a stiff', action='voom'):
print "-- This parrot wouldn't", action,
print "if you put", voltage, "volts through it.",
print "E's", state, "!"

d = {"voltage": "four million", "state": "bleedin' demised", "action": "VOOM"}
parrot(d)

-- This parrot wouldn't voom if you put {'action': 'VOOM', 'state': "bleedin' demised", 'voltage': 'four million'} volts through it. E's a stiff !

Oh shit, wait...I meant

parrot(**d)

because d is a dictionary type and it has to be unpacked. Boy I'm glad these dynamically types languages help me avoid boneheaded mistakes like that!

Re:Fast javascript

[Anonymous Coward]

That's not what he said at all, idiot. Learn to read.

Re:Fast javascript

[haystor]

So these people that know C well enough to write something like Perl or Python found a need for a dynamically typed language.

Why should the language enforce this anyway? It really should be optional, more of a compiler hint anyway.

Re:Fast javascript

[ultranova]

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.

Static typing allows the compiler/runtime to find type mismatch errors and complain, while with dynamic typing, the program will simply crash upon encountering one. Static typing makes a whole class of bugs impossible, just like automatic memory management, and results in more reliable programs.

Re:Fast javascript

[sorak]

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

Holy crap, that's scary! I imagine a server that randomly decides not to support certain language features and leaves you having to having to write kludgey works arounds so that all your code looks like this:

try
{
      attempt_thing()

}// Maybe the user is using internet explorer
catch
{
      try
      {
            attempt_different_thing()
      }// Crap!
      catch
      {
            try
            {
                  alert("We're sorry, but your web browser doesn't support whatever it is were trying to do. I would elaborate more on this, but halfway into the 14th try catch block, I just forgot. I recomend that you get a new browser, install it on a new PC, and, if that doesn't work, then piss off!");
            }catch
            { // I can't remember what I was supposed to do here.
            }
      }
}

Re:Fast javascript

[neilobremski]

I still enjoy writing JScript ASP under IIS, but unfortunately it's very platform-specific and many COM objects that make it useful won't be found on other server-side JavaScript implementations.

Re:Fast javascript

[Anonymous Coward]

You may be interested in Haxe (http://haxe.org/), which compiles into javascript and actionscript, and runs server side, and fairly quickly at that.

Re:Fast javascript

[Doctor Faustus]

Static typing makes a whole class of bugs impossible
Yes. I'm not entirely convinced it's a very significant class of bugs, though. I think performance is probably a better argument.

and results in more reliable programs.
Not with current languages, no. Unit testing is done much more consistently by scripting language programmers because testability just doesn't fit very well into the Java/.Net paradigm. When you can change your real classes and objects for a test, you don't have to use dependency injection everywhere, or avoid constructors, concrete classes and inheritance. You can also make your own fake versions of classes Java or C# might have made final.

Now, granted, a language could let you declare "MyClass myObject", validate it, and still let you change what those mean for testing; that would be great. Until languages like that appear, though, I think I'm sold on Python and Ruby being more reliable for practical purposes than Java and .Net.

Re:Fast javascript

[l0b0]

What To Know Before Debating Type Systems. Interesting read.

Re:Fast javascript

[dgatwood]

JavaScript is an okay language if you treat it as a strictly procedural language. I'd be a lot happier with it if they had real classes and inheritance that didn't suck. Even PHP... heck, even Perl has an object model that is a million times more usable than JavaScript's object model, which appears to have been constructed more as a convenience for providing DOM objects whose methods are defined by C code in the browser than as an actual tool for development in the language itself. Working with OO JavaScript is such a pain in the backside that I just don't bother. By contrast, I write OO in PHP and Perl all the time.

As for the JS DOM, you're right, but if you had a good OO model (something with the equivalent of Objective-C Categories) as part of the bytecode standard, you could ostensibly extend the DOM implementation and either add methods or override methods with custom versions that call into the native code as desired, and do so as part of your initialization. After that, all browsers would be equal just by adding a fairly simple chunk of initialization code. A real, sane bytecode backend designed by somebody who actually gets OO would be the client-side programming equivalent of the Holy Grail....

Re:Fast javascript

[zuperduperman]

I'm not sure how fast it is, but rhino can give you Javascript on the server side in a very effective manner. And it is shipped by default with the JRE.

So - deploy a standard Tomcat or other java based server environment, write a small controller servlet that intercepts requests and dispatches them into your Javascript handlers. It's easy to do, I've done it once before for slightly different reasons.

The only thing I can't really tell you about is performance - I've never used it for anything performance critical. But a beauty of it is that from your javascript you can call any native java api, so whatever needs speeding up you can just move into java itself.

Re:Fast javascript

[Allador]

testability just doesn't fit very well into the Java/.Net paradigm.

I dont understand this at all.

Like any language, in Java or .NET, if you're doing unit testing, it changes the way you design the objects and structures. You design them to BOTH fit the domain model and to more easily support unit testing. But there's nothing inherently difficult about doing unit testing and a TDD approach with Java or .NET.

Now, granted, a language could let you declare "MyClass myObject", validate it, and still let you change what those mean for testing; that would be great. Until languages like that appear, though, I think I'm sold on Python and Ruby being more reliable for practical purposes than Java and .Net.

Thats whats so great about static typed languages, you have Interfaces. Combine that with dependency injection and mocks, and your whole last two paragraphs are trivially answered.

It's true that its a bit more overhead and setup for very small apps, but once you get past a few thousand or tens of thousands of lines of code, I would argue it makes it more manageable.

I think one of the big things statically typed languages gives you is better tooling. One of my contracts right now is a ~3M loc system in Java, which is a heavy user of spring and hibernate. I can move around this thing so fast, follow code execution paths, call & type hierarchies, etc. If I need to rename a method, or add/remove parameters, the IDE immediately tells me what it breaks, or does the fixups for me automatically using the refactoring tools.

And I have a stepping debugger! Why the heck cant any modern dynamically typed languages include a debugger. I realize that a debugger isnt for every day use. But when you've got to drop into a complex set of code written by someone else and step through a few hundred calls to figure out why something is broken, a stepping debugger is essential. Without it, you have to litter your code with log dumps and other noise.

Lastly, at least for languages like Python & Ruby, it fundamentally breaks one of the core concepts of OO: Encapsulation. In these languages you're FORCED to interact with other components based on your looking at the source (ie, their implementation) rather than their published interface. That is just so broken its hard to comprehend why no one else complains about it.

Re:Fast javascript

[Doctor Faustus]

Like any language, in Java or .NET, if you're doing unit testing, it changes the way you design the objects and structures.
It shouldn't have to, to nearly the degree that it does.

Combine that with dependency injection and mocks, and your whole last two paragraphs are trivially answered.
That's far from trivial. That undercuts any notion that object-oriented programming is intended to model the problem at hand.

but once you get past a few thousand or tens of thousands of lines of code...One of my contracts right now is a ~3M loc system in Java
Unless you're doing something on the scale of an operating system, what could possibly warrant three million lines of code in one program? In eleven years programming professionally, the largest program I've ever written was ~10kloc (and I eventually regretted how monolithic I made it) and the largest I've worked on (awful monolithic and repetitive architecture) was around ~50kloc.

I think one of the big things statically typed languages gives you is better tooling.
That's my impression, but people who actually use scripting languages for a living (I do .Net and PL/SQL lately) seem to dispute it.

And I have a stepping debugger!
Ruby has one, anyway. It's not pretty, but having an interactive interpreter tied to the debugger is handy; that's a big part of why people could get stuff done in VB6 despite the piss-poor language, and Ruby's is more versatile.

In these languages you're FORCED to interact with other components based on your looking at the source (ie, their implementation) rather than their published interface.
Not exactly, but no, it's not behaving to your taste. Plenty of people complain about duck-typing, though.

Re:Fast javascript

[Allador]

That's far from trivial. That undercuts any notion that object-oriented programming is intended to model the problem at hand.

It sounds like you're assuming that there should only be one domain/concern to model, but the real world never works like that. You always have competing conceptual models (or at least pieces of them) in the business domain, and you always have real-life technical artifacts/limitations that influence your models. That doesnt mean OO is useless, it just means that absolute purity is difficult in the real world.

And tweaking the way you design systems to support unit testing tends to actually improve most developers structures/factoring, in my experience. It's a beautiful side effect that seems to work quite serendipitously in reality.

Unless you're doing something on the scale of an operating system, what could possibly warrant three million lines of code in one program? In eleven years programming professionally, the largest program I've ever written was ~10kloc (and I eventually regretted how monolithic I made it) and the largest I've worked on (awful monolithic and repetitive architecture) was around ~50kloc.

An enterprise financial system for large national (but not multi-national at this point) orgs. Including procurement/purchasing, reporting, workflow, batch system, authn/authz frameworks, all done in a web app. It's an ERP, they're just huge, at least from what I've seen.

Note also that this is done in Java, which is a rather verbose language. :) So that inflates the numbers a little bit.

That's my impression, but people who actually use scripting languages for a living (I do .Net and PL/SQL lately) seem to dispute it.

I do both ... we also do some Rails contract dev recently. Some things I love about Ruby & Rails, but the tooling is freaking terrible. At least in some ways. If you consider the rails generator and rake as tooling, then that helps, but is not any more fundamentally powerful (though much more concise) than hibernate.

Ruby has one, anyway. It's not pretty, but having an interactive interpreter tied to the debugger is handy; that's a big part of why people could get stuff done in VB6 despite the piss-poor language, and Ruby's is more versatile.

Ruby definitely does not unless one just showed up in the past year or so. You can add a line of code that acts as a break point in the system, and then fall out to the interactive ruby prompt. But thats not even close to the same thing as the interactive debugger I have with Eclipse in Java, or hell, even close to as powerful as the VB6 debugger I had 10 years ago.

If I am missing something fundamental, and there is a real stepping debugger (ie, let me step into, step over, step out, and see the full stack trace at any point the value of any variables), PLEASE let me know.

Re:Fast javascript

[cnystrom]

> I would like to write in the same language on the client and the server. (Java almost achieved that...)

C achieved it. :)

hey ho.

[apodyopsis]

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.

[JonLatane]

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

[fahrbot-bot]

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

[Yvan256]

Maybe De Beers could help?

Re:All... most... there...

[Anonymous Coward]

Maybe De Beers could help?

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

Pure scripting: Lua

[Anonymous Coward]

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.

Re:Pure scripting: Lua

[xant]

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

[belmolis]

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

Clueless.

[SanityInAnarchy]

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

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

Re:Clueless.

[ShadowRangerRIT]

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.

[Bill, Shooter of Bul]

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

Re:Clueless.

[sergstesh]

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.

Re:Clueless.

[RDW]

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

[morgan_greywolf]

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.

[oliderid]

Bless(you);

this guy didn't do any research

[Anonymous Coward]

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

[Anonymous Coward]

From Larry Wall's 2007 State of the Onion:

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

[thePowerOfGrayskull]

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

[perlchild]

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

Some numbers just seem so way out there...

Re:this guy didn't do any research

[Anonymous Coward]

Python has won several benchmarks as the #1 fastest

Not really, unless you pick and choose your benchmarks specifically to favour it, and only then if you use something non-standard and platform-restricted like Psyco. Choose other benchmarks, and other languages come out on top.

But benchmarks are largely meaningless anyway, and raw speed is itself not that important -- most interesting programs are IO-bound, and where you actually have a CPU-bound algorithm, you will generally wind up implementing it in C and calling out to that from your language of choice, which means the speed will be identical whether you choose Python, Perl, Ruby, or anything else.

Re:Religion

[thePowerOfGrayskull]

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.

Computer languages evolve like natural languages

[Anik315]

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:Fast javascript: MORE IMPORTANTLY? Secure DOM

[Anonymous Coward]

"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

----

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

"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

&/or

Top security suites fail exploit tests (SECUNIA):

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

----

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

Re:Religion

[thePowerOfGrayskull]

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.

"Co-optation"??

[jamrock]

Oh. My. God.

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

Re:"Co-optation"??

[Anonymous Coward]

Care to explain your point? All my dictionaries say co-optation and co-option (or cooptation, coÃptation, cooption, coÃption) are interchangeable.

Re:Computer languages evolve like natural language

[Anonymous Coward]

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)

Tcl ignored again

[Anonymous Coward]

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

[cbreaker]

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.

Re:Religion

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:Computer languages evolve like natural language

[siride]

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

[Just Some Guy]

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

Re:Computer languages evolve like natural language

[turbidostato]

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

Still Clueless

[SanityInAnarchy]

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

Re:Still Clueless

[chthon]

Concerning Drupal : Dries Buytaert IS a computer scientist, so he should be able to do anything with any language in a structured way.

Re:Still Clueless

[SanityInAnarchy]

Sure, it's possible, and you don't need to be a "computer scientist" to do so. You can do anything in any language that's Turing-complete.

But that's a bit like saying you can write a webserver in Bash -- aside from just proving it can be done, why would you ever want to write this? What practical reason could you possibly have for using Bash instead of, well, anything else?

I could ask the same questions about Drupal and PHP. Given that Drupal could've been written in any language, and given Dries Buytaert clearly knows other languages (being a computer scientist), what possible reason could he have for using PHP?

Re:Still Clueless

[KindMind]

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

Yeah, yeah, we've heard it all before. ...... But it has consistently failed to put real programmers out of work.

Yes, exactly. Some of the most dreaded words around: "We have an Access application that's not working right, can you fix it?".

As far as there are "scripting wars", I'm rooting for whatever to "win" that isn't brain damaged (not that any of the languages mentioned are), to allow a newbie to start something, but allow a dev to follow up and fix and extend things without gouging out his/her eyes.

Excellent comments, BTW.

Re:Still Clueless

[Bill, Shooter of Bul]

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.

Seriously? Applets? again? Have fun.

And I think he was talking about Groovy embedded inside of Java.

The article is similar to just about anything you read written by anyone : An alternating points of insight and clueless, but generally well meaning.

Re:Still Clueless

[SanityInAnarchy]

Seriously? Applets? again? Have fun.

People are already doing them with Flash. Given the choice, at least Java is open source, and supports languages other than ActionScript.

And I think he was talking about Groovy embedded [codehaus.org] inside of Java.

Which doesn't change a lot. I know he was talking about Groovy, but he was also talking about a feature of it that already existed in Java.

The article is similar to just about anything you read written by anyone : An alternating points of insight and clueless, but generally well meaning.

Well meaning, sure.

I just got the feeling, reading this, that the guy didn't even do his homework, and that he was a journalist, not a programmer.

Re:Still Clueless

[SanityInAnarchy]

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 that's a problem with my head, and not with Haskell, but it does -- and Erlang makes my eyes bleed, coming from Ruby. Reia looks interesting, but I haven't had the time to take a serious look -- and it's also so tiny that I doubt you'd be able to get much done without talking to existing Erlang libraries, and Erlang is already kind of small.

Those are just the major things. There are all kinds of other little warts that annoy me -- again, in Ruby, there's the way 'autoload' works (it doesn't use your custom 'require' statements), and there's a few things that I miss from Javascript (ad-hoc, prototypal object systems).

My own contribution to the problem, as I said, is to try to make Ruby just a bit more multicore-friendly -- by writing an actor library on top of it.

Re:Still Clueless

[Bill, Shooter of Bul]

No, I don't think you can just load a source code file of Java into a running java Application without Groovy. If I had my way, flash wouldn't be used either. I understand the temptation to use Java in the browser, believe me I do, but the slow start up time and resource usage makes it a bloated whale. I'm guessing you don't remember the bad old days of java applets in the mid to late 90's. There is a reason why developers have even preferred kludgy AJAX over revising Java applets.

Re:Still Clueless

[zuperduperman]

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

Actually you might not understand the full extent of what groovy does. It, for example, allows you to add new methods to existing classes (want a new kind of trim() method on the String class? just add it on!). You can even declare it's use within a certain scope so that your modified String class only applies to a certain block of code. This kind of flexibility is way beyond what Java reflection allows in any usable fashion.

Re:Still Clueless

[SanityInAnarchy]

No, I don't think you can just load a source code file of Java into a running java Application without Groovy.

There's no technical reason why not -- just hasn't been done.

I understand the temptation to use Java in the browser, believe me I do, but the slow start up time and resource usage makes it a bloated whale.

Have you seen Flash lately?

My hand to $deity, Java applets load faster than Flash widgets for me.

I'm guessing you don't remember the bad old days of java applets in the mid to late 90's.

I do.

And you don't think anything's changed in ten years?

There is a reason why developers have even preferred kludgy AJAX over revising Java applets.

Oh, right now, I prefer AJAX over any of the above. Javascript isn't a bad language -- there are things from it that I miss in Ruby. And it's a lot easier to do progressive enhancement of an otherwise HTML page -- even a nice, semantic-HTML page (especially so, with jQuery) -- than it is with a plugin.

Re:Still Clueless

[Bill, Shooter of Bul]

Well, given your responses you really aren't talking about the article anymore. We're just down to a Legitimate difference in opinion. Might be solved with a lot of benchmarks and what not, but not really worth the effort.

Re:Still Clueless

[SanityInAnarchy]

Might be solved with a lot of benchmarks and what not, but not really worth the effort.

No, not really, but I don't need benchmarks.

I would guess part of why I perceive Flash as slow is that it's abused, probably more than any other Web technology. A bigger part would be that I'm on 64-bit Linux, which is probably the worst platform I could be running for Flash and still have it work.

But I've just had both Flash and Java applets load in half a second or less, in a casual test. That's good enough that I'd file it under "non-issue" -- as in, not really worth the effort for anyone to benchmark, when choosing a technology.

Firefox vs. Chrome?

[heretichacker]

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 earlier today, and Firefox having a 32% share, I don't see how there's a "battle for supremacy"...

Re:Computer languages evolve like natural language

[Estanislao Mart�nez]

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

[Estanislao Mart�nez]

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

[siride]

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

[Estanislao Mart�nez]

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.

What kind of force?

[gmuslera]

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

the inevitability of an uber-scripting language

[Tumbleweed]

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

[sulfur]

I think I've seen it somewhere.

Re:Religion

[dwarfsoft]

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:Computer languages evolve like natural language

[cbreaker]

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

[Anonymous Coward]

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

Re:Religion

[Anonymous Coward]

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

& 1 EDITOR: "horror" NOT "terror"!!!!

[Anonymous Coward]

HUMBUG.

d:

coldfusion

[Anonymous Coward]

what about coldfusion ?

Re:coldfusion

[I cant believe its n]

Low energy nuclear reactions are useless when scripting

Re:coldfusion

[oliderid]

Well I had to migrate a whole administration web site (coldfusion based) dating from 1998 to PHP. This migration was done on 2007.Reason?

Almost nobody knows it anymore.
Coldfusion is dead.

Having had to wade through 100k lines of it...

[patio11]

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

[morgan_greywolf]

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

[fahrbot-bot]

one horrific industrial accident involving a regexp gone horribly awry

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

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

[Anonymous Brave Guy]

It's not just regexps you have to worry about. Remember, in Perl, there's more than one way to cause an horrific industrial accident!

Nabbed from Python for Perl

[Anonymous Coward]

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.

OOP: use with care

[Tablizer]

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:OOP: use with care

[Tablizer]

Okay, please tell me why above got marked as "troll". Knowing its a sensitive topic, I was careful to not be "attacking" in my wording. I want to know what I did wrong so that I can correct it in the future. Thank You.

Re:Religion

[morgan_greywolf]

One word. PowerShell.

That is all.

Re:Computer languages evolve like natural language

[Anonymous Coward]

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/

Re:Religion

[DragonWriter]

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.

Re:Religion

[mangu]

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

Holy moly, that's a lot of buzzwords

[MoxFulder]

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

Re:Holy moly, that's a lot of buzzwords

[marcosdumay]

"they allow you to code easily and clearly"

Ok...

"to debug quickly"

Check

"and to expand from simple scripts to complex systems"

Now, something here isn't quite right. They allow your simple scripts to expand into a huge unmaintanable mess.

"And they're surrounded by supportive developer communities and code libraries"

That is ok too.

So, 3 out of 4. That is why they are usefull, and why they aren't a silver bullet.

Re:Holy moly, that's a lot of buzzwords

[MoxFulder]

"and to expand from simple scripts to complex systems"

Now, something here isn't quite right. They allow your simple scripts to expand into a huge unmaintanable mess.

I don't agree in general... I think this is very language-dependent and human-dependent. My Perl codebases got completely unmaintainable as they grew, but with Python I haven't had any problems scaling to thousands of lines of code. Partly I think I've gotten to be a more disciplined programmer, partly I think Python's a better language for scalability.

So, 3 out of 4. That is why they are usefull, and why they aren't a silver bullet.

Well I'd say 4 out of 4, but I agree they aren't a silver bullet :-)

Memory and CPU overhead, and difficulty of distributing complex programs and modules in a standardized way... those are the issues I have with dynamic languages.

Re:Holy moly, that's a lot of buzzwords

[kdemetter]

Now, something here isn't quite right. They allow your simple scripts to expand into a huge unmaintanable mess.

You are right , but that depends on the developer , not on the scripting language itself.

I'd submit a bug report , but i don't know the URL of God's bugtracker.

Re:Holy moly, that's a lot of buzzwords

[home-electro.com]

but with Python I haven't had any problems scaling to thousands of lines of code. Partly I think I've gotten to be a more disciplined programmer, partly I think Python's a better language for scalability.

Thousands lines of code is not scalability -- it is still a tiny application. With a bit of discipline easily maintainable in any language, including Assembler.

You don't encounter scalability issues until you reach 100 000 lines code or more.

Re:Holy moly, that's a lot of buzzwords

[l0b0]

I think this is very language-dependent and human-dependent. My Perl codebases got completely unmaintainable as they grew, but with Python I haven't had any problems scaling to thousands of lines of code.

s/thousands/millions, and see where that gets you. At all of my three last jobs we had code bases in that range, from literally decades of development (hundreds to thousands of work years), and the code bases were surprisingly easy to navigate. I'm not saying it can't be done in Python, but I think it's much more human that language dependent.

Re:Holy moly, that's a lot of buzzwords

[doom]

My Perl codebases got completely unmaintainable as they grew, but with Python I haven't had any problems scaling to thousands of lines of code. Partly I think I've gotten to be a more disciplined programmer, partly I think Python's a better language for scalability.

And Python also helped you get to thousands of lines of code so much faster!

Re:Holy moly, that's a lot of buzzwords

[paradoja]

You have to take into account that the code length in script languages will be much shorter than with compiled ones... and that's a huge plus for scallability.

Re:Only ONE script matters --THE BIBLE

[Anonymous Coward]

This is inaccurate. There's no way we would bother with the robes and hoods.

Re:Computer languages evolve like natural language

[Fnordulicious]

It's nice that you think, but your opinion is merely subjective. Enjoy your subjective correctness. But feel free to come back when you have observable data with replicable analyses.

PowerShell will rule them all

[daveb]

Don't make Steve reach for a chair now!!

Besides - it's got a cool blue screen

PowerShell FTW

Re:Computer languages evolve like natural language

[Fnordulicious]

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.

Re:Computer languages evolve like natural language

[belmolis]

Panini's grammar, the Ashtadhyayi, is quite different from the European grammars mentioned. It is a true generative grammar, consisting of a set of rules in a formal language that generate all and only the grammatical sentences of Sanskrit. Nothing like it was created in the West until Chomsky's work on generative grammar. Even now, Panini's grammar is more detailed and comprehensive than most formal grammars of natural languages.

Re:Computer languages evolve like natural language

[turbidostato]

"Panini's grammar, the Ashtadhyayi, is quite different from the European grammars mentioned."

On one side, the point was that "It wasn't until the Europeans discovered Sanskrit in the 18th century until European languages had any formal grammar.". Well, it isn't: almost as soon as there were printed books and as soon as the XV-XVI there's an obvious interest on formalize those recently created latin derivatives talked in Europe. But even regarding the pure intellectual effort about formalizing -not just exposing, language rules, you can see for example, 1587's work from Francisco Sánchez de las Brozas who genuinely studies the internal formal rules of sentence generation. If your point is that a work from the XVIII is more deeper and advanced than one from the XVI, well, news at eleven but that we have to wait to it for an interest on formalizing European languages, sorry but no.

Re:Computer languages evolve like natural language

[belmolis]

No, my point is that the grammars you mentioned are not formal grammars as you seem to think. Europeans only started serious work on formal grammars in the mid-twentieth century.

Malda

[heffrey]

If Malda was "one of the founders of Slashdot", who were the others?

Re:Malda

[prockcore]

Pestilence, Famine and War.

Re:Religion

[chthon]

Three : portability of programs between Linux, Solaris, Unix, cygwin and Win32.

WTF is a BNE?

[Viol8]

Stop trying to appear clever by using acronyms no one understands.

Re:WTF is a BNE?

[Ngarrang]

Stop trying to appear clever by using acronyms no one understands.

You don't understand the assembly equivalent of GOTO? You must never have touched assembly, then. Though, to be fair, when I did VAX Assembler, I did not use BNE.

Re:WTF is a BNE?

[Anonymous Coward]

This is what happens when universities start teaching toy languages instead of real skills like C & assembly.

BNE = Branch No Equals I.e. jump to a new location if the "Equals" status flag is not set. Better? Or do I need to explain "jump" and "status flag" to you, too?

P.S: I'm assuming psuedo-assembler here, not any particular ISA where the specific acronym for that mnemonic may or may not be Branch No Equals.

Re:WTF is a BNE?

[Anonymous Coward]

In what assembler exactly?

The 6502, VAX, Sparc, ARM...etc. etc.

In X86 I think you'll find its called "jne"

That's right, because it's well known that IA32 is the only ISA in the world. Try using Google some time.
Super Mega-Bonus Tip: It's "assembly". The assembler is the program that converts the assembly into binary.

Re:WTF is a BNE?

[An ominous Cow art]

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.

Re:WTF is a BNE?

[home-electro.com]

Man, that is so arrogant. It is different in every assembler. In PIC asm it is GOTO.

Re:WTF is a BNE?

[Viol8]

Btw loser , I've karma to burn , so keep getting your sad little friends to mod me flamebait and see where it gets you.

Re:WTF is a BNE?

[smithmc]

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.

Right, because x86 and Z80 are the only two CPUs in the entire world, right? Arrogant much?

There was no mention of Lua because...

[Viol8]

... its used in niche areas (yes , games are a niche compared to the rest of the computing world) and its reach is microscopic in comparison to other scripting languages. As for its use in embedded devices, yeah right, name some.

Please. Cut with the 'scripting' nonsense

[unity100]

today's, for example, php apps are so complex and big that you can hardly call them 'scripts' anymore.

better term is open code programs running through a compiler.

And Tcl

[Anonymous Coward]

Note that Tcl 2008 will start next week
(October 20) in Manassas VA. See:
http://www.tcl.tk/community/tcl2008/

For details. The conference features tutorials, as well as talks ranging from Tcl's use in environmental nuclear physics to intelligent agent plugins for Skype.

For those not able to make quick travel arrangements to attend, a live A/V feed will be provided. Watch for the link to the feed at:

http://wiki.tcl.tk/21712

Re:Religion

[morgan_greywolf]

Don't look at me! I use bash, Tcl, Python and Perl for all my dynamic language scripting needs. He wanted a native Windows thing. WSH sucks. VB isn't even a dynamic language. PowerShell is at least passable.

Re:Computer languages evolve like natural language

[Anonymous Coward]

Jackass.

It's all about the "other code"

[Sloppy]

His points 2 and 3:

2. Frameworks are becoming even more dominant. Some people identify themselves as Django developers even though they're writing Python code. Ruby has been around for years, but it didn't become a rock star until it was matched with the Rails framework.
...
3. Applications are becoming their own worlds. There are 23 job listings for WordPress developers. While the WordPress plug-ins will be written in PHP, the programmers will rely heavily on the standard set of libraries included in WordPress. Is it fair to say that the coders are working in PHP, or are they really working in WordPress?

Learning a language is trivial compared to learning its standard libraries and/or the existing code inherited as part of a legacy project that you have to maintain. I mean, sheesh, the language is nothing. Learning what has already been written (so you don't have to) and figuring out how to call it, is what it's all about. Learning a language takes a week or two. Learning a big library can take months, maybe even years.

BTW, since when is Python "core savvy?" Lack of easy parallelism (other than forking new processes) has been one of python's biggest problems. Or at least I thought so. I must not be keeping up.

Re:Computer languages evolve like natural language

[SputnikPanic]

That's an interesting assembly of years there.

1453 - Constantinople falls, bringing the end of the Byzantine Empire. (Looks like that Greek grammar was printed just in time!)

1492 - Columbus and the whole ocean-blue thing; completion of the Reconquista in Spain.

1529 - Protestantism gets a shot in the arm with the Diet of something or other whose name escapes me.

1536 - Henry VIII's wild year: Catharine of Aragon dies, Anne Boleyn loses her head, Henry hooks up with Jane Seymour.

1550 - Um, never mind. Totally blanking on 1550...

LOL! Modded down for telling the truth?

[Anonymous Coward]

Well, will wonders NEVER cease:

I was 'modded down', no less as "offtopic" (how I am "off topic" here, truly astounds me! After all - I am on the topic of javascript you know... &, just for telling the truth of the downsides of javascript, with backing documentations no less from reputable sources as well, you /.'ers modded my post down)...

"Unbelievable!"

(Thanks for making me laugh though, whoever modded me down & w/ out an explanation no less - if you can't handle the truth though? That's NOT my problem - it's yours)

APK

P.S.=> Javascript devs - whether you LIKE IT, or not? What I wrote up there is not up for dispute, & completely truth. I posted it, & only meant to help out those who are being stomped on by those that misuse your web-page scripting "weapon-of-choice" (& I use it myself doing ASP.NET work mind you, & I don't like the facts I put out, but they are nevertheless, facts)...

So - Get over it guys, your scripting language stinks for security!

(Now, hopefully, more of you will "sound off" about it, & something will eventually get done regarding its downsides (like javascript being used in attack after attack (more like 90% or more of them lately) for nearly 1/2 a decade now online))... apk

Re:Computer languages evolve like natural language

[cparker15]

John and I went to the store. The clerk said "hi" to John and me.

Re:Computer languages evolve like natural language

[ratboy666]

And you are wrong.

Ruby models natural language/thought more closely than PHP. It can even model "meta-linguistic abstraction". Which is also possible in PHP, but much more difficult.

PHP starts off SEEMINGLY SIMPLE, but then shows it nasty warts gradually. Ruby tends to be up-front with the whole mess.

Indeed, this discussion is very old -- witness LISP vs $PICK_A_LANGUAGE over the years.

Indeed, this is the very point that makes Python preferable to Perl, I would say your argument would get much more interesting if you compared and contrasted Python to Ruby.

But you are still blinded by the apparent "niceness" of PHP; just remember these words when you are ready for the next step in enlightenment.

Re:Religion

[adonoman]

CPAN is definitely a valid reason, a bigger one is portability. But the text vs object thing is really a point against Perl. The text-parsing stuff is still there in PowerShell, only if the small-script you're are calling supports it, you get an object stream back. You can convert it to text if you really feel the need, but knowing that $_.ProcessName is always going to refer to the Process name is way better than having to find column 5, and trust that the script's author hasn't rearranged things on you.

Re:Computer languages evolve like natural language

[Just Some Guy]

Yep. "I" is the subject of the first sentence, and "me" is the object of the second.

Re:Computer languages evolve like natural language

[Tablizer]

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.

I've heard claims like this from various language proponents, but haven't seen any definitive illustrations. Do you have any code examples of PHP hitting an un-fixable wall?
       

Re:strict/weak static/dynamic typing

[bishop's farewell]

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.

Strict/weak and static/dynamic are separate and orthogonal properties of languages.

Static typing means types are determined at compile time, as in C/C++, Java, Haskell, etc. Dynamic typing defers type checking to run time, as in Perl, Python, Erlang, etc.

Strict typing means that the type system cannot be "bent" by things like casts and unions in C, or by behind-the-scenes type conversions in Perl.

C is statically and weakly typed. Perl is dynamically and weakly typed. Python is dynamically and (fairly) strongly typed. Haskell is statically and strongly typed.

Re:Computer languages evolve like natural language

[Anonymous Coward]

but because almost purely becuase

and it doesn't really help if they are objects are not.

one that is at its core, hacked together,

It wasn't until the Europeans discovered Sanskrit in the 18th century until European languages had any formal grammar.

Yours appears to have missed that discovery.

Re:Only ONE script matters --THE BIBLE

[kdemetter]

You seem to be mixing up atheism with christianity.
Just replace atheist with christian , and it makes a lot more sense , it even becomes historically relevant.

Atheists don't give a fuck about what other people believe. They just don't like it when people force their religion on others.

I'm pretty sure most atheists have higher moral standards than religious people , simply because they don't have a holy book to hide behind.

Off course , your post could have been sarcastic, and in that case , you won't mind this post.

Re:Religion

[kdemetter]

to summarize , most wars are based on greed.

In the case of religions , i noticed the following:

At the start of religions , the religion is usually fought against by the powers that be. At that moment the religion is often peacefull , caring , and serves a general good.

Then the religion becomes accepted, and eventually becomes mandatory. At that point the religion becomes dogmatic , abusive , and serves basically to enslave people.

It all begins spiritually , with best intentions.But then power and greed corrupts it , and uses it to bend the people's will.

So , if you seek spirituality , you can only find it by seeking it all by yourself, not by someone else tells you to do.

One of my favorite quotes :

religion is regarded by the common man as true , by the wise as false , and by the rulers as useful.

Re:Religion

[dwarfsoft]

I guess you must have a different concept of the word "Native" than I do ;)

Lets assume that we have a "Vanilla" installation of Windows XP... how well does PowerShell work compared to VBScript?

Considering that I have absolutely no control over what is installed on about 90% of the PCs in the organisation, and that I am rolling out scripting solutions to all PCs, that means that I am limited in choice to using either VBScript or WinBatch (or JScript... no thanks).

Re:Computer languages evolve like natural language

[paradoja]

Formal grammars have little to do with natural languages...

Just think if you were speaking Croatian

[Latent Heat]

John, you, the store, and the clerk would all have different word endings in each of the example sentences. I am told Serbo-Croatian has seven of these noun endings, and Latin and Greek are up there as well.