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.'"
I don't see why not keep it as the web language it is.
http://mc.jamonek.com - Minecraft Signature Generator
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?
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
Atwood's Law: "Any application that can be written in JavaScript, will eventually be written in JavaScript."
But, hey, lots of people like them, so they must be good, right? https://www.destroyallsoftware.com/talks/wat
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
You'll never need more than 640K.
Sheer idiocy. Javascript won ages ago and people are only now waking up to this fact? You new here?
It really is quite brilliant and the only language I thought was worth using since I learned C in 1976, and I've tried them all.
It would perhaps to watch the 8 hours of Doug Crockfords videos to catch up on why this is true.
Need Mercedes parts ?
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
I second and approve this WTF statement and I read the TFA.
I would say PYTHON and PHP 5 have a better chance at replacing PERL and emb_perl capabilities then javascript every will.
[...]but lacking enterprise adoption on large applications.'"
Yeah, it's not like google, facebook youtube and a few other players use it for their frontend.
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. . . .
It's not that its a bad language, it is just so accessible that all the worst (non)programmers write in it. Take a look at the relatively poor quality of questions with a javascript tag on stackoverflow... if you ever thought there is no such thing as a stupid question, that will almost certainly change your mind. Iirc this was the case with perl in its early years. Maybe it will change with the release of ECMASCRIPT-1.D.10.T?
Yep. It even has the obligatory mention of C++ to lure the little fishes in.
(comparing a web scripting language with an adult language like C++ makes no sense anyway...)
No sig today...
fp.pl?
(Score:5, Funny)
by CptChipJew (301983)
Thursday January 22 2004, @11:24PM (#8062958)
open(heart_to_perl);
content-type: haiku/firstpost;
or die "i fail it";
C|N>K
Scenario, im new to perl. Would you consider this simple sort of subroutines human readable?:
@s = sort mycriteria @a; /(\d+)/; /(\d+)/;
sub mycriteria {
my($aa) = $a =~
my($bb) = $b =~
sin($aa) sin($bb) ||
$aa*$aa $bb*$bb;
}
I agree, that correct oop practices and not abusing special chars helps (the latter has always been rampant at every shop I ever worked at, as you said programmers are lazy), but make no mistake, the above is not readable to a beginner.
.. is just like leaving an abusive relationship, its all about getting closure.
http://rareformnewmedia.com/
So the author of this article likes GWT? Is the future Java on the client side? We used to have java applet clients in the early web-days, but it didn't really go anywhere because it was a pretty much a separate environment which didn't interact with DOM. Right now GWT is really mostly yet another framework that cross-compiles into Javascript. Perhaps the best usage outside of the framework is simply enforcing a statically typed infrastructure on top of JavaScript, at worst it's usage is sort of "lint" for JavaScript.
Although there's some marginal benefit from a statically typed regime, if this is all that the future requires to be up to snuf for enterprise usage, that's a pretty low bar for the next ECMAScript. They could just add a few checking attributes to the ECMAScript Object prototype to lock-out the dynamic nature of the object and developers could just migrate their "important" code to use this style of object that if they wanted to be "enterprise". You could even decorate these "finalized" objects somehow to hint the ECMAScript JITs to get any performance advantage you might get with statically typed languages.
Sadly this would eliminate the dynamic type features that make dynamically typed languages more powerful than their statically typed counterparts (although Generics/Templates bridge some of that gap for static languages like Java/C++). Of course with great power comes great responsiblity, and it's possible to write unmaintainable code in nearly every language, but it seems everyone has thier golden bullet to solve the "enterprise" coding problem. I'm usually unimpressed by golden bullets.
A couple of months ago I started working for a large company (over $1billion per year turnover) who use Perl a lot. I am working on one of several business critical applications. The one I work on is over 400,000 lines of code including tests (and some javascript). There is a team of more than 30 perl developers.
Before taking this job I interviewed at a number of other potential employers who also use Perl for large projects which are very much current in their business.
This is mostly due to to people not understanding the full capabilities of the language or blaming lack of DOM standards on Javascript. Javascript properly utilized can be used to create OO code which in the right hands can be maintainable in large applications, ever hear of JQuery, JQuery UI ? You can get a grid control in a few lines of code; AJAX where you can update a portion of a page instead of the whole thing, all of this occured because of people discovering the latent capabilities of Javascript. Fucking JSON, which data becomes running code and code can transform into data.
I guarantee, no one wants a strongly typed language to write a web apps. The JS engines far outstrip any Java VM performance, where is Java now? Fucking ivory tower white elephant.
Javascript is great because a dummy could get into it and actually make something, but I suspect because its this low learning curve is not "geeky" enough for some folks. Javascript is in the same boat with HTML, its just "too easy and loose". If that mentality had persisted, the internet would not be what it is today. We will be stuck in a geek paradise with less than 1000 websites all about the latest fork of linux but they would be happy because we are using C++ to code LOLCATS.
I've seen far too many developers get excited by Node.js. Boggles my mind, personally, but the idea of a Javascript back-end is coming.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Nah - I chalk it up to incompetence this go 'round.
If they really wanted to troll, they'd chuck in a mention of how they should use it instead of C to write the FreeBSD kernel, or say that JS is somehow going to replace .NET.
(/me ducks and runs like hell...)
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)
I do not agree with this article because Perl and JavaScript are two whole different languages. I use Perl everyday to write simple scripts from everything to running Regular Expressions (while I'm not using Python). I've faintly used JavaScript when writing web applications in node.js, but I've never really needed it for anything else. Perl can do web and GUI development (in Perl/Tk and CGI), but it does way more. JavaScript only does web development, while Perl does way more. I would agree with a statement more like "Python is the new Perl", but nothing else seems to come close to Perl.
Its a shame we don't have some sort of error handling facility that would throw an exception in cases like this.
Have gnu, will travel.
Agreed... especially since there's another verb already that conveys the exact same notion.... "liken".
File under 'M' for 'Manic ranting'
The reason that the error rate is so high with javascript on websites is because the environment in which it is most commonly used, a web page, such mistakes are generally of no real consequence, and it's pretty certain that most (if not all, but I would hesitate to make that broad a generalization) programmers are lazy
Blaming a language for the fact that it's usually used in environments where it doesn't actually generally matter if the programmer was too lazy to write correct code is like blaming the inventor of the automobile for people who get into accidents while driving drunk.
File under 'M' for 'Manic ranting'
Java will dominate the server side and a lot of other places simply because Vinod Khosa made it the instructional language of India combined with the drive by the Fortune 1000 to lower programming wages regardless of quality or long-term consequences.
Java failed on the client side. Javascript/HTML5/CSS won.
Even in the new mobile devices, with all the weight of Google and Apple thrown behind Java and the JVM, Java will, once again, lose to Javascript/HTML5/CSS.
Yes, Java is the new MS-DOS of the server world and if someone could actually own it by keeping secret the API (hence upward compatibility paths), the way Gates owned MS-DOS, they'd be the new richest man on Earth regardless of the fact that Java and its entire culture is basically about throwing gibbering hoards at a problem. Java is a jobs program for Indians. I suppose distributing the wealth in a jobs program has merits compared to giving a bunch of money to one guy.
Seastead this.
Doing pretty good as a web language.
that's out of necessity.
web browsers have JS intepreters so you have to use it so it does well in that. frankly I'd rather be writing java, but as it is for historical reasons the java integration and isolation into 'safe' environment like JS was never done for browsers.
Javascript is horrible but it's still better than perl! or php for that matter.
world was created 5 seconds before this post as it is.
I think it's more like an assembly language that flies 10,000 feet over "bare metal". There are quite a few things that generate JavaScript. Guys are working on projects that target it. People program in $whatever, and target JavaScript.
It won't get Perl'd. It'll get 386'd.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Perl:
@sorted_array =
map { $_->[0] } # extract original list elements
sort { $a->[1] $b->[1] } # sort list by keys
map { [$_, -M $_] } # pair up list elements with keys
@files_array;
Ruby:
new_list = old_list.sort_by {|file| file.mtime }
Yep, PERL certainly looks more readable.
I was surprised to see wakanda exists. At first the thought of all client and server side being in javascript struck me as loony. But they do have some interesting demos. Honestly haven't dug into it extensively and it may not be applicable in the real world. The trials I did with it made the typical AJAX things surprisingly easy. Anyone on /. happen to use it in the real world?
So... Node.js, chalked full of easy ways to leak memory (ie don't change default debug console, or use a crappy gzip library) but the ability to write code that runs/renders either on the server or on the client with the same code and low-level libraries to make the decision of the best place to render--ie render same code on server or client--makes JS on the server-side rather attractive. I run, Operations side, over 1000+ websites on a Node.js farm (talking 200-300 mbit/sec of sustained daily web-traffic), and it scales a lot better than PHP from both a templating side (many similar but different sites with inheritance based properties) and from the performance scaling side.
From a PLT side, yea, JS ain't the best, but it's a defacto web-rendering technology and its use on the server can simplify a lot of things, not to mention that JS in V8 is pretty quick to boot, although it does have heap limitation based around the 32-bit code V8 generates.
I leave comment readers with a wonderful link: This PLT Life
This was ripped straight from John Klassa / Raleigh Perl Mongers / Sorting in perl.
JavaScript is terrible. At least Perl has a semi credible namespaces and library mechanism. If you have a big site with loads of JavaScript, you are just lost in mega page mishmash. And, JavaScript doesn't even have a native decimal or currency type, and the way JSON stores represents dates is just aweful. So, no, JavaScript is not going to take over the world.
This is my sig.
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.
Actual LOL, thank you sir.
B) Eliminate all the stupid users. This is frowned upon by society.
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, it is not write-only. It can be read, too. The trouble with Perl is that between writing and reading, information is lost.
now we need to go OSS in diesel cars
I laugh every time without fail - extremely funny.
-- Lattyware (www.lattyware.co.uk)
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.
"...I found that JS became much more predictable once I learned a little more about what was going on..."
I am sure many of us have inherited code written more on a superstition than an understanding of JavaScript. When badly written it can be hard as all hell to trace the errors. However when it is understood and used correctly it can be very powerful while providing an elegant and often very short-and-simple solution to what you are trying to achieve. I read a book recently, JavaScript The Good Parts [http://shop.oreilly.com/product/9780596517748.do] which, while it was a little dry to read, did a damned good job of pointing out the misconceptions and wrong ways to use types and classes, and pointed out the correct patterns for using the power of JavaScript correctly.
That book, combined with the introduction of jQuery, gave JavaScript a whole new level of fun, at least for me. Of course on the down side it made me want to rip thru years of old code (which I have not been allowed to replace/delete yet) and rewrite it in a fraction of the amount of JavaScript code that is currently used to badly achieve its purpose.
I have to wonder if those who decry JavaScript the most have the least understanding of how to use it properly - altho I have to admit, it was never intuitively apparent exactly what were the right and wrong ways of using types, functions, classes and closures.
If I had a DeLorean... I would probably only drive it from time to time.
Perl, Python, Ruby all superior languages to Javascript with none of the bloat of Java.
I heard about this new application callled "NCSA Mosaic", maybe that has potential to adopt javascript and make it big.
--
Stay tuned for some shock and awe coming right up after this messages!
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?
I watched the video you linked to. I have been programming in JavaScript for years now. I was puzzled by the odd results that the author obtained, but having seen doesn't make me feel like JavaScript is inadequate for what I use it for. After all, why would anyone ever try to do the non-sensical calculations he asks JavaScript to do. Why would you ever ask JavaScript to do {} + []?
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
It's a religion. Speak ill of it and you shall face the wrath of the monks.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
Slashdot comments are HTML (or a subset thereof), and so < and > are special characters. Either write them as HTML entities, or use <ecode> element to wrap your code snippets.
Perl is the duct tape of computer science. Python is a good attempt to create a dynamic applications programming language. "There’s more than one way to do it" is key to Perl's whole approach and Python is just the opposite. I agree that some of what Python is a good alternative to Perl, I don't agree on replacement.
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?
Javascript is faster nowadays though. Is making a JIT (or similar) for Perl/Python/Ruby harder than for Javascript? Or is it just because enough $$$ and smart people were thrown at the problem?
You know what's funny? I actually enjoy seeing these submissions. The conversations that ensue tend to emphasize where this statement might be true as well as where it isn't. I actually find the majority of insight on most submissions in the comments and often completely skip the articles. Articles tend to be just a single person's stance anyway.
MouseClass extends ScrollClass, which extends TabClass, which extends SidebarClass, which extends PowerClass, w
perl has a very specific scope
js has a very specific scope
The overlap between the two scopes is not big.
for tasks in the center of its scope, perl is still the best - filtering some plain text file is just easy in perl. Perl never ran on any browser. but perl ran on pretty much anything else (I used it on DOS)
And js was never used in a significant extent to filter text files.
js in not new (so it can not be the "new" perl)
perl was inteded as an easy to learn extension-mixture-replacemnt of shell,tcl/tk,awk,sed. It still is and it is working well. (although tcl/tk still has something going for it (robustness, easy cross-platform gui)).
if there is on thing, which would be "the new perl" then it would be php. Most of the www things which would have been written in perl from 1995-2000 now are written in php.
I'm no fan of JS but last year I decided to give it a try anyway, first because of Node.js, phonegap and later Meteor.com. I tried CoffeeScript several times and slowly I've become a big fan and all our new code is written in CoffeeScript. Much less typing, very readable (nothing like Perl) and if you add underscorejs to the mix you get a very nice and concise language that looks and writes a bit like something between Ruby and Python - which you can use both on the server and the client!
It is snide but I like the signature on this comment. May
repeat but will attribute to oodaloop @ Slashdot. It sort of may
be a troll, but Javascript is++
John Eadie [JE46] http://www.c-art.com `one of these days the dogs aren't going to eat the dog food' - Bill Joy
I see a lot of people talking about Javascript encouraging bad behavior.
Javascript by itself does not encourage any specific behavior.
People relying on global shared namespaces and reimplementing classical inheritance tend to misuse language features in order to make JS look like C++ or Java. This approach sounds awesome, lets take completely different semantics for runtime, explain it as being similar to different semantics if you use a function then complain when it does not act 100% the same, awesome.
It seems like people forget CS101, encapsulation, DRY, separation of concerns, etc. Sure blame the language when you don't even pay attention to the basics. Don't encourage people to pay attention to best practices, just rely on the language. The language.
Use the best tool for the task.
Also a lot of those you listed don't do many of the things Java can do well, day 1. It's a difference of putting things in standard libs and making them ultra-configurable via files/xml/attributes instead of conventions or not at all. It's often a matter of taste and certainly can be annoying. But for those of us that do more than just simple web programming, even Java can look amazing and make Python, Perl, and Ruby look like trash.
JavaScript: The Good Parts by Douglas Crockford shows a way to write clean, conscise and predictable code in JavaScript. (It is also very short book, which I find hilarious. Even then the most important points in the book are in the first half or so.)
The most powerful idea IMHO is the use of function scopes as the main data structure instead of dictionaries. Another idea is avoiding or skipping completely some language features that behave in unusual ways and using simpler more fundamental constructs instead. I think the new-operator is the classic example of these.
I recommend this book wholeheartedly for anyone learning JavaScript and having some prior programming experience.
...they want their headline back.
'The unexamined life is not worth living' - Socrates
The closest thing to that at the moment is a JVM.
Then why do I have to install two or three versions of Java on each desktop to support my enterprise apps?
Oh, nevermind.
Darn.
What we really need is a compiler that compiles Java down to Javascript.
All the power of Java but no Oracle, no endless update nag screens and one less source of browser exploits (JVM exploits are a big problem in practice).
No sig today...
High performance VM ROFL.
You can have all the articles about how java can potentially, theoretically, in specially crafted scenerios be just as fast as C (or in some claims faster, which is a logical error, there is nothing stopping you from building an application specific tuned bytecode with dynamic optimization in C that will perform as fast or faster than the generic one used by java) but in the REAL world, large applications written in Java run slowly and use lots of ram.
Java is nice and portable but real world performance lags far behind the highly optimized Perl the submission seems to be bashing.
May I quote you on my sig, Sir?
Java has been a security hell for the last two years so...no....bad idea.
my point about java was that it's much better language to write in and to maintain code.
that it wasn't integrated(and isolated from os! so that people would actually keep it on) as well into browsers as javascript is the only reason javascript has foothold. speed advantages etc would be on java's side, javascript is just teh suck(even memory use would be on java's side, you could do most dom manipulation with jvm itself taking few hundred kb's of memory...).
world was created 5 seconds before this post as it is.
Perl is faster than Java? HotSpot > Parrot. There is no JIT VM for Perl.
I said closest thing, not solution.
Unfortunately I already switched to python 3 for my own coding. They need funding to support python 3: http://pypy.org/py3donate.html so clearly money is an issue.
Feel free to use it without attribution. I came up with it myself, but I don't think it's so creative that no one else could have.
Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
Please, stop saying it. JS is the only reason the web we're experiencing is shitty right now. because it's really easy to write horrible code with it, actually you have to code horribly in order to do make it work. WTH.
I know it's a controversial opinion, but modern JavaScript is OK.
All modern browsers support the ECMAScript 5 version of JavaScript. That includes a number of useful additions to the language.
IMHO the most important addition is strict mode. That disables some of the most egregious features of the language, making it harder to shoot yourself in the foot. Strict mode can be enabled for a whole file, or on a function-by-function basis - you just need to include the line "use strict"; (including the quotes) at the top of the file or function. As it's just a string it will be ignored on older JS interpreters making it backward compatible too.
Depends on real world, I guess. In my real world, well written Java code (nothing fancy, just no stupidity) was running on par with C++ code (by "on par" I mean within 3 times slower, quite often within 1 - 1.5; int based code even tend to be slightly faster), but yeah, it needed much more memory.
The only part that really seriously lagged behind, was math functions like sin/cos, at the time I've checked, in JVM it was a two pager C code, instead of using CPU capabilities (multi-platformness was the cause I guess).
The major misconception is that JIT is producing code that is inherently slower than static compiler. Well, guess what, it's on the opposite. Unlike static compilers JIT compiler can gather runtime information and use it when deciding which branch to prefer etc. You got memory management, bounds checking etc that you have in Java but don't have in C++, but part of it can be switched off by jvm switches.
Try Flash
LOL I meant Flex, sorry
JavaScript has improved greatly over they years, but for serious work it's still lacking a centralized repository for libraries. Most other scripting languages have something equivalent to CPAN, even if it's not as good. CDNs are close in terms of providing libraries widely, but they don't have an elegant way to find things and use them.
Perl is mediocre until you consider CPAN. That's the real joy of using Perl.
MidnightBSD: The BSD for Everyone
I was forced to develop javascript and I did not like it. My approach was to apply several design patterns (Fowler/GoF) for the project I worked in and found that it was my thinking that was wrong. I adapted and I am convinced that whilst javascript has a lot of crap surrounding it, the core language is quite good, if you use it properly.
One of the main hurdles I had, was to consider javascript as a browser event language. After a while, it flowed as nicely as C does. Ironically "Javascript; The good parts" is about the same size as K&R's "The C programming language".
My ism, it's full of beliefs.
It was hear...it was superior and more intelligent than Java in many ways. Strongly typed. And could have been adapated to the HTML DOM if Adobe's CEO had half a brain. Yes, abandon Flash, but ActionScript is actually a nifty language.
One that 98% of the complainers have never looked at. I think it's funny once a programmer actually starts looking at AS3 and exclaims "wow, that's kind of cool".
Look what they did with Spark components in Flex. HTML5 went and created all these stupid new input types. AS3/Flex4 went the other way and reduced their input types. What's the difference between a radio button and a drop down? Nothing but presentation. Both are simply selectable lists. Checkboxes and mult-select box? Nothing. They're just a multi-select list. So Adobe went and remove the visual layer from the model and control layers. Now you just "style" the appearance as desired.
This was the RIGHT PATH to move in Programming. And where HTML5 SHOULD HAVE GONE, but did not.
Correct me if I'm wrong -- I'm not a web developer -- but aren't Perl, Python, and Ruby all run on the server-side? There's a need for client-side implementation, and Javascript is it. (The only alternative I'm aware of is ActiveX, of which the less said the better.)
Genocide Man -- Life is funny. Death is funnier. Mass murder can be hilarious.
This dinosaur feels compelled to remind you, sonny, that all languages suck, including JavaScript.
Do you think anything you just wrote would be anything but cryptic to someone unfamiliar with English?
"Perl 5 provides word-oriented aliases to all of these variables, if you choose to write COBOL in Perl. Oddly, most folks don't."
-- Larry Wall on his choice of name for Perl's "$_" variable
One is client-side, the other is server-side.
It's not because they both involve coding; they can be compared to eachother.
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
3 times slower is hardly "on par." I tend to define real world as actual large complex java projects in the real world. So things like OO or Minecraft or any of the other large complex projects put out for public consumption. I can think of java programs where speed didn't get in the way but I can't really think of anything in java that is fast and efficient.
You:
"Unlike static compilers JIT compiler can gather runtime information and use it when deciding which branch to prefer etc"
Me in the post you replied to:
"there is nothing stopping you from building an application specific tuned bytecode with dynamic optimization in C that will perform as fast or faster than the generic one used by java"
There are no advantages to a JIT. If you actually have one of the rare use cases where it provides a significant benefit you can build a task specific solution and a parser in you statically compiled language of choice to add a dynamic capability. At the end of the day the JVM is written in a statically compiled language. It is literally impossible for it have any sort of capability that can't be implemented in a statically compiled language.
What does a JIT VM have to do with anything? But yes, actually there is, or something that gives the same benefits. It's called an interpreter. Internally the Perl 5 interpreter compiles to an intermediate machine independent bytecode which it then executes. You can keep that bytecode and run later just like you do with java. Outside of a few specially crafted research problems designed to show performance increases with JIT there is no reason to desire it anyway.
There are plenty of major applications written in both Perl and Java. I can't think of the last time I noticed the performance of a Perl app. Java on the other hand is a constant nightmare. Of course there is OO.org but lately I've been playing with Minecraft and Minecraft servers. OMG what a slow memory hog that thing is! There is literally no reason for it to be either. Write the same thing in C and the memory footprint would be megs and not gigs and it would run smoothly on old low end pc's and not just high end ones. I can't think of any instance where I was impressed with the speed of a java app only cases where they didn't get in the way. Another example, look at all things android. What was Google thinking basing it on Java when they have limited cpu and memory resources?
JavaScript is the only reason we even *use* the web today. If developers had avoided it en mass for the failed reasoning you've outlined, we would all be using Flash or some other plugin for the majority of our "web" browsing. There is a need for a common client-side scripting language - JavaScript is that language, and you should be bloody grateful it's not something far worse.
Also, your assertion regarding code quality is simply not true. You have a choice whether to write horrible code or not. If you really believe poor code to be a requirement of JavaScript development, you should avoid programming altogether (perhaps you are not a programmer, in which case I must apologize).
JavaScript supports the patterns and idioms required by proper application architecture. Perhaps it is not the prettiest language when used correctly, but that doesn't make it inadequate. That makes it ready for a new version (see ECMAScript 5/6).
Bytecode is not executed, it is again interpreted. The only thing a CPU can execute is machine code. That's what a JIT VM does, it turns the bytecode into machine code then executes that and most importantly, saves it for later.
My last experience with Perl was replacing a network monitoring system written in Perl with Java. The Perl version would fall over when presented with > 2 million events a day. The new Java code handled > 100 million with lower latency. How's that for an anecdote?
Google was thinking effective sandboxing and excellent tool support. It's easier to sandbox code when it runs in it's own VM. It's also more portable. I guess they picked Java as the language because it has the biggest set of IDE's available and they're quite fond of Eclipse.
By the way, the Java language and the JVM are only losely coupled. You can compile many languages to run on the JVM, like JRuby, Groovy, Jython, Clojure, Processing and Scala. That's just a small list. You can also compile Java to machine code with the help of GCJ.
I wouldn't be surprised if Perl dropped Parrot soon now the dynamic language instruction has been added to the JVM, since that was one of their excuses for rolling their own.
"The only thing a CPU can execute is machine code. That's what a JIT VM does, it turns the bytecode into machine code"
How is it that you think interpreted code gets executed without turning into the machine code that is the only thing the CPU can understand? Here is a hint. It doesn't. You can compile Perl, using the interpreter, into an intermediate platform independent bytecode that can be saved and executed (aka turned into machine code) on other platforms.
"My last experience with Perl was replacing a network monitoring system written in Perl with Java. The Perl version would fall over when presented with > 2 million events a day. The new Java code handled > 100 million with lower latency. How's that for an anecdote?"
I'll raise you anecdotes. My current experience with Perl is a network monitoring system written in Perl. The Perl version is currently handling well over a billion events a day with low latency. I can't speak as to its upper limit.
Have a read of what JIT is
http://en.wikipedia.org/wiki/Just-in-time_compilation
A plain old interpreter takes each byte code one at a time and executes code that perform the functions they're supposed to.
One with JIT analyses the bytecodes that execute a lot and runs them through an optimising compiler
Some of the many things that happens are:
Removing code that has no effect
Reordering instructions
Converting dynamic method calls to static
Loop unrolling
Code in-lining
That's why some benchmarks can show Java beating C. Because the JIT compiler can optimise the code to the specific hardware it is running on (eg: number and type of CPU's, cache sizes and memory latencies).
There are certain optimisations that can't be done at compile time. You can't statically link to dynamic methods unless you can undo the static link at runtime if new code is loaded. You can't remove thread synchronisation code unless you know at runtime no other threads could possibly touch a variable and no method that references it can be overridden.
If you interpret your byte code one at a time, you can't do any of that.
Why doesn't somebody port python into a browser as a scripting language? Seems like a much more powerful language, it is easy to read and use, and has reasonable scope rules. This is a no-brainer for a company like Google, that uses python for lots of things already. If chrome was programmable in python (with appropriate security modifications) it would destroy JS in about 20 minutes.
(Actually, I'd prefer lisp, ala elisp, but that is simply too scary for most people to contemplate, I suppose)
Go to Heaven for the climate, Hell for the company -- Mark Twain
While it's possible to use JavaScript in a good way, and some of what is there is good, the language itself is a mess of poor design. Something much, much better could give the features that JS gives, without all the horrible design. It's worse than PHP, and that is impressive.
-- Lattyware (www.lattyware.co.uk)
Everyone makes mistakes, stuff happens you didn't intend, and a good language will either error straight out, or give reasonable, easy to spot results (null in Java, for example), that indicate an error. JS is full of stuff where if you get something wrong, the language just explodes in crazy. That's not helpful, especially given web stuff is annoying to debug at the best of times.
-- Lattyware (www.lattyware.co.uk)
I agree with the post. Javascript is a difficult language, but makes it a horrible one is not just the language but how its used. It was not designed to be used in web application of the scale which is demanded nowadays, an as any technology/library/architecture which is used beyond what it was designed for, it sucks. It's just broken this way - the way of web applications.
Many people say it's not broken, people just don't know how to use it. For some, the complexity of the language is not a problem. Similarly, for some the complexity of C++ is a walk in a park, but most agree that not dealing with pointers is progress.
Ask yourself - if there are no problems in Javascript, why there are dozens of frameworks which look the same - for example, the frameworks which create classes, libraries, and other basic elements of the typical programmers toolbox. The reason for that is that Javascript lacks these things - and also lacks the ability to progress - build more complex things on top of simpler ones. It's designed to be used for writing simple things - like an event handler. And you can see how it is not suitable for other things - by the fact that most of libraries reinvent the same again and again, and there is not much reuse among them. Javascript lacks the basics of modularity.
If there was nothing wrong with language, why there are GWT, Typescript, Dart? The first and the main reason for coming up with these is to compensate the ugliness of Javascript (and the rest of Web technologies).
It's being discussed before - you can only patch something for so many times until you hit the limits. Either through code decay (for example, due to backwards compatibility) or mere requirement to patch within the limits - you cannot achieve the same as you would achieve by recreating something from scratch. I don't think Javascript-next is the answer because of this reason, so I also think we need a new set of technologies.
And I'd like to emphasize that Javascript as language is alright - has pros and cons. Javascript for Web is horrible. An example is Javascript in Node.js, where it is complimented by good modularity and platform integration. And the existence of Node.js only confirms that I stated - it highlights the problems of Javascript on the web.
On the web , it's also worsened by the HTML (try creating a sizable Java/Swing application with just one class where you are only allowed to use basic elements - text and rectangles - that's analog of DOM and HTML, a technology misused for almost 20 years without modularity and assembler like instructions), and CSS (if there are no problems in CSS - why SASS/LESS? CSS needs modularity and decent tools no less than other technologies).
So I frankly believe it's time to reboot the matrix - why people are so afraid of new in the web, while they witness so much great invention elsewhere? And I smell conspiracy.
the only thing that prevents perl/python/ruby from being used in client side web programming is the browser makers including the interpreter in their browsers. Since we are talking about what would be nice I decided to mention how much better those languages are than Javascript and Java for client side web programming.
http://stackoverflow.com/questions/9032856
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
I'm not sure what the intention was of the response - but I'm not saying JavaScript isn't deterministic, it's just not a sane set of rules that define what goes on in cases like this - the length of that answer shows how poorly designed the language is. It shouldn't need such explanation.
-- Lattyware (www.lattyware.co.uk)