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.
Re:What. The. Fuck? (Score:5, Funny)
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: (Score:2)
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...)
Re: (Score:3)
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...)
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.
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!
Coming from a PERL guy (Score:2, Informative)
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*
Re: (Score:3)
Err, it would be if you, like, you know... commented a little in the damned thing. ;)
Re: (Score:2)
First of all, that's not even valid Perl. You can't write "sin($aa) sin($bb)" or "$aa*$aa $bb*$bb" because the space character is not an operator (in AWK, it's the string concatenation operator in certain contexts).
Second, the assignments to $aa and $bb are confusing because you left out parentheses around the right-hand side. This is not Perl's fault; it's the author of the code's fault that it's confusing. It would be much clearer as:
my ($aa) = ($a =~ /(\d+)/);
Third, what the hell is this code trying to d
Re: (Score:3)
You aren't writing the same function. Why not skip the two maps and do:
@sorted_array = sort{ (-M $a) cmp (-M $b) } @files_array;
____
and if you like the mtime rather than -M just define a 1 line subroutines.
Re: (Score:3)
Perl objects aren't great (it isn't really and OO language)
Efforts are being made to improve them. Have a looke at Modern Perl [modernperlbooks.com] and what it proposes about objects [modernperlbooks.com].
Good stuff on other matters too. I even discovered there a very interesting use of goto to make a tail call elimination, something that's still unavailable in Java. Of course, this being goto, I have a psychological blockade to actually use it, even though I know that Perl's goto is far more sane than BASIC's.
Re: (Score:2)
Hellfire; if you write .NET or even PowerShell correctly it's perfectly readable. If you comment it correctly it can be perfectly maintainable, too (well, for as long as all the parts are non-obsolete, anyway).
But noOOoo.... everyone's gotta be the cleverest mofo in the effing room, forgetting all about the poor slob who has to maintain the damned thing 2 years later...
Re: (Score:2)
Have you ever noticed how many people write English well? On top of that, there's writing well, and writing concisely. Where one person may get an idea across clearly in two sentences, it may take another five or six. Any language will have the same problems to varying degrees; the trick is to coax people towards being concise.
Re: (Score:2)
But conciseness isn't always the right goal. Take legalese- it's very concise. That's why its used. It isn't readable. Or take perl- people can do an awful lot in 1 line, but nobody can understand it without really studying it. Doing it in 5 or 6 lines instead can be much more readable, and thus maintainable.
Re: (Score:2)
Legalese is very far from concise. That's part of the problem with it. If it was more concise and was frequently refactored, the law would be much shorter and easier for the average person to understand.
Re: (Score:2)
No, it is *VERY* concise. Specific words have an extremely specific meaning, and new concepts are defined in detail. That's why it reads the way it does. Writing it in plain english would take 5 or 6 times the amount of space to mean the same thing.
Re: (Score:2)
I find it's way too open to interpretation to be described as concise. Precedent based law would not be required if it were actually concise.
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: (Score:2)
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.
I noticed this the first time I opened the source code of a simple Python application. It was very hard to decode what was going on, even though I'm proficient in Basic, C, C++, Pascal, Algol, Perl, Lisp, ML, awk, csh, matlab, prolog, logo, Ada, Cobol, TeX/LaTeX, postscript, scheme. You'd figure that those should be enough to interpolate the meaning of any program in a reasonable language.
Re: (Score:3)
Re:Readability (Score:4, Informative)
Of course it is possible to write unclear code in Python - preventing that would be impossible while retaining a useful language.
The whole program sits wrongly with me - for one, the user is using io.open() instead of the open builtin - there is no good reason to do that. Next they are opening files and relying on the garbage collector to close them (not using the with statement as would be sensible), then they use string operations on data they have told us is binary data, use a nested loop in a generator expression, which yes, is ugly, instead of using itertools.chain() to flatten the iterable.
So how would I write the same program?
itertools.chain() is the more efficient and readable way of flattening a 2-layer iterable, instead of the 'horror' you point out. This version also writes bit by bit, rather than joining in-memory, meaning that it doesn't load the entire thing into memory, meaning it will work with extremely large input files (larger than system memory). The use of the with statement means that the files will be closed even if an exception occurs. Plus, the whole thing is more readable.
Python is much more conducive to writing legible code - note neither example involves lots of indices on a list, for example. It's not a miracle worker, but given people who have taken a bit of time to learn the language, it makes writing very readable code very easy. That's a great thing - it's not an instant fix, but trust me when I say I know Java just as well and yet I could never write more readable Java than I could Python for any given task.
Re:Readability (Score:4, Interesting)
Why can't the language resemble more readable (English, or native language) rather than obfuscated math.
Because page after page of MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN really sucked. put background field "name" of card n of background "data" after card field "list" wasn't much better.
The problem with Javascript is not that you can't write good Javascript programs. Javascript has an adequate feature set, the syntax is no worse than C, and reasonably fast implementations are available. It's that the language encourages the writing of bad code, which then has to be debugged by others. Object-oriented programming was retrofitted into Javascript, and it shows. Typical bad Javascript has global variables that should be local, shared data that should be in closures, no proper objects, and no comments.
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?
A bit late for this. (Score:5, Funny)
It's 2013, and someone is discovering Javascript?
Re: (Score:2)
It's 2013, and someone is discovering Javascript?
Just wait until tomorrow when they discover Livescript.
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: (Score:2)
It's the only thing you can run in a web browser.
FTFY.
Re: (Score:2)
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?
Re: (Score:2)
Anyway, what does he mean by "enterprise adoption"? Neither Javascript nor Perl were conceived "for the enterprise".
They were both conceived to make it easy to do simple things. One in web pages on the client, the other in anything with a CLI, even your toaster (if you have a decent toaster, which would have a CLI).
(Perl added to the "make simple things easy" the "and difficult things possible".)
I'm not sure what "for the enterprise" really means, but I'm pretty sure that if that is how I perceive a languag
Re: (Score:2)
You might want to read that sentence again. The part you quote is about Perl, not Javascript.
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: (Score:3)
Re: (Score:3)
More like constants, I wasn't being clear enough. With Compass I can do something like (as a contrived example):
$base-color: #aaa;
$border-color: darken($base-color, 20%);
$header-color: lighten($base-color: 20%);
Now by adjusting $base-color border and header colors are changed as well. And this is a very trivial example - if you write CSS even semi-professionally I suggest you look into it. The documentation (as always) is not the best available, but IMHO the framework is very much worth learning/using.
Atwood's Law (Score:2)
Modem noise (Score:4, Informative)
But, hey, lots of people like them, so they must be good, right? https://www.destroyallsoftware.com/talks/wat [destroyallsoftware.com]
Re:Modem noise (Score:5, Informative)
I've heard many respectable criticisms of Python, but I've never heard anyone say it looks bad.
Visually, it's probably the most elegant-looking language there is.
Re: (Score:2)
Until you need the power of regular expressions. Then Perl starts looking pretty clean again.
Also, it's easy to write bad looking Python. Just use the same naming convention for variables, methods and objects. That is the first thing I encountered coming on to maintain my first Python script.
Re:Modem noise (Score:5, Interesting)
Can you give some examples of "new language features" which don't "fit within the OOP paradigm" and which look horrible in Python?
Re: (Score:2)
Yah. And Perl still looks like modem noise.
Try programming in TECO [wikipedia.org]:
It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text. One of the more entertaining games to play with TECO is to type your name in as a command line and try to guess what it does. Just about any possible typing error while talking with TECO will probably destroy your program, or even worse - introduce subtle and mysterious bugs in a once working subroutine.
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: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: (Score:3)
node.js is an event driven server for Javascript. A better Perl example would be POE. Of course, POE has a lot more modules and options.
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.).
Adoption (Score:2)
[...]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.
With respect... (Score:5, Funny)
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 [wikipedia.org]. ]
Properly understanding javascript.. (Score:5, Funny)
.. is just like leaving an abusive relationship, its all about getting closure.
GWT? (Score:3)
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.
I blame Node.js (Score:2)
Node.js (Score:3)
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 [tumblr.com]
Perl's purpose (Score:5, Informative)
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.
Incomprehensive garbage (Score:4, Interesting)
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.
Better JavaScript (Score:3)
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.
I actually like Javascript (Score:3)
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".
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.
Re:I don't.. (Score:5, Funny)
How many javascript developers does it take? (Score:5, Funny)
10,000. 1 to hold the bulb, and 9,999 to turn the house around.
Replace Javascript with Perl as the situation commands.
Re: (Score:3)
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: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: (Score:2)
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: (Score:3)
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: (Score:3)
Anal stretching seems to comply with this rule with popularity of goatse.
Re:I don't.. (Score:4)
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.
Re:I don't.. (Score:5, Informative)
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 [stackoverflow.com] - 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.
Re: (Score:3)
Oh, they're not. They're just not what the syntax suggests they ought to be. Every other braces-and-blocks language on the planet uses block scope, so anyone who's been brought up on C, C++ or Java and sees code like this:
if (b) { var i = 1; fnord(i); }
...will naturally assume that i is local to the block. It's not something that they think about, it's pure hindbrain reflex. I've been bitten by
Re: (Score:3)
I would guess that some people find closures confusing or hard. They're pretty cool, but you do have to be careful with scope.
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.
Re: (Score:3)
C lacks proper object/class support as well; is C a horrible language?
JavaScript isn't a classic OO language, using it as such will not work.
Try using JavaScript as a prototype-based language (http://en.wikipedia.org/wiki/Prototype-based_programming).
JS has plenty of problems, there's no need to invent new ones.
Re:I don't.. (Score:4, Informative)
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.
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.
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: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:I don't.. (Score:5, Interesting)
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...
Re: (Score:3)
a new markup language that's meant to do pixel perfect rendering (HTML is not, but its used that way)
Very few people want a pixel perfect rendering markup language. They just say they want one while using a table to get the content to reflow into three columns of identical height with each 33.3% of the width of the window, whatever that is or is changed to.
Re: (Score:3, Informative)
Web browsers are for browsing the web. http, ftp, gopher, mail, news. If they were supposed to be restricted to http, they'd be called http browsers.
Web sockets were created because HTTP lacks efficient two-way communication. polling. long polling, comet, insert-new-buzzword-here are inefficient hacks to allow a client to be notified of a server generated event.
Re: (Score:3)
Leaving a connection open to receive messages from the server is what many conventional TCP clients do. Same goes for polling. Just because it's HTTP doesn't magically make it bad.
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:I don't.. (Score:4, Informative)
Whaaaaat. Why are you putting all your shit in the global scope in the first place? Use the module pattern [adequatelygood.com], and none of those functions leak out of the file you're in.
Re:I don't.. (Score:4, Interesting)
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.
Re: (Score:3)
the best way to build a site is with a css grid to make your site handle different resolutions
Which is still pretty useless as it doesn't account for actual physical dimensions. A pixel is not an SI unit of size, and sites that look good on the fixed monitors I use are too small for comfortable reading on my 15" widescreen laptop. Until there's some tracking of dot pitch in the OS and browser, any attempt at designing-in sizes is doomed to failure.
Re: (Score:2)
Wakanda IDE (Score:3)
Re: (Score:2)
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.
In my most recent projects we did use Namespaces where we could. We also used JavaScripts bastardized version of OOP class syntax. Do you know how many developers in the company or on the project even understood that class syntax? Not many. Even the guy who wrote them (me myself and I) find them horrible to manage when dealing with even simple updates to POJOs in Java that then also must be reflected in the JavaScript class constructors. Poor design I'm sure you'll be claiming...but let's be clear...we had
Re:I don't.. (Score:4, Interesting)
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.
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: (Score:3)
Yeah, I have a background in C and C++, and I taught myself Perl with the Llama Book. While the book is pretty good at pointing the differences between Perl and C, it took me some practice to get rid of some basic C reflexes.
Case in point, the ternary "C style" for syntax. You can guess a beginner (or a codemonkey) in Perl to the number of occurrences of it. Experienced Perl programmer only use it when there's no other convenient (and more legible) solution - i.e. almost never.
Re:Whats wrong with JS? (Score:5, Interesting)
Re: (Score:2)
Its a shame we don't have some sort of error handling facility that would throw an exception in cases like this.
Re:Why is it always cool to bash Javascript?!?!? (Score:4, Informative)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
All?
Really?
Are you *SURE* about that?
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: (Score:3, Insightful)
Perl, Python, Ruby all superior languages to Javascript with none of the bloat of Java.
Re: (Score:3)
Try Flash