Slashdot Mirror
Why JavaScript Is the New Perl
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.'"
What is this? Slasdot's daily troll story?
capcha: manure. How appropriate.
Yeah, like there's only one troll story a day. You must not check very often.
Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
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.
It's 2013, and someone is discovering Javascript?
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?
JavaScript is a horrible language.
Even with frameworks to significantly alter it's behaviour, it is still a mess. The weird scope rules and lack of proper object/class support drive me up the wall when working on projects with ~40,000 lines of code.
HTML5 will become a much more realistic technology the day we can use a half decent language.
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?
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.
Live today, because you never know what tomorrow brings
But, hey, lots of people like them, so they must be good, right? https://www.destroyallsoftware.com/talks/wat
It's extremely hard to create something large an keep it maintainable in JavaScript. It's not quite the 'write-only' language Perl can be, but it's not great. It seems to be a symptom of all dynamically typed languages to a degree, but JavaScript even lacks the consistency of many others. It's possible to create maintainable code, but the language fights you.
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.
"Love heals scars love left." -- Henry Rollins
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.).
The G
. It's possible to create maintainable code, but the language fights you.
A thousand times this!!!
I work in a large company where we have a different GUI team that designs our screens. Increasingly over the past few years they have been building screens with more and more JavaScript requirements. Users seem to want to see everything dynamically loaded...page replaces are somehow evil and ugly...give me a fucking break already...if they had any idea how much more it costs them to build the screens they design they wouldn't be doing it.
Pretty screens == almost impossible to maintain code. It's as simple as that and until something better comes along than JavaScript it's going to be a nightmare for most of us to deal with production issues. What's worse is when not even id's of elements on the page make sense so you wind up with id's that make the JavaScript code look even more confusing. I've built some of the most complex systems at my company that are heavy in JavaScript. We did a great job according to everyone around. But I know there are some things we can never correct because of the language we are dealing with.
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. ]
It must have been something you assimilated. . . .
You're confusing the API with the language. Web programs are unmaintainable because the API isn't an application programming interface by a long shot. The language itself is pretty nifty, if you understand and use its functional aspects. It wasn't designed to be used for big projects, so it lacks direct implementations of namespaces and other big project language features, but you can get around those limitations because the language is quite flexible.
So you're saying that it's indeed a good replacement for Perl after all? ;-)
Ezekiel 23:20
.. is just like leaving an abusive relationship, its all about getting closure.
http://rareformnewmedia.com/
Namespaces are pretty trivial to get around the lack of, C programmers have done it for 40 years and there's plenty of large systems written in it. It just takes discipline- prepend your function names with the module name. If you're in namespace window and have a function getHeight, you write it as window_getHeight. It takes a little bit of discipline, but not that much.
The real problem with web programming being unmaintainable is a combination of several factors, pretty much in this order:
1)Web programmers tend to be lower skill programmers. This is for historical reasons- when web apps didn't do much, good programmers wanted to work on more complex problems not just write a GUI for the hundredth time. It tends to be considered an entry level job, pays less,and lacks respect among programmers. Also, the lower barriers to entry on web programming means a lot of self-taught people enter that part of the field, who never really learn CS or software engineering.
2)There's a hack it and get it done mentality to web programmers. This comes from the quick cycle nature of web programming (which tends to be very visual based and small changes are easy to make on the fly) and the abundance of "agile" methodologies which tend to lack in design. Its made worse by how poor a markup language html/css are for what we try to make them do today and the amount of hacking that's necessary to get around browser incompatibilities.
3)The entire AJAX and framework of web programming is wrong. It was a quick hack added so that you could make dynamic apps using existing technologies without major changes to clients. But its layered hack upon hack upon hack. We really need to scrap it all and come up with a web application programming stack- a new markup language that's meant to do pixel perfect rendering (HTML is not, but its used that way), an HTTP replacement that's stateful rather than stateless, a cleaner way of sending data back and forth from the server. But if you write on top of an ugly platform, you're going to get ugly code.
4)Language issues. Javascript was never a good language- hell, you can tell that from the fact it's very name was a blatant marketing maneuver. Lack of a good object model is a real problem. Ideally you would want to be able to use any language here- maybe it's time to start delivering apps as byte code binary so the actual app can be written in whatever the programmer thinks best.
Unfortunately the last two of those would require fixes by the major browser vendors, the first two would take a decade of culture change to fix. So its going to continue to suck for a while.
I still have more fans than freaks. WTF is wrong with you people?
I'm still wondering how Perl was discovered "during the advent of C and C++" ...that, or more likely, both submitter and editor need to look up what in the hell the word "advent" means.
.
*boggles*
.
To wit: I sincerely doubt that Perl was around in 1969 or the early 1980's, FFS...
Quo usque tandem abutere, Nimbus, patientia nostra?
How many javascript developers does it take to change a lightbulb?
10,000. 1 to hold the bulb, and 9,999 to turn the house around.
Replace Javascript with Perl as the situation commands.
Science advances one funeral at a time- Max Planck
https://www.destroyallsoftware.com/talks/wat - Give that a watch - it's short and amusing, not some huge rant or dissection (begins on Ruby, moves to JS). Done watching? JS is full of that kind of horrific design that makes code do stuff you don't expect, and it lacks features that everyone needs. It just makes development harder, and that's the reverse of what you want a language to do.
-- Lattyware (www.lattyware.co.uk)
1)Web programmers tend to be lower skill programmers. ...
2)There's a hack it and get it done mentality to web programmers. ...
I agree with these two statements. But your next one:
3)The entire AJAX and framework of web programming is wrong. It was a quick hack added so that you could make dynamic apps using existing technologies without major changes to clients. But its layered hack upon hack upon hack. We really need to scrap it all and come up with a web application programming stack- a new markup language that's meant to do pixel perfect rendering (HTML is not, but its used that way), an HTTP replacement that's stateful rather than stateless, a cleaner way of sending data back and forth from the server. But if you write on top of an ugly platform, you're going to get ugly code.
That's just ignorant of how nasty client programming really is. The reality is that using a stateless base layer of HTTP and building a state system on top of that (e.g., with REST) is significantly easier to make work properly in a hostile physical network environment than what you propose.
AJAX is one heck of a lot easier to deal with though once it's been tamed with a library like jQuery, and once you've wrapped your head around asynchronous programming. Some programmers never really get async programming (I feel sorry for them, missing out on such powerful techniques) but it is really very useful for almost all network and GUI coding. There's no shame in using a library to make networking nicer; raw POSIX socket calls are horrendous from the perspective of the vast majority of application programmers...
4)Language issues. Javascript was never a good language- hell, you can tell that from the fact it's very name was a blatant marketing maneuver. Lack of a good object model is a real problem.
There's not much wrong with prototype-based object models; they're different, not wrong. If you were going to rag on the language design, it would be far better to grouse about the "fun" gotchas in scoping and the way one handles modularization...
"Little does he know, but there is no 'I' in 'Idiot'!"
Citation please. I'll concede that modern JS engines are very good, but arguing that an engine for a dynamic interpreted language outperforms a modern VM for a statically typed compiled one sounds a bit.... suspicious.
File under 'M' for 'Manic ranting'
Ah. I see your problem. Telerik.
Their controls were all server-side .Net 1.1 controls, then they bolted on .Net 2.0, 3.5, 4.0, and now 4.5. Somewhere around the 3.5 era (the big AJAX push), they realized that more stuff needed to be client-side for that "web 2.0 feel" or whatever. So that got bolted on also. Now it's not just a steaming pile of crap, it's a steaming pile of crap with five more steaming piles of crap piled on top of it.
Your best option at this point is to start over. Trust me on this. I've been where you are, and the best way out is to drop Telerik. The sooner the better.
If you must have a "tab control", it's not that difficult to slap together a tiny bit of Javascript to do what those controls do for you, and then you have the power to make changes to it later, rather than begging Telerik for an update to their black-box, then being told you have to pay to upgrade.
It's awful for large scale projects. That's why things like GWT exist or why people have about a hundred other ways to write anything but JS and have it compile to JS.
Some people act like that's cool and JS gets to be the web assembly but it's not cool. It's a hack job because JavaScript sucks for large projects. It wasn't intended for that and no one is willing to really improve the language or add another language that does a better job for larger tasks.
But your solution requires the same functionality to be implemented on every platform that behaves exactly the same, regardless of form factor, performance or architecture.
The closest thing to that at the moment is a JVM.
no one is willing to really improve the language or add another language that does a better job for larger tasks.
http://code.google.com/p/dart/
The problem isn't "no one is willing..."
The problem is every vendor needs to support the new language/features or it is effectively useless.
I have coined a rule after myself. I give you, Ralph's Rule: "There is no technology so poorly conceived, so inconsistent, so aesthetically offensive, or so woefully untouched by theory that it will not see widespread adoption in the Web community."
Perl is not a 'write-only' language. There are definitely 'write-only' code monkeys out there who abuse Perl and pass themselves off as knowledgeable programmers. But that is not the language's fault. If you design a language that will stay out of the way of the programmer as he develops his solution, then you of necessity have a language that assumes the programmer knows what he is doing even if he's full of shit. That's Perl's strength, and also the source of its bad rep.
Perl is a lot like the English language, both are capable of exquisite expressions. But just as more than 90% of English prose that is written today is unmitigated biz-lingo crap, and half of the rest is no better than Harlequin romance garbage, so too most of the Perl scripts that you see are junk. But if you want a language that a Shakespeare can use, you have to put up with the trash. With one exception that I know of[1], a programmer who knows what he is doing can write excellent and easy to understand programs in any computer language. Perl actually makes it easier to do that than many languages do.
[1]The sole exception I am aware of is Forth. That is truly a write-only language.
Will
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.
The language itself is pretty nifty, if you understand and use its functional aspects.
Can someone explain why JS fans keep trotting this "functional aspects" bit as if it were a redeeming feature of the language? It may have been in the 90s, but we came a long way since then. All competing "scripting" / dynamic languages have the functions as first class types and function literals (even PHP!), and most of them have better, more concise syntax for them, too - e.g. Python lambda x: x*2 or Ruby {|x| x*2} vs JS function(x) { return x*2; }. Heck, even C++ has that these days! It really isn't the kind of feature that you get to show off and tell how cool it is.
And, that aside, what else can JS boast of? Prototype-based OOP is a dubious feature at best, and everything else in the language is a mess, from magical semicolons to scoping rules for local variables and "this".
It's more logical than PHP, though, I'll give you that.
I'm not sure why this comment is modded so highly. The reason web programming sucked was because we have things called browsers that restricted our capabilities. Add on to that the need for everyone to agree to standards which caused progress in browser technology to slowly adopt newer technology. It is still the same problem even today.
Think about it for a second even if you aren't a web programmer. There was a reason (not just Microsoft) for IE6 adoption: it actually, at one point, implemented more than the competition. Mozilla was around but not nearly as capable. Netscape, too, was around but clearly lacking in the quality and performance of IE at that particular point in time. But everyone would rather believe that IE6 was just flat out terrible throughout its entire existence. To that I ask, would you like to use and program for Netscape 4 or 5 for the same period IE6 was dominant? Obviously not! What we should have received is more intense competition rather than a lengthy side lawsuit about how MS abused its monopoly.
To make a long story short, Netscape was not our savior, Microsoft was still the bad guy (honestly), and the world finally learned that monopolies sucked. The true turning point wasn't until Mozilla came around with Firefox and other companies like Apple and Google began creating their own browsers for the purpose of expanding web technology. It wasn't until Firefox, Safari, and Chrome browsers that we finally exited the lack of improvements in client browser technology.
Any industry stuck in an old way of doing things is going to suck. It doesn't matter if you're the smartest person in the world. If you can only using a hammer, nails, and wood, you're not going to be building skyscrapers quickly or efficiently anytime soon. This is exactly what restricted the web and people that worked for the web.
Now to address some key point presented by the parent:
The entire AJAX and framework of web programming is wrong. It was a quick hack added so that you could make dynamic apps using existing technologies without major changes to clients. But its layered hack upon hack upon hack. We really need to scrap it all and come up with a web application programming stack- a new markup language that's meant to do pixel perfect rendering (HTML is not, but its used that way), an HTTP replacement that's stateful rather than stateless, a cleaner way of sending data back and forth from the server. But if you write on top of an ugly platform, you're going to get ugly code.
There is so much wrong with this claim that I don't know where to begin. Let's start with stateless programming since that's the key theme in this opinion. I would be curious to hear what the parent's idea of "right design" is when a service is expected to provide for millions of requests simultaneously. At some point you're going to be forced to parallelize that work. Congratulations, you've just been forced one step closer to implementing a stateless system. You see, in a stateless system, it is much easier to cut off pieces of work into bite-sized chunks to be handled out of order. When you restrict yourself to state, you're at the mercy of single threaded technology to get your work done. It is 2013, we have CPUs in our pocket phones that have 4 cores. Stateless is here to stay and it will become more pervasive even without any web interaction.
Let's also look at how stateful systems do under latency. Just go play any online game to get a feel for this and login to some far off server that crosses an ocean or two. Your latency will suck, packets will be dropped, and the overall experience sucks. The internet was designed to be world-wide. It was designed to travel great distances where latency and reliability was a real issue. Packets are not guaranteed to arrive. This is why we have TCP and an in-your-face kind of restriction that things can time out. I mean we're sending huge amounts of data around the world for christ-sa
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.
If a simple tab control is all you're after JQuery UI is rather nice, as far as JavaScript goes.
Whaaaaat. Why are you putting all your shit in the global scope in the first place? Use the module pattern, and none of those functions leak out of the file you're in.
The weird scope rules and lack of proper object/class support drive me up the wall...
This tells me you don't really understand JavaScript and especially don't understand JS objects.
But--judging from the number of people who keep trying to turn JS into something else--not many do.
Il n'y a pas de Planet B.
I don't know, maybe I'm just weird myself but I don't think Javascript's scope rules are that hard to grasp, and the class support is workable but honestly most of the time you don't need to use classes at all.
I mean, the scope is easy - are you in a function? If so, the variable is scoped to the function. If not, the variable is globally scoped. That's about it. Just wrap something like
around your script file, and everything will be local to that script file while still being able to see the global scope. There's some other funky stuff involving weird cases like using a locally scoped variable before it's defined, but as long as you're not writing crap on purpose it's not a huge deal.
And as for classes - well, honestly, a lot of the time when you think "I need a class for this", what you really mean is "I've got some data that needs to travel together". In Javascript, you can just do that - you can just say:
And then tada! You've got a class that carries your data around. Hooray!
But if you really want classes, with methods and stuff like that, they're there too - but if you're writing a project large enough to actually need those sorts of tools, you really ought to be using a framework that'll handle the nitty-gritty of classes for you.
The problem is not JavaScript, but programmers who think "it's just a scripting language, how hard can this be". And they hit a brick wall again and again because JavaScript is a language with its own features, features that has to be learnt.
And JavaScript is unmaintanable? It's just a programming language. It's up to the programmer to structure your code. How is that different from other languages? Of course it's possible to write maintainable large projects in JavaScript.
I agree best practices and frameworks are still being developed and improved, but is JavaScript a horrible language? No, it isn't.
Me
This is a common misconception among c / c++ developers. Fact is it's simply not true, you have to deal with a multitude to complex issues that you simply don't need to deal with in native code development. I do both web and native code development and I can tell you that the tasks are just different not easier or harder.
Your atitude in this respect reminded me of a guy that recently applied for a job position at the company I work. He was a c++ developer who wrote on his cover letter something along the lines of "I don't know any web development however because of my experience in native languages I think I will be able to easily pick it up". That's simply naive and wrong, as you can expect he wasn't selected.
As for the rest you wrote I agree and disagree at the same time. Sure there are a lot of "make it work" attitudes however you get the same atitude in native code development too so it isn't something restricted to web development.
No, no it is not. People who think like this do not understand web development, and almost no one apart from terrible developers treats it in the way you mentioned. Websites have to be designed to fit on everything from small mobile phones to big TVs. That's why everyone is trying to make their sites "responsive". Everyone is moving in the complete opposite direction to what you have mentioned in that the best way to build a site is with a css grid to make your site handle different resolutions.
I agree that javascript is a terrible language fortunately things are improving if you look at the latest standards being developed for newer versions. I guess we can only hope that it improves to the point where it doesn't just outright suck.
I think that the problem you have is that JavaScript doesn't match your experience and/or expectations of how a programming language should work.
The scope rules of JavaScript are actually very straight forward. The problem is that most languages have block-based scope. JavaScript instead has function-based scope.
As for proper "object/class" support, well, classes are just one way of doing objects, and not the only way. JavaScript has first-class support for objects. It's inheritance model however is prototype-based, rather than class-based. It's a different paradigm, but no less valid.
Your experience and expectations of how a language should work (probably based on experience writing C++, Java, or any number of other languages) say that scope must be block-based, and object models must be class based. Those aren't the only solutions though.