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.'"
What. The. Fuck? (Score:3, Insightful)
What is this? Slasdot's daily troll story?
capcha: manure. How appropriate.
Readability (Score:3, Insightful)
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.
Very Different (Score:5, Insightful)
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?
Re:I don't.. (Score:5, Insightful)
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.
Lacking enterprise adoption? (Score:5, Insightful)
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?
The web is just too successful (Score:5, Insightful)
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.
Re:I don't.. (Score:5, Insightful)
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.
Baxter Doesn't Know What He's Talking About (Score:5, Insightful)
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.
Re:Readability (Score:5, Insightful)
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!
I'm not worried (Score:4, Insightful)
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.).
Re:I don't.. (Score:5, Insightful)
. 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.
Re:Readability (Score:5, Insightful)
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.
Re:I don't.. (Score:5, Insightful)
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.
Re:I don't.. (Score:5, Insightful)
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.
Re:Indeed. (Score:5, Insightful)
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...
Re:Baxter Doesn't Know What He's Talking About (Score:5, Insightful)
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.
Re:Readability (Score:5, Insightful)
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?
Re:I don't.. (Score:5, Insightful)
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.
Re:I don't.. (Score:5, Insightful)
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.
Re:Web (Score:1, Insightful)
Java is horrible, plain and simple.
Javascript (no relation to JAVA) is keeps being extended by third parties into crapful implementations. It's actually just fine and rather easy for beginners to learn, unlike Perl. Also if you learn it, things you learn from it can be applied to C.
The problem comes along when browsers don't have the same level of implementation and performance, and then people demand things from it that it should never have been doing (eg WebGL, SVG, Sound and Music generation/Mixing) to try and turn the web browser into a multimedia platform it was never supposed to be.
It's not the language's fault. But Java is worse (You're lucky if the host has a Java VM at all, let alone a 64bit version. Nobody has a bloody clue how to run a Java application without a OS-centric runtime.)
JavaScript = One language, many runtimes, different performance levels, and poor/non-existant threading.
Java = One language, one runtime, consistent performance on the same hardware, inconsistent performance on different platforms, extremely poor hardware support (worse than Javascript)
The irony with Java is that people keep trying to do the same thing with Java that they're trying to do with Javascript, these languages are not the right tools for multimedia. Period.
Multimedia requires a complete re-think about how media is played, and we were part way there with Macromedia Flash (Not Adobe's versions) but then Adobe went and turned it into a generic video player and people no longer make multimedia using flash. It's now sole purpose is Video advertisements.
If we could stop this stupidity and look at why we need OpenCL, OpenGL, etc it's because these are hardware scaling issues that we can't do with C/C++/Java/Perl/PHP/Javascript/etc with how people have been taught, and might still be being taught computer science. We need a C-like language that is multimedia aware and scaleable at the compiler level.
What we should be able to do is something like
main()
{
new mediacontainer = openmedia("cateatingacheezeburger.mp4");
mediacontainer.requirevideohardware(true);
mediacontainer.languageselect("EN");
new subtitles = openmedia("subtitles.csv");
mediacontainer.overlaychildmedia(subtitles);
mediacontainer.moveplayhead("23s");
mediacontainer.usefullscreen(true);
mediacontainer.play();
}
The underlying compiler should then link in the OS-dependant libraries to enable playback of said file as needed. If the OS lacks the libraries, then it should just STOP unless it's optional. Let the software use the underlying threaded, possible hardware support. Quit reinventing wheels.
But no, this isn't what happens at all. What keeps happening is that people become obsessed with turning all these easy to use languages into OOP models that only they understand.
Re:Web (Score:5, Insightful)
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.
Re:I don't.. (Score:5, Insightful)
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/ [google.com]
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.
Re:I don't.. (Score:5, Insightful)
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."
Re:I don't.. (Score:5, Insightful)
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.
Re:Web (Score:3, Insightful)
Perl, Python, Ruby all superior languages to Javascript with none of the bloat of Java.
Re:Web (Score:1, Insightful)
I'm sorry, I must have missed the bloat.
Is it the high performance VM, is it the cross platform runtime libraries or has 1996 called and they want their bytecode interpreter back?
Re:I don't.. (Score:5, Insightful)
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
Re:Uhm... (Score:2, Insightful)
I'm fond of saying that javascript is the worst language ever invented - however, that's only because I've put Perl out of my mind completely.
Have you tried PHP?
Re:I don't.. (Score:4, Insightful)
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.