Perl never had a monopoly on a runtime environment with an install base of pretty much everyone who owns a computer, tablet, or smartphone. Sometimes it's not about engineering principles.
If native mobile apps end up de facto replacing the open internet, that could change, of course. But I hope the internet remains, warts and all. And as ARM chips improve, and DOM APIs are expanded, and JS engines become more efficient, and the HTTP spec is ever more optimized for web applications, I think in the end the browser will survive.
>> Perl never had a monopoly on a runtime environment with an install base of pretty much everyone who owns a computer, tablet, or smartphone. Sometimes it's not about engineering principles.
> If native mobile apps end up de facto replacing the open internet
Mobile is just hyped. Once companies realize that people who access to the internet solely through their phone can hardly be monteized, well be back pre-iphone in the hype department.
> Still, you don’t see that many big Python and Ruby shops either...
But we keep seeing a lot of PHP shops. Does this mean that PHP is better suited for "large scale projects?" I'd very much doubt that.
The ease of learning a language and it's availability are very important factors in the popularity of a language. Javascript scores well in this regard. Really, I am not too worried about Javascript's impending doom. Unlike Perl, it continues to remain a favorite "target language" making it further entrenched in most ecosystems.
Javascript is fairly new, Perl hass been around for ages. So there is a lot of old code knocking about that was written quickly and by people who quite frankly did not know what they were doing. Perl5 is actually extremely readable and if you are any where near a decent developer you will understand it. I have worked in loads of companies and bad code is bad code no matter the language. I have have seen some Java code that made me want to give up development for good, and don't get me started on legacy browser javascript code.
Per wikipedia, Javascript was appeared in 1994 versus Perl in 1987 - not that big of a difference.
Now, both Perl and Javascript today - are totally different beasts they been back then. They both evolved a lot, but due no real competition in browsers Javascript have monopoly. Perl on the other hand, even having all this awesome stuff in it today, have to compete with many other platforms.
Absolutely, it is when following readability guidelines and write documentation. Using obfuscation style is a mess and will never help anybody but the developer ego who believes he is smarter than everybody. But that's a pitty to act like that cause it create pain for maintainers and even for yourself.
Sounds to me like the classic apples and oranges comparison.
In my opinion Javascript's evolution has become a requirement more than just a story of success. It was the de facto standard language for browsers but with big lacks of performances. Browsers vendors worked to improve it and everything was only a natural consequence of the evolution of the World Wide Web.
Perl's history is completely different. Perl has always worked behind the scenes, and still does it greatly. It has a stable, rock solid, very performant and widely spread runtime.
Let's just call things with their names and use them for the purpose they are born and everything will look less confusing.
More than else, always remember: You can write FORTRAN in any Language.
> JavaScript 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.
How about CoffeeScript?
Also, I worked on some pretty "big" JS projects (in terms of scale, not popularity) and I found Javascript really easy to maintain, you just have to plan ahead a little, but I do agree that the syntax is a slightly bit not to my liking, but it is not horrible.
However, I knew before that Array + <something> will give you a String (with the members of that array delimited by a comma) followed by <something> cast into a String. I don't find that wat.
Also, the reason why String+Number works is because + is overridden on strings to concatenate, while - isn't. That's why you get a NaN, but you probably know that. How would you expect it to work anyway? I don't think it's that watty.
The only thing that I find wat-worthy is Object + <something>, because that truly makes little sense. There might be some ambiguous logic behind it, though.
I gues it could be because + infront of an empty array returns 0. So, when you do !+[] you get 1. What you pasted it a bit of a labyrinth, but if someone bothered to keep track of it, they could definitely find ten 1s in there. It's not why, it's a how.
I hope someone figures out the rest and gets a cookie! :D
It may not be the greatest, but at least it's better than JavaScript's broken type system. It does catch at least some problems prior to runtime.
The most compelling arguments regarding this matter are often in the form of personal experience working with large applications. JavaScript code bases don't scale well past around 10,000 lines of code and 2 or 3 developers at most. Languages like Java, C, C++, C# and Ada, on the other hand, can relatively easily handle software systems with millions of lines of code, worked on by hundreds or even thousands of developers spread globally.
Its type system is not particularly complex, but it is robust - it doesn't, for instance, coerce strings-with-numbers-in-it into numbers. Sure, you don't have sum types, etc, but at least it behaves in predictable ways.
C++ is notoriously bad at scaling. I'm told that Ada is both very safe and painfully slow to code.
JS certainly has its problems. I don't think its type system features all that high. Newcomers trying to make it behave like their favourite language is a much bigger problem.
Compared to javascript, Java is quite "rigid". There is always a right way to do things, and doing something else usually leads to hard times. This means that it fits quite well together, and allows complex systems to be more easily created.
Javascript's relativity 'loose' type system means that developers have to spend a lot more time ensuring parts will work well. It isn't like good code can't be written in javascript, it's just that it takes a lot more effort.
These subtle JS rants every other day are kind of annoying. Comparing JS to Perl gives a new but still wrong angel on an old tedious discussion.
JS weaknesses are overrated: anybody can grasp all quirks within an hour and after few days you get used to them (besides there just a few and great standard libs like underscore making JS a rock-solid base) and JS' bad parts won't stand in your way anymore. Those who aim for perfection won't get shit done anyway. They look for the academically structured Rails apps (or replace with any other bloated framework) with half a second respond times and breaking after every 0.0.1 update of Rails. In my view JS is damn perfect and I can think of anything better right now. JS and its ecosystem (especially the awesome npm) gives you anything to write elegant, well maintainable code bases ten leagues higher than any script language like PHP and on the same level like Ruby or Python.
JS is not a hack written in ten days. JS is a wonderful and modern language, more innovative than most other language out there, it's a masterpiece of a language. People complain because it's different: it doesn't follow the traditional OO, there're no strict monolithic frameworks which teach them how to structure code and most are just overwhelmed with functional programming and event loops/call backs/asynchrony because they were just used to something different. This is not being arrogant it's just that people don't like change or hoping all the time for something better instead of being happy with what they have now.
You can create and maintain very large code bases in JS without any Coffee or other layers of abstraction (there enough examples out there). Most people are just not used anymore to think theirself about structuring code since there was always somebody who did the job for them (Rails, Django, etc.).
You don't need to compile to JS -- JS is also not the new assembly of the net because hundreds are building weird languages on top providing useless syntactic sugar and again old-age OO, it's already a very high level language allowing you to do ANYTHING and structuring you code exactly as want. Nothing will stand in your way.
And Javascript is so fast, you get C class performance with a dynamically typed language. No need to compile after every single change or deploys are fast and easy without sending huge binaries to the servers. There's no other language providing this speed for such little cost, no other.
To understand JS' beauty and to get the "flow" you have with other languages and you do not get with JS you have to do two things: invest time and try to forget what you learned. And if you still don't get there spend more time with JS. It's not JS which failed.
JS haters and other downvoters: not agreeing != downvoting
The problem with Javascript came when it started to be used server side. Suddenly, comparing with other languages that one can use instead is fair game.
Sure, Javascript may not be as bad as perl or php, but it's got plenty of warts. On the server, why use javascript when you can use a language without warts?
Usual disclaimer about micro-benchmarks applies, but I suspect the real picture is even worse. Speaking of compiling down to Javascript, languages like Coffeescript came about because of Javascripts warts, not because it's such a great language.
Again, you can program in straight Javascript, but why? Because it's all you know? I need to forget better solutions exist to like it?
Could you explain what you consider to be wonderful and modern about it? My view is it's Just Another scripting language with a weird OO model. I'm specifically interested in the features you think it offers that other scripting languages like Ruby, Perl and Python don't have, which make it modern and wonderful.
> more innovative than most other language out there
Could you give an example of this?
> most are just overwhelmed with functional programming and event loops/call backs/asynchrony because they were just used to something different.
Javascript allows you to have a simple form of anonymous function. Is this what you mean by "functional programming"? Do you feel Javascript's implementation of this is superior to how other languages do it?
It's kind of sounding a bit like you think NodeJS invented event-driven programming...
> You can create and maintain very large code bases in JS without any Coffee or other layers of abstraction
You can do this in any language, and there are enough examples out there. That doesn't mean that it's necessarily what the language encourages. I've found Javascript considerably more difficult to organize code in than Haskell or Erlang or Perl or Objective C ... actually, harder than most things.
> Most people are just not used anymore to think theirself about structuring code since there was always somebody who did the job for them (Rails, Django, etc.).
You ... how long have you been programming for?
> it's already a very high level language allowing you to do ANYTHING and structuring you code exactly as want. Nothing will stand in your way.
I think this is definitely the first time I've understood the relationship between Javascript and ZOMBOCOM.
> And Javascript is so fast, you get C class performance with a dynamically typed language.
And it's about now that this start to sound like satire...
It might just depend on one's previous experience. I've not been very impressed with Javascript the language. I've been a C++ programmer for years, so I'm well practised at being happy with what I have now rather than wishing for something better. But I find it difficult to be happy with a language that doesn't have proper block scope and won't even check function arity. (Dear computer, stop being so damn lazy.)
But, sadly, it fills a hole that nothing else does.
Mh... "those who hate Perl hate it because it’s “too hard to maintain” and too “strange.”"... No.. i hate perl because it's too easy to write really, really bad code and non-obvious how to write good code.
Any time people hate on Perl but like Javascript, I get confused. Perl has some weaknesses vs Javascript (doesn't run in the browser, can't be parsed by anything other than perl so you don't get interesting new interpreters) but also some considerable strengths (uninsane OO, considerably better tooling, string handling, runs on every server by default).
But the nice things about JS - the effortless ability to go all higher-order, the flexibility, the power, the /fun/ - and much of the bad parts - the difficulty with writing clear and maintainable code, no support for strong types; if you like Javascript, you will love Perl when you get to know it.
I love Perl because it is really easy to structure your code to match your way of thinking. And it is so fast to get the job done.
I am a javascript beginner. For me, it is a lot more difficult to read than Perl. I very much agree with the article, but I think that javascript is more than a new Perl, it is also a new BASIC. Like BASIC 30 year ago, it is present on every computer, almost every developer will encounter the need to learn javascript and almost anything can be coded in javascript.
There's one obvious way to write good Perl code: read the documentation. Perl has tonnes of it. There are bugs in there of course, but most of it is very good. Also try to visit perlmonks.org once in a while - they're good there. Everything else is just a reason to be lazy and not care about the code you write.
And, Perl has an awesome community, let's not forget that. They do love clean code and all (modern Perl is very easy to read and understand IMHO), but are aware that in the end you want to get the job done.
Time and again, the question "are there any useful ideas or features in language X that we can borrow and implement in Perl?" has been posed by prominent people in the Perl community. Which is the opposite of the "not invented here" syndrome.
There's another obvious way to write good Perl thanks to the CPAN: don't write it because others already made the work better than you. @mutation: i agree with doc quality.
Well, the documentation system on CPAN is ancient and awful to use.
I have often enough found missing documentation. Particularly perl programmers seem to give a f*ck about documenting return values.
And even when there is a good documented function, often enough i am not smarter after reading.
Just picking a random method of a random module here:
What's the return value? Is there really no result? And what is cache? I can't even click that variable and see it's structure.
As a reminder, i just picked some random module. It's 2013 and not 1980. I'd like to know that kind of stuff quickly when i check for arguments and how to call stuff. I like that stuff in my editor/ide as well. Clickable. Call me lazy, but i do want to work efficiently and not trying to google all day for a simple usage example. I like to get the work done.
You're partially right about perlmonks. It's a great resource for perl! Sometimes it seems like it's the last stronghold of the perl community but it has great answers.
What is not so great is that i find multiple solution (like more then 10) for a very simple problem, but that's subjective..
Hope they could create a kind of huge centralized 'CJSAN' repository as CPAN [1] is. I've checked some existing projets [2] but it can hardly list some hundred modules. NPM [3] is great, but it should himself be integrated into a larger JS repository in the same way Cpanminus [4] is integrated inside CPAN.
Using any technology in hopelessly idiotic ways when better tools (and more importantly, appropriate tools) exist will turn it to the new [previous-tech-used-in-hopelessly-idiotic-ways].
This dilemma is as old as programming itself and will only go away when we introduce public flogging as punishment* for wrongly applying the "laziness is a virtue" dogma.
* Developers are people too (mostly) and I don't condone public violence against them. Private violence is OK.
This isn't about running code in the web browser. This is a greater problem of offloading what is better off as being server-side processing on the browser.
This comes off as very dogmatic. There are good use cases for single-page or few-pages webapps. I'm likewise more comfortable server-side, but I can understand why you would want this sort of thing.
If native mobile apps end up de facto replacing the open internet, that could change, of course. But I hope the internet remains, warts and all. And as ARM chips improve, and DOM APIs are expanded, and JS engines become more efficient, and the HTTP spec is ever more optimized for web applications, I think in the end the browser will survive.