I like my functions as first class citizens. I like my prototypes and my inheritance model. I like my callbacks and my closures. I like how I can move from client-side, to server-side, to my TV, all with the same language. I like how easy it is for beginners to produce something useful and for seasoned developers to produce something good.
There are many other languages that share such traits but Javascript is one of the few that can be picked up by beginners interested in any field (eg: games, web, apps) and keep surprising you. It is extremely powerful in the hands of those that devote time to learn how things work. Its one of the few languages that you can learn as a beginner and keep with you as you become a better programmer.
I don't think it should be the only language someone knows but it should be a language that everybody knows.
So yes, there are people who like javascript.
The reason people are attempting to put javascript everywhere is because they can and because others enjoy it. And those who do enjoy JS, know what parts of JS are to be avoided at all costs. And I actually like it compared to other modern scripting languages for two reasons:(1) I don't have to worry about whether my end-user will have to worry about installing 100 dependencies to consume my code/service (2) I can choose how robust my setup is (Closure Compiler) or how sweet (CoffeeScript), and spend time sharing my setup with others who like the language instead of using proverbial sarcasm on topics about languages that I don't want to use.
what?
JavaScript, TypeScript, and Dart have one.
But there are also users who read them if they think that some particular behavior is puzzling. Then they check the spec to see if this stuff really is supposed to happen or if this is something which wasn't properly specified.
For example, there was a 50:50 split when it came to the behavior of SVG masking. As it turned out, that part of the spec was just confusingly written and the compliant behavior was actually really silly. The spec was changed and now every browser does the same intuitive thing.
Without this "central authority" there wouldn't have been a way to get this fixed.
Dart is another interesting example. They had a specification since the beginning and every part of the ecosystem follows it. This way, different teams (and even different companies) can create all kinds of tools which all have the same precise understanding of the language. Naturally, this also helps with identifying spec issues.
Without a specification, you have to reverse-engineer the behavior and you might end up being forced to replicate some really nasty crap. Some of JavaScript's warts were set in stone this way.
It very clearly states, 'The golden rule of CoffeeScript is: "It's just JavaScript".'
In my day job, we write mostly Coffee - which is little more than a preprocessor to JS, IMHO. It's definitely nice to have, but I don't consider it an independent language unto itself. If you know JS well, it shouldn't take more than a day to get up to speed with CS.
Just because it has first-class functions it does not mean that JavaScript is a "functional" language.
JavaScript does not promote the use of pure functions, referential transparency, and the minimization of state.
JavaScript does not encourage the use of recursion.
JavaScript has an atrociously broken type system, rather than a robust and theoretically sound one.
JavaScript does not offer pattern matching and other functionality offered by modern functional languages.
In fact, it goes out of its way to promote a very imperative, non-functional style of software development, even when efforts are made to try to use it in a functional way.
[1] http://www.anvari.org/fortune/Quotations_-_Random/3041_quote...
That said, if I don't strictly have to run C/C++, I'd much rather run Haskell or Python. And you'd be surprised where you can run high-level languages like Python; one project I work on runs Python in the GRUB2 bootloader to test BIOS and hardware, giving Python full ring0 privileges, raw memory access, ACPI method invocation, and SMP support. Some of the Python standard library is missing (an HTTP server, for instance), but quite a bit of it is available. See http://biosbits.org/ for that project.
Now if I had the time and experience I wanted to try and compile this library called py2llvm. The library that can compile static variables and python syntax into LLVM bitcode with C like performance. I think that is the best of both worlds.
With Python, you don't have to worry about the conventions part, since there is one "Pythonic" way to do everything. But at least with JS there are only a few different standard ways to implement, for example, OOP. So once you've gotten used to it, when you read someone's code, you can quickly notice what style they use and contribute your code to match it.
My biggest remaining gripe with Javascript is the lack of a good base set of libraries for container and string manipulation. Sure there are packages (like Underscore) you can use, but it would be nice to have them as a standard part of JS.
Once you specialize on using one of them, you'll probably adopt their conventions.
I myself haven't settled yet, too my own dismay. It's not easy.
It usually doesn't require a lot of boilerplate code.
What is not to like?
The one thing I worry about is the limited range of integers.
Your preference makes sense, it's just not the same one I have. More on topic for this thread, I'm still not convinced that it's a good thing for an embedded system.
I made this a while ago, see if you can figure out how it works: http://jsfiddle.net/AXTdj/
Sure, it's kinda nice that you're able to extends objects later on, but I'd rather have everything neatly declared in one place.
It definitely does not "give me a whole new opinion on what OOP means", it furthers my opinion that I'm not a fan of JavaScript.
foo.prototype = { dothis: function(){}, dothat: function(){}
}
In the beginning I wrote it more like
foo.prototype.dothat = function(){} foo.prototype.dothis = function(){}
Which was a lot more ugly.
For far too long now we've had to hear JavaScript advocates go on and on about how good JavaScript's approach is. Yet over and over we see developers being forced to fake a limited subset of class-based OO one way or another, just to get their work done effectively.
Of course, there are multiple ways of faking class-based OO in JavaScript, with varying degrees of compatibility with one another. In any sizable JavaScript code base, especially if third-party libraries are used, these incompatibilities can become a very real issue, very quickly.
This is one of the things that the JavaScript community should have addressed years ago.
Whether you use constructor functions, object literals, or the module pattern to structure your code in an OO-like manner, they all result in 'functions hung off objects' which can be called in the same way: object.foo(), I don't see the very real compatibility issue you're talking about.
>> It's very good to see more and more people openly admitting that JavaScript's prototype-based OO approach just isn't practical.
It's plenty practical, I will welcome ES6's class keyword for the clearer semantics, but this is simply vague FUD.
The prototype system is less powerful .. - No. Just different.
The language will never have continuations.. - Generators help here. We use them with node --harmony
Scoping. - Fat arrows and block scoping coming in ES6.
These features can be used today in node, by enabling the harmony flag. Otherwise wait until next year.
Yes, this is a good thing :)
> The prototype system is less powerful .. - No. Just different
Javascript let you use prototypes to cause map lookups for absent keys to fall back to a different map. Lua lets you use prototypes to override every operator, make the object callable, override map lookups for absent keys, and override assignment of new keys. All of these operations can be made to call into arbitrary functions the user provides. Python, an OO scripting language, provides all of the same features.
It seems to me that among these three languages there is a greater difference between the more powerful systems and the less powerful system than between the prototypal systems and the OO system.
> The language will never have continuations.. - Generators help here. We use them with node --harmony
Python also has generators, but you still need greenlet or stackless if you want to use coroutines. The inability to suspend from a subroutine is a deal breaker. Generators are probably nice for writing generators. For writing control flow, Continuation.js seems like a better choice.
> Scoping. - Fat arrows and block scoping coming in ES6.
=> lets you use a lexically scoped this, which is likely a dynamically scoped this from an enclosing lexical scope. This sounds useful, but it doesn't really make things less messy.
Continuations seem to be rare among other languages you could choose. Personally I have only seem them in LISP, what else is out there?
I would love to use LISP, but the libraries simply aren't there. Last time I tried Racket, there wasn't even a library for JSON.
I did not say anything about static typing. Most dynamic languages are not forced by their specs to coerce disparate types into utter garbage. I invite you to type the examples in the Wat talk into a REPL for any other dynamic language and see how many of them produce exceptions.
> Continuations seem to be rare among other languages you could choose. Personally I have only seem them in LISP, what else is out there?
Before answering, I will point out that coroutines are equivalent to one-shot continuations, and coroutines that can be copied are equivalent to multi-shot continuations. Then, I am familiar with continuation implementations in the following languages: Python [1][2], Scala with any JVM runtime[3], Any JVM language with a particular runtime[4], C[5], Lua[6], Julia[7], and C++[8]. Of these, the ones for the JVM, C/C++, and Lua[9] are multi-shot continuations or equivalent to them, while Julia and Python are a bit more limited. I am not familiar with many languages, so I'm sure I've missed a lot of instances of this sort of feature.
> I would love to use LISP, but the libraries simply aren't there. Last time I tried Racket, there wasn't even a library for JSON.
I can't really speak to this because I haven't spent time trying to build real software using lisp.
[1] https://pypi.python.org/pypi/greenlet
[3] http://jim-mcbeath.blogspot.com/2010/08/delimited-continuati...
[4] http://oss.readytalk.com/avian/javadoc/avian/Continuations.h...
[5] http://en.wikipedia.org/wiki/Setcontext
[6] http://lua-users.org/wiki/CoroutinesTutorial
[7] http://docs.julialang.org/en/latest/manual/control-flow/
[8] http://www.boost.org/doc/libs/1_51_0/libs/context/doc/html/c...
That's changed since then: http://docs.racket-lang.org/json/index.html
My main reason for liking Python isn't that it's compact and manageable (unless by compact, you mean the code one writes), but because I like the elegance of the language.
You're saying you have to stick to strict conventions for JavaScript to be any good? That would imply that it isn't any good to me. I use it, frequently, I just prefer not using it.
I don't use lambdas, so that doesn't carry into how I compare languages.
1) There are very fast implementations in production, as well as an arms race between some of the world's most powerful titans of software development to outdo each other at js vm performance.
2) It is a thin abstraction over the Reactor Pattern, which is very useful for certain kinds of event-based applications.
3) Very lively and robust package ecosystems in npm (node) and jQuery (web). Virtually all packages are async by default.
It's a shame, would love to see more Smalltalk posts.
Because its the current trendy thing. And chasing that dragon isn't necessarily a bad thing if it gets people in the door. Sure its an evolutionary dumb step in some ways but lowering the barrier to entry means that ideas that might not otherwise come to the space could get a chance to grow. Or if nothing else the trendy attention means more libraries get written, which helps someone else down the road.
There are a lot of blind optimism in that statement, but we all know that the best tech doesn't win. What wins is the good enough-ist tech that also pops enough buzzwords win the to interest of the dude that claims to only care about the best tech.
Plus, Lua isn't controlled by a creepy asshole who thinks the NSA is essential and says stupid shit like "Who's ever heard of government misusing information?"
JVM has threads. Akka adds actors (those seem quite nice when used with Scala). Does Lua/LuaJIT offer something simple-looking-yet-powerful in that area?
At the heart of my programming heraldry is C. From there I branched out into C++, Java, Perl, C#, etc.
In effect you are comparing JavaScript to Assembler, since CoffeeScript compiles to JS. I'm certain most people would agree that this is a ridiculous comparison, because as quirky as JavaScript can be it is far easier to work with than assembler. I wish people would stop making that comparison (I've been guilty of it myself, but I've stopped as of late).
In my view, the popularity of JavaScript comes down to two things: Interactivity and instant gratification.
I first played with JavaScript while in college in 1995. It blew my mind that I could just put some code into a text file and load it into Netscape and see stuff happen. No compiling, no linking, just text making the browser do things, and unlike Java it did not require me to upload an applet and hope that my target user had a JRE installed.
Today you have things like Chrome dev tools and JS Fiddle where you can get even more of that.
The velocity of going from idea to web app (site) is a lot nicer for most people.
IMHO JavaScript is the programming equivalent of an LLC. It's quick to start, low capital investment, and doesn't expose you to a lot of risk.
Anyhow...that's my two cents that I had to throw in before more veins in my head popped.
Whatever language it is I'm glad prototyping devices are coming out at a cost that basically makes them an impulse purchase.
If it's possible to write performant, robust code with good tooling in CoffeeScript/Dart/TypeScript/Python/Clojure/etc., then the peculiarities of Javascript become a lot less important.
And since CoffeeScript compiles to JavaScript you can use it anywhere JS runs...
...and that's what makes it a bad language.
That's why there's a book called "JavaScript: The good parts" :)
*hyperbole, please forgive me for being not being completely literal.
A common rebuttal to that is "it allows people to get into programming more easily". I personally think this is horseshit. There are a multitude of ways to get started with programming, and javascript is in many ways the one that teaches the worst practices and patterns of them all.
But I don't really think it will inhibit growth. I think that it is more likely just to create two main groups of people that call themselves programmers. The people that know HTML and jQuery and the actual programmers. I don't think it will do anything to the growth of real programming, it just might mean we get lots of people calling themselves programmers who really aren't. But that happens already.
As a self taught developer, I find it offensive that you think I would go through all the trouble of teaching myself how to code, and then rest on my laurels, like I wasn't inherently curious and thoughtful.
Since learning Javascript front to back, I've developed a curiosity with strictly typed languages, assembly, computer science, Big O notation and other (what I consider) hardcore disciplines in computing.
Javascript was my gateway, and I love it to death, but I'm not a javascript developer any more than a C developer is simply a C developer.
As someone that codes since 1986 with a CS degree, I am often dismayed what many "programmers" seem to know nowadays.
Lowering barrier to entry is +EV move, almost always. It multiplies crud but more importantly multiplies the 10% that are worth the crud.
Not sure where you are, but universities in Europe are not like in USA.
In many countries public universities are more renowned than private ones and in some, it is even quite symbolic what you pay per semester.
Type systems, complexity analysis, and assembly language programming, for example, aren't "hardcore disciplines in computing". They're the basic foundation upon which the rest of our knowledge is built. They are among the minimal level of knowledge that all programmers should have.
When you understand concepts such as those first, and are exposed to JavaScript later on, it's plainly obvious how inexcusably bad JavaScript is. While theory may not always work well in practice, JavaScript goes out of its way to ignore sensible and practical theory in every way possible.
People starting with JavaScript (or PHP; JavaScript isn't alone in being a bad language), but without this basic theoretical knowledge, don't seem to realize how bad the language truly is. It's unfortunate to see them not accept and admit to these flaws, even after the learn that there are much better ways of doing things.
Your second sentence pretty much defines "hardcore". The "hard core" of anything is what supports the rest. Originally the term is from the mid-19th century and refers to a layer of broken stones and bricks that provided support for a building project, commonly roads.
People's curiosity is what motivates them to experiment and learn new things, not how or what language they learn (I started with Basic which apparently causes brain damage and I'm getting along fine). If they are curious on their own, they'll pick up data-structures/asm/c etc.
Uau!? Do such universities exist?
Most of the time if one thinks s/he knows javascript, actually s/he knows a higher level abstraction library and DOM built on javascript like Jquery.
I had quite a few non-developers on my team, who knew enough javascript to have a "good enough" idea what was going on with the code, without having to bug me all the time.
Any programmer who has real experience with a variety of different programming languages will become very aware of how inferior JavaScript inherently is.
JavaScript's problems go much beyond the quirks or oddities we see with programming languages in general. They're severe deficiencies (the lack of proper modules or namespacing, and the lack of proper class-based OO), or inexcusably stupid design flaws (semicolon insertion, its broken scoping rules, its broken type system, its broken prototype-based OO, its broken comparison operators, and so on).
No intelligent, experienced, self-respecting programmer will want anything to do with such a ridiculously flawed and broken language. They surely will not see it as good as Python or any other language that isn't rife with the unjustifiable stupidity that permeates every aspect of JavaScript.
Why is "class-based OO" necessary? There's nothing wrong with prototypal inheritance. The way modules are done in Node is pretty powerful compared to other languages I've used. The scoping rules are different, for sure, but I don't really see why you'd call them "broken". They're internally consistent and easily comprehensible.
Semicolon insertion is, admittedly a problem. The solution, of course, is to put in your own semicolons. If you do that, and use something approaching reasonable whitespace conventions, there isn't really a problem. JavaScript's `==` the like are, for sure, broken, but that's nothing a `===` can't fix. It's not like the other languages you mentioned wouldn't have issues without reasonable conventions.
I find your arguments somewhat odd. You do openly admit that you "wouldn't particularly enjoy coding in Javascript". People don't say such things about good programming languages, especially when arguing in favor of them to some extent.
I also find it odd that you argue that there's nothing wrong with prototype-based OO, yet claim that CoffeeScript is the best language you've worked with. One of CoffeeScript's most useful and important features is that it adds very simplistic class-based OO to JavaScript. Go look at the example code in the "Classes, Inheritance, and Super" section of the CoffeeScript home page to see what I'm talking about. The CoffeeScript code is tolerable; the JavaScript that's outputted is horrendous. Hand-written JavaScript is often just as bad, if not worse.
The various JavaScript "module" systems are purely hacks. They abuse existing language features to fake modularity, poorly. They're nothing like the proper module support of other languages. And at least you admit that semicolon insertion and the broken comparison operators are serious issues. Many other JavaScript advocates refuse to, for whatever reason.
There's nothing wrong with admitting that JavaScript is a really bad language. I think you know that it is, and want to admit it, and I think you should. It doesn't deserve to be defended, because its problems are generally inexcusable in every respect.
Your use of the word 'admitting' is peculiar. There's nothing wrong with claiming that JS is bad. There's also nothing wrong with claiming it's good.
I enjoy programming in CoffeeScript more than any other language I've used (Ruby, Python, Objective-C, a little Java, a little C). Plus, as dynamic languages go, it's fast. To me, these two things make CoffeeScript a fantastic language.
And since CoffeeScript is just syntactic sugar on top of JavaScript, well, I suppose JavaScript must at heart be a fantastic language too.
(Evidently today's my "someone is wrong on the Internet" day).
The problem is that your comments about JS tend to contain more hyperbole and opinion than undisputed reality.
JS obviously has flaws. But so does English. It's good to have a natural language that a large percentage of the world's population, across nationalities and ethnic groups, can speak. I think the same applies in programming. Programming languages are not just for telling a computer what to do; they're also for collaborating with other programmers. And once a code base is written in a particular language, it's often hard to make a case for rewriting it in a different language. So why not use a language that is popular, is cross-platform, is vendor-neutral, has multiple optimized implementations, and is likely to remain popular and well-supported for many years to come? JavaScript is that language.
FWIW, I have much more experience with Python and Lua than with JavaScript. I also do some work in C++. Yet, despite JavaScript's flaws, I'm defending it as a general-purpose programming language.
The strengths of JavaScript, on the other hand, are deep. Everything is an object, functions as first-class citizens, the inheritance model, etc. The callback-based I/O of Node.js wouldn't work nearly as well in any other language I've seen, because JavaScript is such a good language.
I will take a language with syntactical deficiencies but a beautiful underlying model over the opposite any day, and I don't see anything about that statement that indicates that I'm a poor programmer who's only been exposed to PHP and JavaScript.
You don't have to use the OO inheritance features in CoffeeScript in order to like it on the whole.
> Programmers who program "in" a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer's thoughts will also be primitive.
> Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.
I disagree with Coffeescript though, nothing will make that shit readable to me. :P
Yes, a majority of prof. software engineers who work for internet companies work on the web. But then there's also stuff like embedded, systems, databases (not the ones you hook up to some scripting language to generate html), medical, aerospace, industrial processes, etc.
The software industry is huge and only a small part of it is web related.
> I mean just look at the front page of Hacker News
It's like assuming San Francisco was a model for all other cities on this planet. It's all about your local bubble. For you maybe really it looks like everyone (including your local coffeeshop owner) could win a JS hackathon. But for me I barely know an engineer who's fluent in JavaScript. Everything is C++ here.