Forgive me for not being hip but why try so hard to put JS in new places? It seems to be just an unfortunate historical accident that JS is one of the most popular languages in the world - does anyone actually like it compared to other modern scripting languages? Could we invest in CoffeeScript instead, at the very least?
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.
Check my second paragraph, I quote some of things I like most in js as a language. Nothing there is exclusivity of javascript and many other languages implement the same features but I do enjoy javascript as a language and the fact that it is evolving, successful and ubiquitous helps a lot.
I'm not who you originally asked, but I share his sentiment that javascript is a nice language. I've used python for years, have a few open source applications with Java, and written several scripts for my own purposes in C. I've also explored C++, haskell, scheme, ruby, and MIPS assembly. Not a whole lot of PHP. So I use javascript for everything? Not even close. But I still like it.
In recent times I have delivered commercial products in PHP, Python, Ruby and LiveCode. In the past (way past more than 10 years) I used to work with VB, Delphi, REBOL and some Java. While I was coursing engineering, we learned scheme (its great!)
CoffeeScript is JS. And to be more honest and judgemental, CoffeeScript is the sweeter-but-poorly-documented 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.
But the one-page manual of coffeescript is far more useful to users than those looong specifications. No document about the syntax is better than the annotated source of the parser. And you can find specifications about all kinds of javascript runtimes elsewhere, they document the coffeescript runtime too.
Language specifications are important for interoperability. They are very useful for people who write tools like smart IDEs or linters. They are also interesting for people who want to create their own VM or compiler. There are various JavaScript and Java VMs. There are also various C and C++ compilers.
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.
I like JavaScript. It is a very intelligent language, far ahead in its design than more recent products like Dart. If you was not insanely focused on its drawbacks, you could see its qualities too.
Your post is content-free. What do you consider explicit advantages of Javascript over Dart? Because to my eyes Javascript looks like a similar language with no type system and terrible scoping.
I enjoy JS a lot, and will frequently choose it over Ruby or Python. A functional style plays nicely with a lot of the problems I'm solving, it's nearing ubiquity, and there's lots of big names and smart people working on optimizing it even more.
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.
It's disappointing to see the false "JavaScript is functional" claim thrown around time and time again.
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.
Why it's always C/C++ (not even Pascal or Oberon) in another corner of the ring? If hardware is powerful enough to sustain Node.JS, why not use OCaml, Racket or, maybe, some JVM-based language? Or, if the scripting is a requirement, Lua, Tcl or maybe Python.
C/C++ is always in one corner because it's the go-to language (heh) for code that needs to do direct hardware access and manipulation.
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.
Well I have been trying to play around with LLVM on ARM Cortex-M4 micro controllers specifically the STM32F4 series of my controllers there is a github project that tries to use Clang.
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.
I'd expect Javascript programmers dwarf Lua programmers by a couple of orders of magnitude. At least one OOM if you want to limit to people who only know the language "well."
In the game programming industry (PC games, not iOS/Android games), the two most popular languages are C++ and Lua. That's probably part of the reason why these two languages keep getting brought up in this thread to compare against Javascript.
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.
You do understand that CoffeeScript compiles to JavaScript, and that by supporting JavaScript they're supporting CoffeeScript, in addition to TypeScript, right?
JS is great - it's so hackable, via simple straightforward syntax that's familiar to anyone who programmed in c,c++,c#,java,php and is similar in ease of use to python and ruby - why on earth would you think it's a bad thing... Javascript is easy - few constructs that together can build just about anything is a big plus IMO - to each is thier own right
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?"
I'm curious. I persume, with quite powerful hardware, task's not going to be trivial and may require some concurrently running processes.
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?
This comment is a bit incoherent, so I'm not sure if I'm responding correctly at all. Your C/C++ program can contain any number of Lua states, and can also contain an infrastructure for passing messages between these states. The states themselves are single-threaded. Within a single Lua state, you can have any number of coroutines, but these do not work like JVM threads or goroutines; they must be scheduled explicitly.
Full disclosure I'm not a JavaScript programmer. I dink around with it. I can work with it. I understand it enough to maintain the code I need to at work, but I'm not a "JS Guy".
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.
When I see a device like this I like to think that people familiar with JS can now tinker with hardware devices. I know some people who are comfortable with JS but aren't engineers and they may not be willing to learn Arduino C.
Whatever language it is I'm glad prototyping devices are coming out at a cost that basically makes them an impulse purchase.
So, I don't really buy arguments like this. Would your friends who are comfortable with JS but aren't engineers actually be interested in learning microcontroller programming because they can do it in JS? When you move from scripting a web page to programming on a very limited embedded system, you're changing to a completely different paradigm. Instead of worrying about the DOM and AJAX, you're worrying about GPIO and PWM and interrupts. The actual syntax of the language is a rather minor detail compared to all of this. Now, I'm not saying that we should all be coding microcontrollers in ASM or AVR C, but what makes Javascript more approachable than, say, Arduino?
Because it takes a lot more time to learn another language proficiently than it does to adapt what you already know to a different platform. It's accessible.
It's my fervent hope that developments like source maps and asm.js will eliminate what it basically Javascript's sole competitive advantage; that it's the only language that runs in a browser.
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.
CoffeeScript is JavaScript. There should be nothing stopping anyone from doing everything with CoffeeScript on this device, or anything that supports JS.
The goal is seamless integration between physical hardware and a web application without the need for a server on the device. Sounds pretty awesome to me.
Because everyone* knows JavaScript. I'd wager that the vast majority of professional software engineers work on the web, or very close to the web, and JavaScript is the lingua franca of the web. I mean just look at the front page of Hacker News on any given week. It's full of talk of JavaScript and new JavaScript libraries and new things to do in JavaScript. When you think about how many more people this can reach without them having to learn yet another language for a very specific thing, it makes sense.
*hyperbole, please forgive me for being not being completely literal.
Everybody thinks they know javascript, but on the contrary nobody actually knows it. It's a very twisted and powerful language. It has many quirks and many unknowns.
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.
Some people do know javascript. Implementations differ, but are getting more standardized as time goes on. Without the DOM and browser environment APIs, it gets a lot simpler. Do you think fewer people actually know javascript than actually know C++?
C++ is a bad example. C itself is mindblowinly complex, and C++ layers more on top of that. A better example might be Python, or possibly Lua. Languages that have been designed, rather than grown organically, unlike C++/C/Javascript.
Yeah, but a basic level of javascript is often all that's necessary.
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.
I'd wager that the vast majority of professional software engineers work on the web
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.
And? That's brilliant, as it provides some progression after learning the language! Once you're confident with Arduino, you can move onto C++, from there ASM, etc...
I've dealt with these kind of programmers on numerous occasions. While they may claim to know other programming languages, they usually don't know much about them at all, in reality. If they do know another language, it's PHP, which is just about as bad as JavaScript in most respects.
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.
Well, that's just unnecessarily offensive. I'm proficient in Python, Java, and C, and was at some point also fluent in PHP, Ruby, and Lisp. While I wouldn't particularly enjoy coding in Javascript, CoffeeScript is, to date, the best language I've worked with. I debug in JavaScript, so I'm not that far away from it.
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.
There's nothing "offensive" about pointing out realities, even if they may be painful for some people to accept.
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.
There's nothing "offensive" about pointing out realities, even if they may be painful for some people to accept.
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.
JavaScript has issues, but they are largely syntactical. Yes, `==` means something different than it does in every other language - but it is still a useful construct (if not worthy of its own operator). Yes, `Class.prototype.method` is overly verbose, but in CoffeeScript you get clean syntax without losing the beauty of prototypical inheritance.
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.
There's nothing wrong with admitting that JavaScript is a really bad language.
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).
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
You don't have to use the OO inheritance features in CoffeeScript in order to like it on the whole.
This is the key. With good conventions and tools it is perfectly fine language. The concept of "Programming into one's language" from Code Complete applies strongly:
> 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
I've met talented JavaScript programmers. They're just quite good at using other languages, too, and thus choose not to use JavaScript whenever possible.
Can I ask why it worries you? Honestly just curious. Is it the performance hits of more levels of abstraction? Or fear of all data being in the "cloud"?
Personally it worries me because people can build whatever they want and call themselves "programmers". It encourages a state in the industry when knowing about data structures, hardware, turing machines or the other fundamentals of computer science are considered unecessary. Perhaps they are, from a business standpoint. However, it will eventually inhibit growth of the discipline as a whole.
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.
I understand where you are coming from, and I don't like the "it allows people to get into programming more easily" excuse either.
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.
I think that segregation in of itself can be dangerous too though. People will get stuck in the web programmer mindset, and never progress if they're interested in anything else.
You seem to think these programmers are content with simply learning only what they need to know and calling it a day.
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.
I don't intend to offend you, but I think you illustrate a problem with many programmers who have come into the field with a self-taught JavaScript or PHP background, and without any sort of a formal education.
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.
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.
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.
Programmer may have been an elite title at one time, but now it's just like saying gardner, chef, or scientist. You just have to work a little harder to figure out whether or not someone is a moron. There have always been morons and there always will be. I may be one of them!
To quote Sturgeon "90% of everything is CRUD". Majority of people that get CS now is due to money (how else to justify the expense of a diploma?), not the appeal computers have, and it's been like that for a while.
Lowering barrier to entry is +EV move, almost always. It multiplies crud but more importantly multiplies the 10% that are worth the crud.
As opposed to studying for five years in a college, learning Java and programming in Java exclusively, never learning anything outside the Java and never perfecting?
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.
As opposed to studying for five years in a college, learning Java and programming in Java exclusively, never learning anything outside the Java and never perfecting?
Comments
Forgive me for not being hip but why try so hard to put JS in new places? It seems to be just an unfortunate historical accident that JS is one of the most popular languages in the world - does anyone actually like it compared to other modern scripting languages? Could we invest in CoffeeScript instead, at the very least?
just to answer you: I Like Javascript.
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.
It sounds like you don't like Javascript as a language, you like it because it just happens to be successful and ubiquitous.
Check my second paragraph, I quote some of things I like most in js as a language. Nothing there is exclusivity of javascript and many other languages implement the same features but I do enjoy javascript as a language and the fact that it is evolving, successful and ubiquitous helps a lot.
How much experience do you personally have with other programming languages, aside from JavaScript (and perhaps PHP, if you're familiar with it)?
I'm not who you originally asked, but I share his sentiment that javascript is a nice language. I've used python for years, have a few open source applications with Java, and written several scripts for my own purposes in C. I've also explored C++, haskell, scheme, ruby, and MIPS assembly. Not a whole lot of PHP. So I use javascript for everything? Not even close. But I still like it.
In recent times I have delivered commercial products in PHP, Python, Ruby and LiveCode. In the past (way past more than 10 years) I used to work with VB, Delphi, REBOL and some Java. While I was coursing engineering, we learned scheme (its great!)
Having written c# for many years JS is like a breath of fresh air simply because it is dynamic and you aren't confined to the inheritance model of c#
CoffeeScript is JS. And to be more honest and judgemental, CoffeeScript is the sweeter-but-poorly-documented 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 do you mean by "CoffeScript is JS"? CoffeeScript is not JavaScript. CoffeeScript compiles to JavaScript.
I suggest that you refer to the CoffeeScript home page: http://coffeescript.org/
It very clearly states, 'The golden rule of CoffeeScript is: "It's just JavaScript".'
what?
There still isn't any language specification, is there?
JavaScript, TypeScript, and Dart have one.
But the one-page manual of coffeescript is far more useful to users than those looong specifications. No document about the syntax is better than the annotated source of the parser. And you can find specifications about all kinds of javascript runtimes elsewhere, they document the coffeescript runtime too.
Language specifications are important for interoperability. They are very useful for people who write tools like smart IDEs or linters. They are also interesting for people who want to create their own VM or compiler. There are various JavaScript and Java VMs. There are also various C and C++ compilers.
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.
Who needs documentation when you can just pop open a REPL and copy-paste your functions to see how they compile?
People who don't know javascript.
My thoughts exactly, instead of killing it off or at least limiting it to the browser, we're trying to shove that abomination everywhere. This is sad.
I like JavaScript. It is a very intelligent language, far ahead in its design than more recent products like Dart. If you was not insanely focused on its drawbacks, you could see its qualities too.
Your post is content-free. What do you consider explicit advantages of Javascript over Dart? Because to my eyes Javascript looks like a similar language with no type system and terrible scoping.
I enjoy JS a lot, and will frequently choose it over Ruby or Python. A functional style plays nicely with a lot of the problems I'm solving, it's nearing ubiquity, and there's lots of big names and smart people working on optimizing it even more.
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.
It's disappointing to see the false "JavaScript is functional" claim thrown around time and time again.
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.
Python, okay, but how are you prevented from using a "functional style" in Ruby?
When all you know how to use is a hammer, everything looks like a nail...
"True. When your hammer is C++, everything begins to look like a thumb." [1]
[1] http://www.anvari.org/fortune/Quotations_-_Random/3041_quote...
Why it's always C/C++ (not even Pascal or Oberon) in another corner of the ring? If hardware is powerful enough to sustain Node.JS, why not use OCaml, Racket or, maybe, some JVM-based language? Or, if the scripting is a requirement, Lua, Tcl or maybe Python.
C/C++ is always in one corner because it's the go-to language (heh) for code that needs to do direct hardware access and manipulation.
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.
Well I have been trying to play around with LLVM on ARM Cortex-M4 micro controllers specifically the STM32F4 series of my controllers there is a github project that tries to use Clang.
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.
I love python. It's nothing like javascript really. It's more like C, but with an approachable wrapper.
Because a lot of people know Javascript and C/C++.
Okay, maybe Racket and OCaml are relatively obscure options, but quite a lot of people know Java and Python. And I can't say Lua's not popular, too.
I'd expect Javascript programmers dwarf Lua programmers by a couple of orders of magnitude. At least one OOM if you want to limit to people who only know the language "well."
In the game programming industry (PC games, not iOS/Android games), the two most popular languages are C++ and Lua. That's probably part of the reason why these two languages keep getting brought up in this thread to compare against Javascript.
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.
You do understand that CoffeeScript compiles to JavaScript, and that by supporting JavaScript they're supporting CoffeeScript, in addition to TypeScript, right?
Of all the great languages out there... we had to choose Javascript.
It's a shame, would love to see more Smalltalk posts.
JS is great - it's so hackable, via simple straightforward syntax that's familiar to anyone who programmed in c,c++,c#,java,php and is similar in ease of use to python and ruby - why on earth would you think it's a bad thing... Javascript is easy - few constructs that together can build just about anything is a big plus IMO - to each is thier own right
Many of JS's "straightforward syntax" that "looks similar" to other languages, is subtly different in profound and dangerous ways.
If Smalltalk ran on every.single.browser.ever, you would.
This is an argument for writing JS against browsers, not stuffing it into every domain possible.
why try so hard to put JS in new places?
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.
Because JavaScript runtimes are the best dynamic language VMs by a long shot.
The JVM would like to have a word with you.
LuaJIT would like to have a word with JVM.
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?"
I'm curious. I persume, with quite powerful hardware, task's not going to be trivial and may require some concurrently running processes.
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?
This comment is a bit incoherent, so I'm not sure if I'm responding correctly at all. Your C/C++ program can contain any number of Lua states, and can also contain an infrastructure for passing messages between these states. The states themselves are single-threaded. Within a single Lua state, you can have any number of coroutines, but these do not work like JVM threads or goroutines; they must be scheduled explicitly.
I'll wait an hour for it to warm up, then come back and hear what it has to say.
Nitpicking: while JVM implementations can run, they're not particularly tailored for dynamically typed languages.
Clojure would like a word with you.
Just because you can build a dynamic language on a vm doesn't mean it was designed and optimized for it.
I don't think invokedynamic beats V8.
Source?
Full disclosure I'm not a JavaScript programmer. I dink around with it. I can work with it. I understand it enough to maintain the code I need to at work, but I'm not a "JS Guy".
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.
When I see a device like this I like to think that people familiar with JS can now tinker with hardware devices. I know some people who are comfortable with JS but aren't engineers and they may not be willing to learn Arduino C.
Whatever language it is I'm glad prototyping devices are coming out at a cost that basically makes them an impulse purchase.
So, I don't really buy arguments like this. Would your friends who are comfortable with JS but aren't engineers actually be interested in learning microcontroller programming because they can do it in JS? When you move from scripting a web page to programming on a very limited embedded system, you're changing to a completely different paradigm. Instead of worrying about the DOM and AJAX, you're worrying about GPIO and PWM and interrupts. The actual syntax of the language is a rather minor detail compared to all of this. Now, I'm not saying that we should all be coding microcontrollers in ASM or AVR C, but what makes Javascript more approachable than, say, Arduino?
Because it takes a lot more time to learn another language proficiently than it does to adapt what you already know to a different platform. It's accessible.
It's my fervent hope that developments like source maps and asm.js will eliminate what it basically Javascript's sole competitive advantage; that it's the only language that runs in a browser.
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.
JavaScript certainly has it's quirks, but if you get to know it it's not a bad language.
And since CoffeeScript compiles to JavaScript you can use it anywhere JS runs...
It's not a bad language as long as you know it well enough to know which parts of it are the bad parts so you can avoid them.
...and that's what makes it a bad language.
Or just don't learn the bad parts to begin with.
That's why there's a book called "JavaScript: The good parts" :)
CoffeeScript is JavaScript. There should be nothing stopping anyone from doing everything with CoffeeScript on this device, or anything that supports JS.
The goal is seamless integration between physical hardware and a web application without the need for a server on the device. Sounds pretty awesome to me.
I like it. It was the first language I learned because edu materials were more accessible (to me) than Perl/python/Ruby
I'd think Lua would have made a lot more sense.
Because everyone* knows JavaScript. I'd wager that the vast majority of professional software engineers work on the web, or very close to the web, and JavaScript is the lingua franca of the web. I mean just look at the front page of Hacker News on any given week. It's full of talk of JavaScript and new JavaScript libraries and new things to do in JavaScript. When you think about how many more people this can reach without them having to learn yet another language for a very specific thing, it makes sense.
*hyperbole, please forgive me for being not being completely literal.
Everybody thinks they know javascript, but on the contrary nobody actually knows it. It's a very twisted and powerful language. It has many quirks and many unknowns.
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.
Some people do know javascript. Implementations differ, but are getting more standardized as time goes on. Without the DOM and browser environment APIs, it gets a lot simpler. Do you think fewer people actually know javascript than actually know C++?
C++ is a bad example. C itself is mindblowinly complex, and C++ layers more on top of that. A better example might be Python, or possibly Lua. Languages that have been designed, rather than grown organically, unlike C++/C/Javascript.
C++ was grown organically? I think Bjarne Stroustrup would disagree.
By that I'd mean the way more and more complexity has been layered on over the years.
Of course some people do know Javascript inside out, but how many?
Yeah, but a basic level of javascript is often all that's necessary.
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.
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.
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.
Correction - everyone thinks that they know Javascript. It's a more twisted language than it appears.
It's still more approachable though than C or Lua where only some people think they know it.
And arduino is even more approachable again.
Don't you forget that Arduino is C++.
And? That's brilliant, as it provides some progression after learning the language! Once you're confident with Arduino, you can move onto C++, from there ASM, etc...
I may know javascript, but my god I wish I didn't have to.
Many people do enjoy writing JavaScript and view it as just as good as Python and others.
I've dealt with these kind of programmers on numerous occasions. While they may claim to know other programming languages, they usually don't know much about them at all, in reality. If they do know another language, it's PHP, which is just about as bad as JavaScript in most respects.
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.
Well, that's just unnecessarily offensive. I'm proficient in Python, Java, and C, and was at some point also fluent in PHP, Ruby, and Lisp. While I wouldn't particularly enjoy coding in Javascript, CoffeeScript is, to date, the best language I've worked with. I debug in JavaScript, so I'm not that far away from it.
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.
There's nothing "offensive" about pointing out realities, even if they may be painful for some people to accept.
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.
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.
JavaScript has issues, but they are largely syntactical. Yes, `==` means something different than it does in every other language - but it is still a useful construct (if not worthy of its own operator). Yes, `Class.prototype.method` is overly verbose, but in CoffeeScript you get clean syntax without losing the beauty of prototypical inheritance.
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.
There's nothing wrong with admitting that JavaScript is a really bad language.
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).
You don't have to use the OO inheritance features in CoffeeScript in order to like it on the whole.
This is the key. With good conventions and tools it is perfectly fine language. The concept of "Programming into one's language" from Code Complete applies strongly:
> 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
What a bunch of pompous bullshit. From what you've said it seems you've never met a talented JS programmer.
Do they exist?!
I've met talented JavaScript programmers. They're just quite good at using other languages, too, and thus choose not to use JavaScript whenever possible.
I'd wager that you know as much about javascript as you do about presenting a convincing point of view.
I agree. I sort of like javascript now, but it was an acquired taste after force-feeding myself the language.
If you're telling the truth, you don't know it.
Very nice analogy (the lingua franca). The state of CS and the convergence we're seeing toward the web worries me though.
Can I ask why it worries you? Honestly just curious. Is it the performance hits of more levels of abstraction? Or fear of all data being in the "cloud"?
Personally it worries me because people can build whatever they want and call themselves "programmers". It encourages a state in the industry when knowing about data structures, hardware, turing machines or the other fundamentals of computer science are considered unecessary. Perhaps they are, from a business standpoint. However, it will eventually inhibit growth of the discipline as a whole.
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.
I understand where you are coming from, and I don't like the "it allows people to get into programming more easily" excuse either.
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.
I think that segregation in of itself can be dangerous too though. People will get stuck in the web programmer mindset, and never progress if they're interested in anything else.
You seem to think these programmers are content with simply learning only what they need to know and calling it a day.
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.
I don't intend to offend you, but I think you illustrate a problem with many programmers who have come into the field with a self-taught JavaScript or PHP background, and without any sort of a formal education.
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.
http://boards.straightdope.com/sdmb/showthread.php?t=523412
https://yourlogicalfallacyis.com/notruescotsman
People like yourself are the exception, usually the majority follows what the parent post was stating.
As someone that codes since 1986 with a CS degree, I am often dismayed what many "programmers" seem to know nowadays.
Programmer may have been an elite title at one time, but now it's just like saying gardner, chef, or scientist. You just have to work a little harder to figure out whether or not someone is a moron. There have always been morons and there always will be. I may be one of them!
To quote Sturgeon "90% of everything is CRUD". Majority of people that get CS now is due to money (how else to justify the expense of a diploma?), not the appeal computers have, and it's been like that for a while.
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.
As opposed to studying for five years in a college, learning Java and programming in Java exclusively, never learning anything outside the Java and never perfecting?
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?
You can write Java in any language if you are persistent enough.