Follow Slashdot stories on Twitter


Forgot your password?
Perl Programming

Why JavaScript Is the New Perl 453

theodp writes "'People are thoroughly excited [about JavaScript],' writes Lincoln Baxter. 'However, I'd akin this to people discovering Perl during the advent of C and C++ (mirror). Does it work? Yes. Is it pretty? Not by a long shot.' Baxter adds, 'While I do like both languages, JavaScript [is] just waiting for the next technology to come around and make it look like Perl does today: pervasive, but lacking enterprise adoption on large applications.'"
This discussion has been archived. No new comments can be posted.

Why JavaScript Is the New Perl

Comments Filter:
  • What. The. Fuck? (Score:3, Insightful)

    by Anonymous Coward on Sunday January 06, 2013 @06:47PM (#42498851)

    What is this? Slasdot's daily troll story?

    capcha: manure. How appropriate.

    • by oodaloop ( 1229816 ) on Sunday January 06, 2013 @06:48PM (#42498859)
      Yeah, like there's only one troll story a day. You must not check very often.
    • Yep. It even has the obligatory mention of C++ to lure the little fishes in.

      (comparing a web scripting language with an adult language like C++ makes no sense anyway...)

      • Nah - I chalk it up to incompetence this go 'round.

        If they really wanted to troll, they'd chuck in a mention of how they should use it instead of C to write the FreeBSD kernel, or say that JS is somehow going to replace .NET.

        (/me ducks and runs like hell...)

  • Readability (Score:3, Insightful)

    by Anonymous Coward on Sunday January 06, 2013 @06:50PM (#42498887)

    One thing BASIC did right was make it easy to read, this despite being procedurally oriented and allowing for spaghetti code using multiple GOTO statements instead of using subprocedures using GOSUB/RETURN.

    Newer languages look more like obfuscated math in an OO context. Perl, JavaScript, Ruby, even Python have an element of unreadability to them--if not well commented, then I'll often need to consult an online reference or reference book to understand exactly what is going on. C++ using templates becomes just as unreadable.

    It's ridiculous, if you think about it. I don't have to consult a dictionary every few words I read or write of a sentence, so why should I have to consult a language reference for every few lines of code I am reading or writing?

    As programmers, we are telling the computer what to do. Why can't the language resemble more readable (English, or native language) rather than obfuscated math.

    And forget functional programming, that is the most obfuscated coding I have ever seen, I can't even read it except in the most trivial of cases.

    • Re:Readability (Score:5, Insightful)

      by Anonymous Coward on Sunday January 06, 2013 @07:06PM (#42499013)

      One thing BASIC did right was make it easy to read, this despite being procedurally oriented and allowing for spaghetti code using multiple GOTO statements instead of using subprocedures using GOSUB/RETURN.

      LITTLE-KNOWN FUN FACT: If you write Perl correctly, it's also perfectly readable, despite all its odd quirks and allowing for spaghetti code using obscure modules and abuse of the single-character special variables.

      I know! It's hard to believe that such an amusing stereotype spread so much by programming trendwhores who don't know what they're talking about could possibly be wrong! What an impossibly weird world we live in!

      • Scenario, im new to perl. Would you consider this simple sort of subroutines human readable?:

        @s = sort mycriteria @a;
        sub mycriteria {
        my($aa) = $a =~ /(\d+)/;
        my($bb) = $b =~ /(\d+)/;
        sin($aa) sin($bb) ||

        • Err, it would be if you, like, you know... commented a little in the damned thing. ;)

        • First of all, that's not even valid Perl. You can't write "sin($aa) sin($bb)" or "$aa*$aa $bb*$bb" because the space character is not an operator (in AWK, it's the string concatenation operator in certain contexts).

          Second, the assignments to $aa and $bb are confusing because you left out parentheses around the right-hand side. This is not Perl's fault; it's the author of the code's fault that it's confusing. It would be much clearer as:

          my ($aa) = ($a =~ /(\d+)/);

          Third, what the hell is this code trying to d

      • Hellfire; if you write .NET or even PowerShell correctly it's perfectly readable. If you comment it correctly it can be perfectly maintainable, too (well, for as long as all the parts are non-obsolete, anyway).

        But noOOoo.... everyone's gotta be the cleverest mofo in the effing room, forgetting all about the poor slob who has to maintain the damned thing 2 years later...

    • Have you ever noticed how many people write English well? On top of that, there's writing well, and writing concisely. Where one person may get an idea across clearly in two sentences, it may take another five or six. Any language will have the same problems to varying degrees; the trick is to coax people towards being concise.

      • by AuMatar ( 183847 )

        But conciseness isn't always the right goal. Take legalese- it's very concise. That's why its used. It isn't readable. Or take perl- people can do an awful lot in 1 line, but nobody can understand it without really studying it. Doing it in 5 or 6 lines instead can be much more readable, and thus maintainable.

        • Legalese is very far from concise. That's part of the problem with it. If it was more concise and was frequently refactored, the law would be much shorter and easier for the average person to understand.

          • by AuMatar ( 183847 )

            No, it is *VERY* concise. Specific words have an extremely specific meaning, and new concepts are defined in detail. That's why it reads the way it does. Writing it in plain english would take 5 or 6 times the amount of space to mean the same thing.

            • I find it's way too open to interpretation to be described as concise. Precedent based law would not be required if it were actually concise.

    • Re:Readability (Score:5, Insightful)

      by Hentes ( 2461350 ) on Sunday January 06, 2013 @07:15PM (#42499069)

      For many of us, math is easier to read than human language. Language is inherently inaccurate, and terrible at describing complex algorithms. The problem with syntax isn't that it doesn't look like human language, otherwise everybody would be using Smalltalk. But when a piece of code can be written in too many ways (and there isn't a simple "obvious" way to guide programmers), it becomes hard to understand code written by someone who thinks differently. One solutions to this is to limit the language to a single style like Java does, which forces all programmers to write similar code, making it easy to understand what others have written. Now of course there are people who can write ugly code in any language, and there's no way to eliminate that, but most coders are lazy, and if a language makes it easy to write nice code and hard to write ugly code, they will choose the former. The tradeoff is that these languages are more rigid and less costumizable.

    • by Alomex ( 148003 )

      Newer languages look more like obfuscated math in an OO context. Perl, JavaScript, Ruby, even Python have an element of unreadability to them--if not well commented, then I'll often need to consult an online reference or reference book to understand exactly what is going on.

      I noticed this the first time I opened the source code of a simple Python application. It was very hard to decode what was going on, even though I'm proficient in Basic, C, C++, Pascal, Algol, Perl, Lisp, ML, awk, csh, matlab, prolog, logo, Ada, Cobol, TeX/LaTeX, postscript, scheme. You'd figure that those should be enough to interpolate the meaning of any program in a reasonable language.

      • Really? Python reads so much like English that it's really clear. It may be because you are an existing programmer - I have found those that come into Python from other languages tend to fight the language a lot, and are so used to conventions from other languages, they have problems with Python as it doesn't follow them.
    • Re:Readability (Score:4, Interesting)

      by Animats ( 122034 ) on Sunday January 06, 2013 @07:50PM (#42499267) Homepage

      Why can't the language resemble more readable (English, or native language) rather than obfuscated math.

      Because page after page of MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN really sucked. put background field "name" of card n of background "data" after card field "list" wasn't much better.

      The problem with Javascript is not that you can't write good Javascript programs. Javascript has an adequate feature set, the syntax is no worse than C, and reasonably fast implementations are available. It's that the language encourages the writing of bad code, which then has to be debugged by others. Object-oriented programming was retrofitted into Javascript, and it shows. Typical bad Javascript has global variables that should be local, shared data that should be in closures, no proper objects, and no comments.

    • Re:Readability (Score:5, Insightful)

      by M. Baranczak ( 726671 ) on Sunday January 06, 2013 @08:36PM (#42499547)

      Why can't the language resemble more readable (English, or native language) rather than obfuscated math.

      Because natural languages and programming languages are intended for completely different tasks. Do I really need to explain this?

  • by Animats ( 122034 ) on Sunday January 06, 2013 @06:51PM (#42498891) Homepage

    It's 2013, and someone is discovering Javascript?

    • by rwyoder ( 759998 )

      It's 2013, and someone is discovering Javascript?

      Just wait until tomorrow when they discover Livescript.

  • Very Different (Score:5, Insightful)

    by hibiki_r ( 649814 ) on Sunday January 06, 2013 @06:52PM (#42498903)

    Perl was exciting because it provided a lot of power without having to be as low level as C. It's still a useful, albeit not all that pretty language. Javascript is used a bunch of one reason only: It's the only thing you can sensibly run in a web browser without an iffy user experience. Large chunks of the language are horrible, and while it has enough decent bits to do real work on, you won't find that many people that wouldn't wish for the languages said bits were taken from. I mean, if people actually liked the language, would we find things like Coffeescript and objective-J out there?

  • by NoKaOi ( 1415755 ) on Sunday January 06, 2013 @06:55PM (#42498925)

    pervasive, but lacking enterprise adoption on large applications

    Seriously? How many enterprise level web based sites/applications are there that don't use JavaScript vs. do use JavaScript? I know, you're going to argue that the whole thing isn't entirely based on JavaScript, but seriously, wouldn't you say enterprise adoption is pretty darn high?

    • by rduke15 ( 721841 )

      Anyway, what does he mean by "enterprise adoption"? Neither Javascript nor Perl were conceived "for the enterprise".

      They were both conceived to make it easy to do simple things. One in web pages on the client, the other in anything with a CLI, even your toaster (if you have a decent toaster, which would have a CLI).

      (Perl added to the "make simple things easy" the "and difficult things possible".)

      I'm not sure what "for the enterprise" really means, but I'm pretty sure that if that is how I perceive a languag

    • by Hentes ( 2461350 )

      You might want to read that sentence again. The part you quote is about Perl, not Javascript.

  • by Kjella ( 173770 ) on Sunday January 06, 2013 @06:55PM (#42498927) Homepage

    HTML/CSS is a fair text markup language, it's a horrible tool to design user interfaces
    JavaScript is a fair way to make small DOM scripts, it's a horrible programming language.

    But with a big enough hammer called the World Wide Web, you can make a square peg fit a round hole.

    • by Piata ( 927858 )
      As a web designer, I'm not sure I understand your gripe about HTML/CSS being a horrible tool to design user interfaces. Typically I design my interface in Photoshop and then create it using HTML/CSS, which is suprisingly good at this sort of thing and only getting better. I've designed things on multiple platforms in the past and I prefer the HTML/CSS method.
  • Atwood's Law: "Any application that can be written in JavaScript, will eventually be written in JavaScript."
  • Modem noise (Score:4, Informative)

    by frisket ( 149522 ) <peter@[ ] ['sil' in gap]> on Sunday January 06, 2013 @07:01PM (#42498981) Homepage
    Yah. And Perl still looks like modem noise. Python is even worse. But JavaScript is like someone on acid tried to breed a zombie computer language in his basement.

    But, hey, lots of people like them, so they must be good, right? []

    • Re:Modem noise (Score:5, Informative)

      by hobarrera ( 2008506 ) on Sunday January 06, 2013 @07:13PM (#42499063) Homepage

      I've heard many respectable criticisms of Python, but I've never heard anyone say it looks bad.
      Visually, it's probably the most elegant-looking language there is.

    • Yah. And Perl still looks like modem noise.

      Try programming in TECO []:

      It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text. One of the more entertaining games to play with TECO is to type your name in as a command line and try to guess what it does. Just about any possible typing error while talking with TECO will probably destroy your program, or even worse - introduce subtle and mysterious bugs in a once working subroutine.

  • by Baby Duck ( 176251 ) on Sunday January 06, 2013 @07:04PM (#42498995) Homepage

    I came here to call Baxter a troll, especially considering his "lacking enterprise adoption on large applications" comment, but I've already been beaten to the punch. He is living in the year 2000 if he doesn't understand the impact of JSON, jQuery, and Node.js. Perl never brought to the table anything remotely like these.

    Even if something surpasses Javascript, as long as we still use CSS and DOM, jQuery will live on -- just with bindings to this new language. As long as there is demand for a data exchange format that is both human-readable and easy for machines to parse, JSON will not die any more than XML will.

    • by Bob9113 ( 14996 ) on Sunday January 06, 2013 @08:04PM (#42499361) Homepage

      JSON, jQuery, and Node.js. Perl never brought to the table anything remotely like these.

      I like both languages, and prefer others to either of them. Not trying to knock Javascript or blow sunshine up Perl's skirt, and I don't know if Baxter has a clue, but your statement is not correct. Perl's eval, CPAN, and mod_perl are the Perl equivalents, respectively. They do pretty much the exact same thing (except CPAN; it's actually *much* more extensive than jQuery, and has no equivalent in Javascript that I am familiar with). The only difference, as noted by many people already, is that the Javascript versions work consistently across web browsers, so their usage is more pervasive on the client side. Not necessarily better or worse based on that evidence alone, just more pervasive. Server side, there's a solid half decade of work ahead for Javascript to be in the same ballpark on infrastructure support as Perl.

      • by dodobh ( 65811 )

        node.js is an event driven server for Javascript. A better Perl example would be POE. Of course, POE has a lot more modules and options.

  • I'm not worried (Score:4, Insightful)

    by RedHackTea ( 2779623 ) on Sunday January 06, 2013 @07:07PM (#42499025)
    It's not Delphi (thank god), and VBScript should have died a long time ago, but it's still around. And if you know JavaScript, you're more than likely safe and knowledgeable enough to learn the next web browser language (which will probably be very similar to JavaScript). Every programmer knows that you learn a few different languages, and that they come and go. You just have to adapt. When I was younger, C++ was the shit. Then Java came along, and it was an easy adjustment/transition.

    I also find the "is it pretty?" question a little subjective. If someone writes bad code, it's ugly in any language. For a scripting language, JavaScript is fine and gets the job done. You don't have to worry about one line of code breaking and bringing down your entire site. Scripting languages have always been quick and dirty; that's the point. These days I personally prefer Ruby though for my scripting needs (haven't made a site with it using RoR though yet; I write Ruby scripts for my quick&dirty computer needs instead of using Bash, etc.).
  • [...]but lacking enterprise adoption on large applications.'"

    Yeah, it's not like google, facebook youtube and a few other players use it for their frontend.

  • by fahrbot-bot ( 874524 ) on Sunday January 06, 2013 @07:21PM (#42499089)

    JavaScript Is the New Perl

    JavaScript, I use Perl. I know Perl. Perl is a friend of mine. JavaScript, you're no Perl.

    [ My apologies to Senator Lloyd Bentsen []. ]

  • by joss ( 1346 ) on Sunday January 06, 2013 @07:44PM (#42499225) Homepage

    .. is just like leaving an abusive relationship, its all about getting closure.

  • by slew ( 2918 ) on Sunday January 06, 2013 @07:46PM (#42499241)

    So the author of this article likes GWT? Is the future Java on the client side? We used to have java applet clients in the early web-days, but it didn't really go anywhere because it was a pretty much a separate environment which didn't interact with DOM. Right now GWT is really mostly yet another framework that cross-compiles into Javascript. Perhaps the best usage outside of the framework is simply enforcing a statically typed infrastructure on top of JavaScript, at worst it's usage is sort of "lint" for JavaScript.

    Although there's some marginal benefit from a statically typed regime, if this is all that the future requires to be up to snuf for enterprise usage, that's a pretty low bar for the next ECMAScript. They could just add a few checking attributes to the ECMAScript Object prototype to lock-out the dynamic nature of the object and developers could just migrate their "important" code to use this style of object that if they wanted to be "enterprise". You could even decorate these "finalized" objects somehow to hint the ECMAScript JITs to get any performance advantage you might get with statically typed languages.

    Sadly this would eliminate the dynamic type features that make dynamically typed languages more powerful than their statically typed counterparts (although Generics/Templates bridge some of that gap for static languages like Java/C++). Of course with great power comes great responsiblity, and it's possible to write unmaintainable code in nearly every language, but it seems everyone has thier golden bullet to solve the "enterprise" coding problem. I'm usually unimpressed by golden bullets.

  • I've seen far too many developers get excited by Node.js. Boggles my mind, personally, but the idea of a Javascript back-end is coming.
  • by Heretic2 ( 117767 ) on Sunday January 06, 2013 @09:23PM (#42499839)

    So... Node.js, chalked full of easy ways to leak memory (ie don't change default debug console, or use a crappy gzip library) but the ability to write code that runs/renders either on the server or on the client with the same code and low-level libraries to make the decision of the best place to render--ie render same code on server or client--makes JS on the server-side rather attractive. I run, Operations side, over 1000+ websites on a Node.js farm (talking 200-300 mbit/sec of sustained daily web-traffic), and it scales a lot better than PHP from both a templating side (many similar but different sites with inheritance based properties) and from the performance scaling side.

    From a PLT side, yea, JS ain't the best, but it's a defacto web-rendering technology and its use on the server can simplify a lot of things, not to mention that JS in V8 is pretty quick to boot, although it does have heap limitation based around the 32-bit code V8 generates.

    I leave comment readers with a wonderful link: This PLT Life []

  • Perl's purpose (Score:5, Informative)

    by Darinbob ( 1142669 ) on Sunday January 06, 2013 @10:36PM (#42500247)

    Perl wasn't an alternative to C/C++. It became popular because it was a nice replacement for all those other Unix apps, a combination of sh+awk+sed, etc.

  • by drolli ( 522659 ) on Monday January 07, 2013 @12:29AM (#42500849) Journal

    perl has a very specific scope
    js has a very specific scope

    The overlap between the two scopes is not big.

    for tasks in the center of its scope, perl is still the best - filtering some plain text file is just easy in perl. Perl never ran on any browser. but perl ran on pretty much anything else (I used it on DOS)

    And js was never used in a significant extent to filter text files.

    js in not new (so it can not be the "new" perl)

    perl was inteded as an easy to learn extension-mixture-replacemnt of shell,tcl/tk,awk,sed. It still is and it is working well. (although tcl/tk still has something going for it (robustness, easy cross-platform gui)).

    if there is on thing, which would be "the new perl" then it would be php. Most of the www things which would have been written in perl from 1995-2000 now are written in php.

  • I know it's a controversial opinion, but modern JavaScript is OK.

    All modern browsers support the ECMAScript 5 version of JavaScript. That includes a number of useful additions to the language.

    IMHO the most important addition is strict mode. That disables some of the most egregious features of the language, making it harder to shoot yourself in the foot. Strict mode can be enabled for a whole file, or on a function-by-function basis - you just need to include the line "use strict"; (including the quotes) at the top of the file or function. As it's just a string it will be ignored on older JS interpreters making it backward compatible too.

  • by MrKaos ( 858439 ) on Monday January 07, 2013 @09:48AM (#42504037) Journal
    But with regular expression and string handling that perl has in abundance comparing it with javascript seems odd.

    I was forced to develop javascript and I did not like it. My approach was to apply several design patterns (Fowler/GoF) for the project I worked in and found that it was my thinking that was wrong. I adapted and I am convinced that whilst javascript has a lot of crap surrounding it, the core language is quite good, if you use it properly.

    One of the main hurdles I had, was to consider javascript as a browser event language. After a while, it flowed as nicely as C does. Ironically "Javascript; The good parts" is about the same size as K&R's "The C programming language".

Evolution is a million line computer program falling into place by accident.