JavaScript is the new Perl(ocpsoft.org)
ocpsoft.org
JavaScript is the new Perl
http://ocpsoft.org/opensource/javascript-is-the-new-perl
44 comments
Seems like a weird comparison. JavaScript is obligatory and available in all common browsers. It's fairly easy to get started, and even easier to actually accomplish something with it. Not sure if Perl is as accommodating (haven't tried it though).
When all is said and done JavaScript is a very popular language. When you leave a company, having build something fairly complex - If you did your job properly, documented your code and followed common sense, the project will probably live on.
The author also speaks off everyone hating Perl. Is JavaScript really as hated? I don't get that impression at all.
When all is said and done JavaScript is a very popular language. When you leave a company, having build something fairly complex - If you did your job properly, documented your code and followed common sense, the project will probably live on.
The author also speaks off everyone hating Perl. Is JavaScript really as hated? I don't get that impression at all.
Lover of Perl and JavaScript alike here.
It is a weird comparison. The two languages are used in very different ways; I guess the author is saying JavaScript will be supplanted by something nicer, like Perl has been. But Perl hasn’t been. Python and Ruby are cohabitors, not usurpers. A sizable chunk of the web’s infrastructure is still Perl, and that is unlikely to change.
To give you an idea of the language, Perl is very easy to use, and very hard to grok. The language is large and complex, but most of the size and complexity have to do with being as helpful to the programmer as possible. If you use things in a way that seems plausible, your expectations probably won’t be violated. But if you want to deeply understand how something works, be prepared to discover many details you didn’t expect about how the language is silently helping you out.
It’s a relatively painless experience, even if you don’t know a lot of Perl, to glue a few CPAN modules together and get something working. In that respect it’s similar to writing a Node.js application, though the set of Node libraries is, last I knew, laughably small by comparison.
Having maintained both large-scale JavaScript and Perl codebases, I can tell you that it’s much easier to deal with Perl. Having a proper module system is a huge boon, as well as sane handling of types, and some compile-time checking. Perl is dynamic, yes, but types are explicit by way of sigils—in Perl 5, essentially typed dereferencing operators.
The main difficulty in Perl is the same as in any dynamic language: refactoring. It can be a pain to change things, because many of the resulting errors are not checked till runtime. A comprehensive test suite helps with this; Perl’s testing culture is very good, and comparable to that of Ruby. JavaScript developers tend not, in my experience, to write tests.
So not everybody hates Perl, and not everybody hates JavaScript. People who’ve actually used a language tend not to hate it as much as those who haven’t. This article is, in that regard, just plain silly.
It is a weird comparison. The two languages are used in very different ways; I guess the author is saying JavaScript will be supplanted by something nicer, like Perl has been. But Perl hasn’t been. Python and Ruby are cohabitors, not usurpers. A sizable chunk of the web’s infrastructure is still Perl, and that is unlikely to change.
To give you an idea of the language, Perl is very easy to use, and very hard to grok. The language is large and complex, but most of the size and complexity have to do with being as helpful to the programmer as possible. If you use things in a way that seems plausible, your expectations probably won’t be violated. But if you want to deeply understand how something works, be prepared to discover many details you didn’t expect about how the language is silently helping you out.
It’s a relatively painless experience, even if you don’t know a lot of Perl, to glue a few CPAN modules together and get something working. In that respect it’s similar to writing a Node.js application, though the set of Node libraries is, last I knew, laughably small by comparison.
Having maintained both large-scale JavaScript and Perl codebases, I can tell you that it’s much easier to deal with Perl. Having a proper module system is a huge boon, as well as sane handling of types, and some compile-time checking. Perl is dynamic, yes, but types are explicit by way of sigils—in Perl 5, essentially typed dereferencing operators.
The main difficulty in Perl is the same as in any dynamic language: refactoring. It can be a pain to change things, because many of the resulting errors are not checked till runtime. A comprehensive test suite helps with this; Perl’s testing culture is very good, and comparable to that of Ruby. JavaScript developers tend not, in my experience, to write tests.
So not everybody hates Perl, and not everybody hates JavaScript. People who’ve actually used a language tend not to hate it as much as those who haven’t. This article is, in that regard, just plain silly.
> The two languages are used in very different ways
I thought so too. JavaScript seems like it's filling a gap, and by doing that it's ensuring its own survival. Either that, or we're forcing it into a specific purpose (i.e event based manipulation, animation, data i/o), but the end result will probably be the same. I have a hard time imagining something else coming along, at least not as long as JavaScript is... well, everywhere.
Thank you for explaining Perl to me. A proper module system, compile-time checking and the sort has, with JavaScript, been solved by using JSLint and AMD. Well, almost. It makes the code easier to maintain. Although I'm sure Perl is superior in that regard, it still works - and it works really well.
I thought so too. JavaScript seems like it's filling a gap, and by doing that it's ensuring its own survival. Either that, or we're forcing it into a specific purpose (i.e event based manipulation, animation, data i/o), but the end result will probably be the same. I have a hard time imagining something else coming along, at least not as long as JavaScript is... well, everywhere.
Thank you for explaining Perl to me. A proper module system, compile-time checking and the sort has, with JavaScript, been solved by using JSLint and AMD. Well, almost. It makes the code easier to maintain. Although I'm sure Perl is superior in that regard, it still works - and it works really well.
I don't think that people's problems with perl < 5.0 was it's lack of "object oriented" features. Perl's object system is quite interesting, but orthogonal to the perceived ickiness of perl the language.
I think part of the problem with JavaScript, php, perl, etc is that is there, by default, everywhere. A great many beginners do some very ugly things with it because it's already on the system they have and there's tons of not so good examples on the Internet to cut and paste. I'd bet there are plenty of people creating web sites who aren't entirely clear on where HTML stops and JavaScript starts.
Ruby, for example not only has to be installed on most older systems, you'd have to know that you wanted ruby in the first place. This alone acts as a giant filter. Anyone who knows they want to use ruby is already going to produce better code.
Edit: Please s/ruby//g with anything slightly more obscure than perl/php like python, go, object-pascal, etc. I'm not trying to be a ruby elitist here. It was just an example.
Ruby, for example not only has to be installed on most older systems, you'd have to know that you wanted ruby in the first place. This alone acts as a giant filter. Anyone who knows they want to use ruby is already going to produce better code.
Edit: Please s/ruby//g with anything slightly more obscure than perl/php like python, go, object-pascal, etc. I'm not trying to be a ruby elitist here. It was just an example.
They are not "already" going to produce better code. I have nothing against Ruby, but its devs are not endowed with better programming practices.
I do agree with you that it acts as a filter of sorts, but only for now. Anything that is not mainstream tends to act this way.
I do agree with you that it acts as a filter of sorts, but only for now. Anything that is not mainstream tends to act this way.
I've seen a lot of silly Ruby / Java / Scala code to buy this line of argument.
PHP is most likely not on the system they have.
I don't know about OS X but it doesn't come with any popular Linux distro and it doesn't come with Windows either. Neither does Perl.
I don't know about OS X but it doesn't come with any popular Linux distro and it doesn't come with Windows either. Neither does Perl.
PHP comes with every hosting provider out there for a few dollars a month. Has been the trend for a few years now :-). PHP is cheap to support for a host.
Most people don't try to host their first web site on their windows box. They likely get a shared host for $3 a month somewhere. This probably has a little sample site with a few lines of PHP and some JavaScript on it.
When I started, I did not know the difference between PHP, JavaScript and HTML. I thought it was all "web markup".
When I started, I did not know the difference between PHP, JavaScript and HTML. I thought it was all "web markup".
> Most people don't try to host their first web site on their windows box.
Most people dont host their first web site period. I never heard of anyone who didn't learn PHP offline, on a local Apache server.
Most people dont host their first web site period. I never heard of anyone who didn't learn PHP offline, on a local Apache server.
PHP is available on OS X
computer-4:~ justin$ php -v
PHP 5.3.15 with Suhosin-Patch (cli) (built: Aug 24 2012 17:45:44)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend TechnologiesThat doesn't sound elitist at all...
I don't mean it too. I produced the most awful, unreadable, barely functional drek you can imagine for far longer than I should have as a beginner with perl. The point is, that it might not be a failing of perl and JavaScript that makes so much code written in it so ugly. Its accessibility might actually be a good thing, with this simple side effect.
> Nobody actually does plain “JavaScript” programming for the web anymore, not really anyway. Do they use the core language? Yes. But we no longer use any of the built-in JavaScript->HTML functionality directly.
Which is sort of a shame because there's stuff in there that totally obviates the need to haphazardly traverse the dom with jQuery.
Finding the form an input element belongs to in jQuery:
Which is sort of a shame because there's stuff in there that totally obviates the need to haphazardly traverse the dom with jQuery.
Finding the form an input element belongs to in jQuery:
$('input').parents('form');
// or probably
$('input').parent().parent().parent().find('form');
document.querySelector('input').form;
$('input').on('click', function(evt) {
var form = this.form;
});
// where `submit` uses XHR2 to make a request
<input type="submit">Unless you want to support IE7, that is. http://caniuse.com/#search=queryselector
Not that I recommend doing so, but in many cases you don't have a choice. Or you started working on a project that originally needed to, and maintaining consistent style might lead you to use jQuery everywhere.
Not that I recommend doing so, but in many cases you don't have a choice. Or you started working on a project that originally needed to, and maintaining consistent style might lead you to use jQuery everywhere.
Of course. My main point wasn't the use of querySelector per se, but the ability to access the exact DOM element(s) you need without crazy querying or traversal.
While the DOM API isn't perfect by any means, and jQuery fills that gap really well, there are still times where the OOP nature of the DOM gets you exactly what you want with minimal faff.
The other problem is the relative obscurity of it thanks to jQuery and crowd-sourced DOM documentation (via MDN).
While the DOM API isn't perfect by any means, and jQuery fills that gap really well, there are still times where the OOP nature of the DOM gets you exactly what you want with minimal faff.
The other problem is the relative obscurity of it thanks to jQuery and crowd-sourced DOM documentation (via MDN).
yeah, jQuery certainly eclipses everything else. Though I don't know what you mean by obscurity + MDN... it does seem weirdly anaemic for such a big / complex / important piece of the API, but I don't know if I'd call MDN obscure. Or, I hope it isn't, I find it wildly useful.
I don't really feel like being the next Perl is a bad thing, contrary to the article's premise.
However, the author is making a lot of unbacked and sensational claims. I feel inclined to comment on each part.
> everyone hates [Perl] because it’s “too hard to maintain” and too “strange.”
I didn't know everyone hates Perl and I also didn't know those were the reason. Surely we don't want strange languages? </sarcasm>
> global variables in JavaScript have been at the root of nearly every client-side security exploit to date.
Where does this information come from?
> In the mean time, to work around some of these issues, JavaScript is still being used much like an Assembly language.
How is javascript like assembly?
> We are seeing a similar explosion of packages (libraries), like Perl did, which led to the development of CPAN (you could akin this to the jQuery plugin ecosystem, which is neither as formal, reliable, nor as convenient or automated.)
Also worth mentioning is node's NPM, in which case the above argument is not true. And also, github and great search engines did not exist at the time that CPAN came out, and it's hard to imagine it would have gained the same amount of traction, because it's simply not necessary for the most part.
> There’s a similar explosion of JavaScript implementations on server side and in other languages, leading to issues with compatibility and runtime bugs.
What is this based on? I haven't seen many problems with compatibility and runtime bugs in the Node ecosystem at all. However I've never used Rhino, and perhaps that's what he's talking about. Does the author have any experience with Node?
> Still don’t believe that JavaScript is the new Perl? Compare jQuery to Perl CGI. Nobody actually does plain “JavaScript” programming for the web anymore, not really anyway. Do they use the core language? Yes. But we no longer use any of the built-in JavaScript->HTML functionality directly.
Only holds limited truth for browser development. Everybody using jquery is using plain Javascript. They are interfacing with the DOM API through jQuery and using the jQuery library. But the comparison is like saying anybody who uses a 3rd party library in Java is not using the real language. A language is not the API that you're using.
> jQuery is the glue that holds together the JavaScript ecosystem, provides browser compatibility, and it admittedly does a pretty good job.
what?
> however, sooner or later, the lack of language constructs like truly enforceable namespace boundaries, and the general mess created when teams get a little bit bigger is going to set in.
Name spacing is easily solved using module loaders and proper scoping.
> This is seen over and over as the new wave of developers comes into corporate life: Larger companies try it out, then decide it’s costing measurably, then switch back.
It would be interesting to know which large companies have been trying it out and then deciding it's costing them too much money and switching back.
> We ARE inherently lazy and most of us will ignore nearly any best practice or principle once “that deadline” gets too close.
Sorry, this just means you're a shitty developer and/or can't manage deadlines very well.
> Still, you don’t see that many big Python and Ruby shops either (Google is an exception,)
His exception is a pretty large one. And besides that, which companies has the author studied?
I'm not going to comment on any of the Java claims, since I don't have that much experience with Java.
All in all this article is incredibly biased towards Java and affected by large amount of disinformation about Javascript in general.
However, the author is making a lot of unbacked and sensational claims. I feel inclined to comment on each part.
> everyone hates [Perl] because it’s “too hard to maintain” and too “strange.”
I didn't know everyone hates Perl and I also didn't know those were the reason. Surely we don't want strange languages? </sarcasm>
> global variables in JavaScript have been at the root of nearly every client-side security exploit to date.
Where does this information come from?
> In the mean time, to work around some of these issues, JavaScript is still being used much like an Assembly language.
How is javascript like assembly?
> We are seeing a similar explosion of packages (libraries), like Perl did, which led to the development of CPAN (you could akin this to the jQuery plugin ecosystem, which is neither as formal, reliable, nor as convenient or automated.)
Also worth mentioning is node's NPM, in which case the above argument is not true. And also, github and great search engines did not exist at the time that CPAN came out, and it's hard to imagine it would have gained the same amount of traction, because it's simply not necessary for the most part.
> There’s a similar explosion of JavaScript implementations on server side and in other languages, leading to issues with compatibility and runtime bugs.
What is this based on? I haven't seen many problems with compatibility and runtime bugs in the Node ecosystem at all. However I've never used Rhino, and perhaps that's what he's talking about. Does the author have any experience with Node?
> Still don’t believe that JavaScript is the new Perl? Compare jQuery to Perl CGI. Nobody actually does plain “JavaScript” programming for the web anymore, not really anyway. Do they use the core language? Yes. But we no longer use any of the built-in JavaScript->HTML functionality directly.
Only holds limited truth for browser development. Everybody using jquery is using plain Javascript. They are interfacing with the DOM API through jQuery and using the jQuery library. But the comparison is like saying anybody who uses a 3rd party library in Java is not using the real language. A language is not the API that you're using.
> jQuery is the glue that holds together the JavaScript ecosystem, provides browser compatibility, and it admittedly does a pretty good job.
what?
> however, sooner or later, the lack of language constructs like truly enforceable namespace boundaries, and the general mess created when teams get a little bit bigger is going to set in.
Name spacing is easily solved using module loaders and proper scoping.
> This is seen over and over as the new wave of developers comes into corporate life: Larger companies try it out, then decide it’s costing measurably, then switch back.
It would be interesting to know which large companies have been trying it out and then deciding it's costing them too much money and switching back.
> We ARE inherently lazy and most of us will ignore nearly any best practice or principle once “that deadline” gets too close.
Sorry, this just means you're a shitty developer and/or can't manage deadlines very well.
> Still, you don’t see that many big Python and Ruby shops either (Google is an exception,)
His exception is a pretty large one. And besides that, which companies has the author studied?
I'm not going to comment on any of the Java claims, since I don't have that much experience with Java.
All in all this article is incredibly biased towards Java and affected by large amount of disinformation about Javascript in general.
I agree with a lot of what you said, but I can see one area where I can see what the author is trying to say.
> How is javascript like assembly?
You're right that JavaScript is not like assembly; it's more like bytecode. A number of different languages compile to JavaScript (CoffeeScript, TypeKit, Fay), which is then interpreted. While the intent of JavaScript is that it should be readable by humans, in practice this does not happen thanks to production minification. This is more like bytecode. For example, you can Java .class file with a hex editor, but you'll need software to do that, or a hex editor and a lot of time.
tl;dr: The author means to say that JavaScript is used as a building block for other languages used to write client-side logic.
> How is javascript like assembly?
You're right that JavaScript is not like assembly; it's more like bytecode. A number of different languages compile to JavaScript (CoffeeScript, TypeKit, Fay), which is then interpreted. While the intent of JavaScript is that it should be readable by humans, in practice this does not happen thanks to production minification. This is more like bytecode. For example, you can Java .class file with a hex editor, but you'll need software to do that, or a hex editor and a lot of time.
tl;dr: The author means to say that JavaScript is used as a building block for other languages used to write client-side logic.
Ok, I can see that point. I guess the big difference is that not many people write in bytecode, but a lot of people (majority in my experience, which might change) write in pure Javascript
> I guess the big difference is that not many people write in bytecode, but a lot of people (majority in my experience, which might change) write in pure Javascript
That's purely a matter of preference. If you want, you can write in Java, C# or C++ and compile that to JavaScript, many major websites use that approach.
The fact that many people still write pure JavaScript shows the opposite of what the article says: People like it and are productive with it. If they were not, they would more often write in something else and compile to it.
That's purely a matter of preference. If you want, you can write in Java, C# or C++ and compile that to JavaScript, many major websites use that approach.
The fact that many people still write pure JavaScript shows the opposite of what the article says: People like it and are productive with it. If they were not, they would more often write in something else and compile to it.
Oh, definitely. I write in JavaScript myself. I understand what the author is trying to convey, but both analogies (assembly and bytecode) are wrong in their own ways.
Yeah everyone uses jQuery on the browser right now, but that isn't true on the server. I don't know why you'd want jQuery on your Node app...
But anyway, eventually I think jQuery might not be as useful once most every browser has a sane implementation of the new ECMAScript harmony. But who knows, the jQuery API is so simple it might stay around on the browser for a while.
But anyway, eventually I think jQuery might not be as useful once most every browser has a sane implementation of the new ECMAScript harmony. But who knows, the jQuery API is so simple it might stay around on the browser for a while.
>How is javascript like assembly?
Their point is it is often used as a language to compile down to, not that JS is like ASM.
Their point is it is often used as a language to compile down to, not that JS is like ASM.
This post reads a bit inflammatory to me and I take issue with most of your points.
> > everyone hates [Perl] because it’s “too hard to maintain” and too “strange.”
> I didn't know everyone hates Perl and I also didn't know those were the reason.
More accurately: nobody cares about Perl. Not 'nobody', but most people. It's hyperbole. You might argue that there is still a lot of Perl around according to programming language popularity metrics, but very few if any new things are being done with Perl, at least in this neck of the woods.
> How is javascript like assembly?
Explained in other comments. It's more like bytecode. Many other languages are compiled to JavaScript (hundreds?)
> > There’s a similar explosion of JavaScript implementations on server side and in other languages, leading to issues with compatibility and runtime bugs.
> What is this based on? I haven't seen many problems with compatibility and runtime bugs in the Node ecosystem at all.
I've used systems that use other JavaScript interpreters than V8. Also I think he may be referring to incompatibility between browsers and server. Compare to Python or Ruby where there is a standard C implementation used the vast majority of the time and then a manageable number of competing implementations that can easily be ignored for compatibility reasons.
> > Still don’t believe that JavaScript is the new Perl? Compare jQuery to Perl CGI. Nobody actually does plain “JavaScript” programming for the web anymore, not really anyway. Do they use the core language? Yes. But we no longer use any of the built-in JavaScript->HTML functionality directly.
> Only holds limited truth for browser development. Everybody using jquery is using plain Javascript.
I don't understand. In my experience of web development, we are using JQuery, which is a Javascript library that abstracts most things you do in the browser just as Perl CGI is a library that abstracts most things to do with HTTP. You appear not be refuting what he wrote, but simply claiming he is wrong. What do you mean by saying that everybody using JQuery is also using plain Javascript?
> > jQuery is the glue that holds together the JavaScript ecosystem, provides browser compatibility, and it admittedly does a pretty good job.
> what?
Yes, yes, and yes. What issue do you take with this statement?
> > however, sooner or later, the lack of language constructs like truly enforceable namespace boundaries, and the general mess created when teams get a little bit bigger is going to set in.
> Name spacing is easily solved using module loaders and proper scoping.
His complaint is that it's not enforced. Sure, it's "easy" to use module loaders and proper scoping, but anybody is free to ignore them and boy do they!
> > We ARE inherently lazy and most of us will ignore nearly any best practice or principle once “that deadline” gets too close.
> Sorry, this just means you're a shitty developer and/or can't manage deadlines very well.
No, "you're" not a shitty developer, lots of real people working in a real companies are. Successful languages make it impossible to be a shitty (read: disorganized) developer in these respects. People who work in enterprise say this over and over as do, surprisingly, people in the programming languages community. Head over to Lambda the Ultimate or just take a look at the design choices that languages like Haskell make.
> > Still, you don’t see that many big Python and Ruby shops either (Google is an exception,)
> His exception is a pretty large one. And besides that, which companies has the author studied?
It's perfectly fine to include a statement of anecdotal truth in a blog post. Want some data? Take a look at TIOBE: http://www.tiobe.com/index.php/content/paperinfo/tpci/index..... The popular static languages are more popular than the popular dynamic languages by a factor of 4:1.
> > everyone hates [Perl] because it’s “too hard to maintain” and too “strange.”
> I didn't know everyone hates Perl and I also didn't know those were the reason.
More accurately: nobody cares about Perl. Not 'nobody', but most people. It's hyperbole. You might argue that there is still a lot of Perl around according to programming language popularity metrics, but very few if any new things are being done with Perl, at least in this neck of the woods.
> How is javascript like assembly?
Explained in other comments. It's more like bytecode. Many other languages are compiled to JavaScript (hundreds?)
> > There’s a similar explosion of JavaScript implementations on server side and in other languages, leading to issues with compatibility and runtime bugs.
> What is this based on? I haven't seen many problems with compatibility and runtime bugs in the Node ecosystem at all.
I've used systems that use other JavaScript interpreters than V8. Also I think he may be referring to incompatibility between browsers and server. Compare to Python or Ruby where there is a standard C implementation used the vast majority of the time and then a manageable number of competing implementations that can easily be ignored for compatibility reasons.
> > Still don’t believe that JavaScript is the new Perl? Compare jQuery to Perl CGI. Nobody actually does plain “JavaScript” programming for the web anymore, not really anyway. Do they use the core language? Yes. But we no longer use any of the built-in JavaScript->HTML functionality directly.
> Only holds limited truth for browser development. Everybody using jquery is using plain Javascript.
I don't understand. In my experience of web development, we are using JQuery, which is a Javascript library that abstracts most things you do in the browser just as Perl CGI is a library that abstracts most things to do with HTTP. You appear not be refuting what he wrote, but simply claiming he is wrong. What do you mean by saying that everybody using JQuery is also using plain Javascript?
> > jQuery is the glue that holds together the JavaScript ecosystem, provides browser compatibility, and it admittedly does a pretty good job.
> what?
Yes, yes, and yes. What issue do you take with this statement?
> > however, sooner or later, the lack of language constructs like truly enforceable namespace boundaries, and the general mess created when teams get a little bit bigger is going to set in.
> Name spacing is easily solved using module loaders and proper scoping.
His complaint is that it's not enforced. Sure, it's "easy" to use module loaders and proper scoping, but anybody is free to ignore them and boy do they!
> > We ARE inherently lazy and most of us will ignore nearly any best practice or principle once “that deadline” gets too close.
> Sorry, this just means you're a shitty developer and/or can't manage deadlines very well.
No, "you're" not a shitty developer, lots of real people working in a real companies are. Successful languages make it impossible to be a shitty (read: disorganized) developer in these respects. People who work in enterprise say this over and over as do, surprisingly, people in the programming languages community. Head over to Lambda the Ultimate or just take a look at the design choices that languages like Haskell make.
> > Still, you don’t see that many big Python and Ruby shops either (Google is an exception,)
> His exception is a pretty large one. And besides that, which companies has the author studied?
It's perfectly fine to include a statement of anecdotal truth in a blog post. Want some data? Take a look at TIOBE: http://www.tiobe.com/index.php/content/paperinfo/tpci/index..... The popular static languages are more popular than the popular dynamic languages by a factor of 4:1.
>>You might argue that there is still a lot of Perl around according to programming language popularity metrics, but very few if any new things are being done with Perl, at least in this neck of the woods.
Perl is used extensively and probably more than any other language in its stride even when it comes to new projects. Unless your definition of new projects are projects which spit out HTML and nothing else.
A very big world exists outside web development.
>>Want some data? Take a look at TIOBE
I don't trust data which includes treats ruby(the programming language) and ruby(stones) or Python(the programming language) and Python(the snake) as same.
>>The popular static languages are more popular than the popular dynamic languages by a factor of 4:1.
Correction, IDEs of popular static languages(Read Java and C#) are more famous than static languages themselves. Who 'really' programs in those languages these days? Today its all about auto complete magic with armies of low paid mediocre programmers. In fact IDE's are the only reason why static languages are even round.
Else who has the time to sit down and write 20 lines of code with 10's of API calls just to open and write a line to a file?
For 99% projects programmer time is vastly more expensive than CPU time.
Perl is used extensively and probably more than any other language in its stride even when it comes to new projects. Unless your definition of new projects are projects which spit out HTML and nothing else.
A very big world exists outside web development.
>>Want some data? Take a look at TIOBE
I don't trust data which includes treats ruby(the programming language) and ruby(stones) or Python(the programming language) and Python(the snake) as same.
>>The popular static languages are more popular than the popular dynamic languages by a factor of 4:1.
Correction, IDEs of popular static languages(Read Java and C#) are more famous than static languages themselves. Who 'really' programs in those languages these days? Today its all about auto complete magic with armies of low paid mediocre programmers. In fact IDE's are the only reason why static languages are even round.
Else who has the time to sit down and write 20 lines of code with 10's of API calls just to open and write a line to a file?
For 99% projects programmer time is vastly more expensive than CPU time.
>I didn't know everyone hates Perl and I also didn't know those were the reason. Surely we don't want strange languages? </sarcasm>
Why the sarcasm? "Everyone", in everyday talk means "most people", and considered that Perl has long lost the spotlight it once had as a scripting language, that is a lot of people.
As for the "strange" part, yes, surely we "don't want strange languages". Strange languages have always been marginal, with C (Algol) style languages always being the most popular.
Here by strange he obviously alludes to the "syntactic noise"-likeness of the language's syntax, one of the most common complaint's about it.
>How is javascript like assembly?
In the obvious way that is used as a target language for stuff, from emscripten to coffeescript, to TypeScript, to Dart, to clojurescript, to GWT.
It's been called multiple types, including in HN, "the assembly/bytecode of the web world" in case you haven't noticed.
>Sorry, this just means you're a shitty developer and/or can't manage deadlines very well.
Which includes most of the industry, so it cannot be dismissed with an work ethic/abilities slant like that. It's common knowledge (and inspected in literature) that most IT project fail, for example. You really think it's because of "shitty developers"? Do you think Brook's team had "shitty developers"? Or the team that worked on Chandler? (read "The Mythical Man Month" and "Dreaming in Code" respectively).
Why the sarcasm? "Everyone", in everyday talk means "most people", and considered that Perl has long lost the spotlight it once had as a scripting language, that is a lot of people.
As for the "strange" part, yes, surely we "don't want strange languages". Strange languages have always been marginal, with C (Algol) style languages always being the most popular.
Here by strange he obviously alludes to the "syntactic noise"-likeness of the language's syntax, one of the most common complaint's about it.
>How is javascript like assembly?
In the obvious way that is used as a target language for stuff, from emscripten to coffeescript, to TypeScript, to Dart, to clojurescript, to GWT.
It's been called multiple types, including in HN, "the assembly/bytecode of the web world" in case you haven't noticed.
>Sorry, this just means you're a shitty developer and/or can't manage deadlines very well.
Which includes most of the industry, so it cannot be dismissed with an work ethic/abilities slant like that. It's common knowledge (and inspected in literature) that most IT project fail, for example. You really think it's because of "shitty developers"? Do you think Brook's team had "shitty developers"? Or the team that worked on Chandler? (read "The Mythical Man Month" and "Dreaming in Code" respectively).
The existence of cross-compilers (even popular ones) does not make a language "like assembly". Javascript is still overwhelmingly written in Javascript.
'People are using it like assembly' does mean that all or even a significant fraction of people are doing that. It's sufficient that a noticeable number of people are doing it and there are tens if not hundreds of projects that compile other languages to Javascript.
Point 1: There is no other way to write client-side browser applications.
Point 2: Node.js allows a team of 1-2 quickly get a server-side app up and running. Once a project takes off and needs to scale to a larger team, it's extremely easy to switch to and write C++ components.
Point 3: Who cares if history is repeating itself or not. It's an impressive technology stack with huge corporate backers. Besides, Perl is still used and although nowhere near as cool, still works great for writing shell scripts.
Point 2: Node.js allows a team of 1-2 quickly get a server-side app up and running. Once a project takes off and needs to scale to a larger team, it's extremely easy to switch to and write C++ components.
Point 3: Who cares if history is repeating itself or not. It's an impressive technology stack with huge corporate backers. Besides, Perl is still used and although nowhere near as cool, still works great for writing shell scripts.
If you say Javascript is becoming an assembly language, you never coded in assembly language, it is not "impossible" to maintain a javascript project, if you can get pass that it is not java, people have been doing it for years and will continue to do so in the near future
Site seems to be timing out here.
Same here. No-image Google cache version here:
http://webcache.googleusercontent.com/search?q=cache:QFxSoJi...
Should be better now.
Perl was never as popular as JavaScript has become lately,
I don't know what to say.
Spoiler: apparently ES6 is going to kill ES5. Personally I'm shocked.
I don't know what to say.
Spoiler: apparently ES6 is going to kill ES5. Personally I'm shocked.
If you replace “popular” with “visible”, then it makes a kind of sense.
We have an extensive JavaScript codebase at the large corporation I work at and by simply enforcing the use of ECMAScript 5 Strict Mode and verifying with JSLint we are able to catch most potential issues but then again, nobody there is writing large systems in JavaScript, only flourishes of browser-side interactivity...
I'm hoping Node continues to gain popularity. The idea of using the same language on the serverside and clientside seems too enticing to fail.
There was much more "magic" in CGI/Perl. The only "magic" in JS in fact is caused by browser vendors and have nothing to do with language itself.
> a stack that is resilient enough to withstand sloppy code.
There is no such magic stack that withstands sloppy code.
There is no such magic stack that withstands sloppy code.
Perl had zero corporate investment from a application development perspective. Java had an enormous amount -- and still does. Now take a look at Javascript. Javascript is the first language since Java to have gotten this much investment across a lot of enterprises. Google, Microsoft, of course, but also the rise of startups like Meteor. For Javascript to go away the way Perl did for app development will require too much retooling.