Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Perl Programming IT Technology

10 Forces Guiding the Future of Scripting 190

snydeq writes "InfoWorld examines the platforms and passions underlying today's popular dynamic languages, and though JavaScript, Perl, PHP, Python, Ruby, Groovy, and other scripting tools are fast achieving the critical mass necessary to flourish into the future, 10 forces in particular appear to be driving the evolution of this development domain. From the cooption of successful ideas across languages, to the infusion of application development into applications that are fast evolving beyond their traditional purpose, to the rise of frameworks, the cloud, and amateur code enablers, each will have a profound effect on the future of today's dynamic development tools."
This discussion has been archived. No new comments can be posted.

10 Forces Guiding the Future of Scripting

Comments Filter:
  • by Anonymous Coward on Monday October 13, 2008 @05:33PM (#25362333)

    And twitter.

    • by MoxFulder ( 159829 ) on Monday October 13, 2008 @10:58PM (#25364763) Homepage

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

      • "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: (Score:2, Insightful)

          by MoxFulder ( 159829 )

          "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

          • by l0b0 ( 803611 )

            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.

          • by doom ( 14564 )

            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!

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

  • 10 forces? (Score:5, Funny)

    by CaptainPatent ( 1087643 ) on Monday October 13, 2008 @05:35PM (#25362351) Journal

    though JavaScript, Perl, PHP, Python, Ruby, Groovy, and other scripting tools are fast achieving the critical mass necessary to flourish into the future

    I didn't read the article, but from the summary I'll assume one of the forces is gravity.

    It's too bad it's such a weak force.

    • Re: (Score:2, Informative)

      by 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? (Score:4, Informative)

        by fm6 ( 162816 ) on Monday October 13, 2008 @06:11PM (#25362727) Homepage Journal

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

      • Re:10 forces? (Score:5, Insightful)

        by pimpimpim ( 811140 ) on Monday October 13, 2008 @08:47PM (#25363999)

        A quick skim over the bloody summary shows that this is a "don't read the f-ing article" if there ever was one: "co-optation", "infusion of application development", "fast evolving beyond their traditional purpose", "the cloud", "code enablers".

        I use perl daily, python when I need OO, and hack together most time-savers with bash. Like people did before me since the Bourne shell came out in 1977, and the more complicated scripting languages after that. In 30 years, people will probably still be doing the same. The only thing that might change is that more and more programs that are not depending on performance, might be completely written in scripting languages. As far as my work is concerned, the factor 20 or more speedup I get by actually programming in C will always be of use. It's not like we want to do the same with tomorrow's computing capacity as we can do now, we want to do more!

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

        • by doom ( 14564 )

          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.

  • Fast javascript (Score:5, Interesting)

    by cornicefire ( 610241 ) on Monday October 13, 2008 @05:40PM (#25362433)
    Does anyone know of a project to bring some of the fast Javascript implementations like V8 to the server? It could be like PHP or Perl, only very fast-- if the numbers hold out. I would like to write in the same language on the client and the server. (Java almost achieved that...)
    • Re: (Score:2, Informative)

      by JPortal ( 857107 )

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

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

    • Re: (Score:2, Insightful)

      by brezel ( 890656 )

      seriously, i am trying not to troll here but why would i want to use a language with no strict typing on the server to generate html+js text when i can use lots of great languages with typing that can do that very well and are not scripting languages? o.O

      maybe i am missing the point here.

      • Re: (Score:2, Insightful)

        by gbjbaanb ( 229885 )

        from TFA:

        And then there are others who see languages such as JavaScript rising from the browser and colonizing the server. A unified platform makes everything simpler. Yes, Netscape wanted this to happen years ago, but thanks to the lightning performance of the new JavaScript semi-compilers, the language is bound to look even more attractive.

        See, MS crushed your dreams too :-)

      • Re: (Score:3, Interesting)

        by abigor ( 540274 )

        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.

        • 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

          • 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 injectio

            • by Allador ( 537449 )

              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 trivi

              • 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 ri

                • by Allador ( 537449 )

                  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 de

        • by l0b0 ( 803611 )
          What To Know Before Debating Type Systems [pphsg.org]. Interesting read.
    • Re:Fast javascript (Score:5, Interesting)

      by Cyberax ( 705495 ) on Monday October 13, 2008 @06:03PM (#25362643)

      Java HAS achieved that. See Google Web Toolkit - it compiles Java to _JavaScript_ which is executed inside your browser.

      IMHO, it's THE best toolkit for rich AJAX applications now.

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

      • by dgatwood ( 11270 ) on Monday October 13, 2008 @07:12PM (#25363225) Homepage Journal

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

        • 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

          • by dgatwood ( 11270 )

            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 JavaSc

        • 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? [parrot.org] Don't know about replacing Javascript clientside, though.

    • Re: (Score:3, Informative)

      by destiney ( 149922 )

      Ruby on Rails' RJS templates is exactly that. You write Ruby that is translated into Javascript calls. I've written a number of Javascript-driven Ruby on Rails apps without ever having written a single line of actual Javascript. You get a "page" object which represents the DOM, simple as can be.

      http://www.google.com/search?q=rjs+templates [google.com]

    • Re: (Score:3, Informative)

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

      Rhino [mozilla.org]
      Attila Szegedi [szegedi.org]
    • by Inda ( 580031 )
      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?
    • by sorak ( 246725 )

      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
      {

  • hey ho. (Score:5, Interesting)

    by apodyopsis ( 1048476 ) on Monday October 13, 2008 @05:49PM (#25362523)
    I write embedded firmware for my job (predominantly C) - my code is tied to the hardware, I frequently code real-time stuff in assembler to get the maximum speed. I have no OS, and I write all the ISRs and schedulers myself.

    On the other end of the spectrum is a friend of mine who is language and platform agnostic. Sways between a bunch of scripting languages on a number of operating systems and has probably never compiled an application in his life, interpreters are his tools.

    My point - if there is one - is that each to their own, there will always be a requirement for different skill sets. In a way, software is software regardless of the language it is coded in. The same rules apply.

    I love doing clever stuff with pointers (except when it goes wrong in style), and using neat mathematical tricks in assembler to speed up fixed divisions and run stuff faster - but as the same time when knocking up a test rig on a PC I can honestly appreciate stuff like a "foreach".

    Hey ho. Ramble Ramble.
    • Or even a "for" loop, if you still have to program in C90. I suppose while loops is still better than BNEs though...
  • by fahrbot-bot ( 874524 ) on Monday October 13, 2008 @05:50PM (#25362535)

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

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

  • by Anonymous Coward on Monday October 13, 2008 @05:57PM (#25362585)

    I'm surprised there was no mention of Lua [lua.org]. Besides Javascript, Lua is probably the most widely used scripting language out there. Usually its use is hidden from the end-user but it's in everything from embedded devices to World of Warcraft.

    It has a very simple design and is very fast (especially with LuaJIT). The semantics are similar to Javascript but Lua is a lot more pure and simple. There probably will never be a Javascript engine as fast as the fastest Lua engines.

    • by xant ( 99438 )

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

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

  • Clueless. (Score:5, Informative)

    by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Monday October 13, 2008 @06:00PM (#25362607) Journal

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

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

    • Re:Clueless. (Score:5, Informative)

      by ShadowRangerRIT ( 1301549 ) on Monday October 13, 2008 @06:04PM (#25362665)
      I assume they mean some flavor of Perl 5, since the Perl didn't have objects prior to Perl 5. And Perl 5 released several years after Python.
      • Re:Clueless. (Score:5, Informative)

        by RDW ( 41497 ) on Monday October 13, 2008 @06:36PM (#25362941)

        'I assume they mean some flavor of Perl 5, since the Perl didn't have objects prior to Perl 5. And Perl 5 released several years after Python.'

        Indeed. According to Larry:

        'After Tcl came Python, which in Guido's mind was inspired positively by ABC, but in the Python community's mind was inspired negatively by Perl. I'm not terribly qualified to talk about Python however. I don't really know much about Python. I only stole its object system for Perl 5. I have since repented.'

    • by Bill, Shooter of Bul ( 629286 ) on Monday October 13, 2008 @06:16PM (#25362783) Journal
      I'm guessing that he meant to say " when Larry Wall decided to add an object system to Perl". As the Objects weren't added until 1994. So that's when the nabbing probably occurred. Well, either that or Larry Wall has an unpublished update to Physics::Lorentz.

      perl history [wikipedia.org]
    • Still Clueless (Score:5, Insightful)

      by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Monday October 13, 2008 @06:49PM (#25363069) Journal

      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

      • by chthon ( 580889 )

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

        • 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 [umbc.edu] -- 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 c

      • 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 [codehaus.org] 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.

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

          • 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.
  • 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
    • by siride ( 974284 ) on Monday October 13, 2008 @06:42PM (#25362985)
      As someone with a BA in Linguistics, I call BS on the natural language part of your post. The biggest mistake you have made is that you failed to distinguish between written grammar guides, and an actual grammar for a language, which is in each person's head and is quite complete and well-formed. So much so that we have yet to fully elucidate the complexities therein.
    • by turbidostato ( 878842 ) on Monday October 13, 2008 @06:47PM (#25363045)

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

      Well, sure... It's only that the first printed greek grammar is from 1453; the first modern grammar, the Spanish one from Nebrija, dates from 1492; the first Italian one, that of Trissino, is from 1529, the Portuguesse one from Fernando de Oliveira is from 1536 and the French one from Louis Meigret was published on 1550.

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

        • "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 ex

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

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

    • 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 lear

    • Re: (Score:3, Informative)

      PHP is no more like a natural human language than any other programming language. Did you never learn about the Chomsky hierarchy in your computer science classes? All programming languages are formal languages as they are at least regular languages. However it is not known whether human natural languages (or any other conceivably similar natural language) are entirely translatable to any formal language. The two cannot be assumed to be comparable until this can be proven, and as far as linguistics goes we'

  • by jamrock ( 863246 ) on Monday October 13, 2008 @06:15PM (#25362773)

    Oh. My. God.

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

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

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

  • Don't use the forks, Luke (or Larry, or Guido, or Rasmus)
  • 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*

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

    Besides - it's got a cool blue screen

    PowerShell [microsoft.com] FTW

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

Truly simple systems... require infinite testing. -- Norman Augustine

Working...