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?

[fm6]

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

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

[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

[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

[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

[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

[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

[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

[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?

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.

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

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

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.

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.

Re:Religion

[morgan_greywolf]

One word. PowerShell.

That is all.

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

[I cant believe its n]

Low energy nuclear reactions are useless when scripting

Re:Religion

[chthon]

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

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.

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.

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

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

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

[cparker15]

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

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

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?

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.