As someone who has come around to Javascript after many years avoiding it, I think I can answer you: people like Javascript for a similar reason to why people like Python. As long as you stick to a strict set of conventions, Javascript is a very compact and manageable language, with a bit of extra flexibility to spice things up due to its prototypal nature.
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.
Same same. Though I'm happy with having a lot of stuff out of the stdlib because we know where that kind of things leads. As long as performance is good enough, that probably won't be a problem and discoverability is still ok (agreed the ecosystem not yet too vast although we're getting there). My gripe is with all the unfinished stuff in just about any javascript library out there.
Any chance you could point out a couple of good resources that cover the "strict set of conventions" you mention for Javascript?
I've been dabbling in Javascript projects for a while now, and one of my biggest frustrations has been that I haven't been able to find any great resources that cover best-practice code design (above the level of style guides that cover mainly syntax issues). It would be great to have a couple of resources that cover the "right way" of doing things.
It's extremely simple - basically everything is a hash. It has full lambda, not just crippled lambda like Python. It's very fast (I think it is the fastest scripting language except for Lua, and getting faster because of the browser wars).
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.
Non-string values are not valid hash keys. Operations that should be type errors fail silently and return nonsense. The prototype system is less powerful than the OO system of basically every other scripting language. The language will never have continuations, so people who want real control flow are stuck using preprocessors to generate callback spaghetti. Encoding a particularly rigid mix of dynamic and lexical scope into the language specification, such that everyone must be exposed to dynamic scoping much of the time, is one of the worst ideas I can imagine.
Non-string values are not valid hash keys. - ES6 Maps
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.
Sure if you prefer static typing then JS is not for you.
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.
I personally don't like that everything's a hash. It's nifty, and it means you don't really need objects, but I kinda like objects, even if I don't use them frequently in Python.
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.
It takes less than an hour to learn and get used to it if you know the standard Java-style OOP already. It's worth it and it'll give you a whole new opinion on what OOP means.
I know how it works, I just find it worse, by far. There's a whole lot more overhead to getting it working, specifically all of the foo.prototype stuff, and it doesn't require that everything be together.
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.
It's very good to see more and more people openly admitting that JavaScript's prototype-based OO approach just isn't
practical.
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.
> In any sizable JavaScript code base, especially if third-party libraries are used, these incompatibilities can become a very real issue, very quickly.
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.
Your entire complaint is very superficial and easy to fix with any convention you like. For example: http://jsfiddle.net/AXTdj/3/ I included "overhead" calculations.
@eob - same problem, couldn't reply directly to you.
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 think JS is more elegant than Python - just different tastes, I suppose. I find the crippled lambda unacceptable, and I don't like things like len() as a standalone function (in Python).
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.
Comments
JavaScript is my favorite programming language. It's not perfect, but still. (Other languages I know: Ruby, Python, Java, Go, Scheme, C, Erlang).
Why? I really would like to understand, because I see JS as a necessary evil, and would rather use something else if given the option.
As someone who has come around to Javascript after many years avoiding it, I think I can answer you: people like Javascript for a similar reason to why people like Python. As long as you stick to a strict set of conventions, Javascript is a very compact and manageable language, with a bit of extra flexibility to spice things up due to its prototypal nature.
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.
Same same. Though I'm happy with having a lot of stuff out of the stdlib because we know where that kind of things leads. As long as performance is good enough, that probably won't be a problem and discoverability is still ok (agreed the ecosystem not yet too vast although we're getting there). My gripe is with all the unfinished stuff in just about any javascript library out there.
Any chance you could point out a couple of good resources that cover the "strict set of conventions" you mention for Javascript? I've been dabbling in Javascript projects for a while now, and one of my biggest frustrations has been that I haven't been able to find any great resources that cover best-practice code design (above the level of style guides that cover mainly syntax issues). It would be great to have a couple of resources that cover the "right way" of doing things.
I think most frameworks for JS are opinionated, I mean things like jQuery, Sencha, AngularJS, emberJS, or also various server side frameworks.
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's extremely simple - basically everything is a hash. It has full lambda, not just crippled lambda like Python. It's very fast (I think it is the fastest scripting language except for Lua, and getting faster because of the browser wars).
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.
Non-string values are not valid hash keys. Operations that should be type errors fail silently and return nonsense. The prototype system is less powerful than the OO system of basically every other scripting language. The language will never have continuations, so people who want real control flow are stuck using preprocessors to generate callback spaghetti. Encoding a particularly rigid mix of dynamic and lexical scope into the language specification, such that everyone must be exposed to dynamic scoping much of the time, is one of the worst ideas I can imagine.
Non-string values are not valid hash keys. - ES6 Maps
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 :)
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.
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.
=> 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.
Sure if you prefer static typing then JS is not for you.
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.
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 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
[2] http://www.stackless.com/
[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...
[9] http://lua-users.org/lists/lua-l/2006-01/msg00652.html
That's changed since then: http://docs.racket-lang.org/json/index.html
I personally don't like that everything's a hash. It's nifty, and it means you don't really need objects, but I kinda like objects, even if I don't use them frequently in Python.
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.
You can use objects in JS if you want to - but fair enough, different tastes and preferences.
I didn't say you couldn't, I just skimmed over them. The prototype stuff is funky to me, I'd rather just have a straightforward syntax with objects.
It takes less than an hour to learn and get used to it if you know the standard Java-style OOP already. It's worth it and it'll give you a whole new opinion on what OOP means.
I made this a while ago, see if you can figure out how it works: http://jsfiddle.net/AXTdj/
I know how it works, I just find it worse, by far. There's a whole lot more overhead to getting it working, specifically all of the foo.prototype stuff, and it doesn't require that everything be together.
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.
It's very good to see more and more people openly admitting that JavaScript's prototype-based OO approach just isn't practical.
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 plenty practical, I will welcome ES6's class keyword for the clearer semantics, but this is simply vague FUD.
Your entire complaint is very superficial and easy to fix with any convention you like. For example: http://jsfiddle.net/AXTdj/3/ I included "overhead" calculations.
You know that you can just do
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.
@eob - same problem, couldn't reply directly to you.
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 think JS is more elegant than Python - just different tastes, I suppose. I find the crippled lambda unacceptable, and I don't like things like len() as a standalone function (in Python).
Yeah that len thing's weird, I probably had similar thoughts when I started using Python, but got over it.
I don't use lambdas, so that doesn't carry into how I compare languages.
Reasons to like js:
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.