I think that much of these criticism relate to the implementation, and the runtime (i.e. browser) rather than the language itself. As a scripting language for a browser environment it's pretty good. Modern variants have lots of lovely language features and tools like babel mean you can use a lot of these new features without sacrificing backward compatibility.
The threadless/nonblocking model is "interesting" but in my opinion its wholly suitable for user-oriented scripting as it forces a style of development that doesn't block.
The null/undefined thing actually makes sense to me. The concept of "Null" is a swirling vortex of uncertainty in most languages and it's nice to see it get some more nuanced treatment.
There's something about the bloody-minded pragmatism of javascript that appeals too ... it's very much a language that has evolved from the bottom up based on need, and much of it is very much community driven. You see problems solved in interesting and unusual ways that you mightn't see in a more stringently stewarded language.
I wouldn't use it for everything. I wouldn't prescribe it for beginners to programming either. But it's great for what it does. I like lots of other languages too, but I respect their applicable limitations. It's a nice language.
There are a lot of valid criticisms against JavaScript. This is a fact. It's not a great language (clearly demonstrated by the discussion about it being good or not) but it's not terrible. I doubt anyone calls JS terrible on its own merits. There is a lot of hate against the runtime (edit: I mean the browser, not JS VMs or interpreters). The runtime enforces JS and the runtime itself is enforced everywhere. There is also this new flow of very inexperienced developers who seem to think JS (and perhaps Ruby) is the only language. This is very similar to the hate PHP got. Pragmatic choices vs experienced having their "I told you so" moment when they see "sql_srsly_escape_string_this_time(...".
All this makes a lot of people react emotionally and makes talking about JS itself (like many other mass-adopted technology) very hard.
Is JS nice? Yeah, as my personal opinion - but we can all say that it is good enough, evidenced by the ecosystem and the things people create with it.
> It's not a great language (clearly demonstrated by the discussion about it being good or not) but it's not terrible
I'm wondering what would be an example of a great language? Because we know that there are only two kinds of languages: the ones people complain about and the ones nobody uses
I like to think of Haskell as a great language. It still has its warts (e.g. last [0,1/3..2] > 2), but if you wan't wart free, there's probably nothing beyond lambda calculus.
Being the closest thing to lambda calculus with enough syntactic sugar on top to make it practical is a large part of what makes Haskell great.
The one thing that makes Haskell not great is that its understanding is not widely intuitive.
People with mathy backgrounds that don't blink at the phrase "lambda calculus" won't consider this, but a lot of people struggle with math.
If you can't put it in the hands of a 6th grader (in the public school system with no special tutoring) and have a reasonable chance of it being understood (n.b. I self-taught myself early JavaScript when I was in the 5th grade, and picked up PHP the following year), it won't ever be "great".
This is the one criticism of Haskell that in my opinion has no merit. Programming languages are not intuitive. They are a learned skill. You know the saying (sometimes said as a joke) "such-and-such language failed because it didn't have C-like syntax" -- but C-like syntax is NOT intuitive! Reading C code is a learned skill.
Maybe it could be amended to "since many programmers learned to program using languages with a syntax inspired by C, wildly different syntaxes learned at a later stage are more difficult to them", which is a more reasonable proposition. This could be fixed by teaching programmers other languages early on.
Haskell is no more or less intuitive than JavaScript. It's just different.
> Programming languages are not intuitive. They are a learned skill.
I can teach someone Python or JavaScript in a few weeks, at a casual pace, where they can accept input from STDIN or a file, do some calculations, and produce output to STDOUT or another file.
Haskell? I'd need a dedicated fucking thesaurus on-hand for them to grok the paradigm, and it would take a few months before they could achieve the same result.
I have another point here:
If the only languages that are considered great are the ones that make people feel smarter than everyone else for being able to understand, we don't need great languages.
Most of us need easy, practical languages that help us solve problems and don't get in our way. (Most of achieving this property comes down to ecosystem rather than language design.)
> Haskell? I'd need a dedicated fucking thesaurus on-hand for them to grok the paradigm, and it would take a few months before they could achieve the same result.
This is one of those assertions people should have to demonstrate with actual experiments.
I can teach someone how to write buggy, unmaintainable code that seems to work but actually doesn't in Python and JavaScript. So? :)
My point here is that, while working with a "great" and/or "better-designed" programming language can be beneficial, it's the ecosystem that really counts.
No need for sarcasm and my argument wasn't that there aren't bugs in programs written in Haskell.
My argument is that people who claim "writing Python is easier" usually ignore that it's writing buggy/throwaway code in Python that is actually easier (aka "look, I can write bugs fast"). Writing large, maintainable and bug-free code in Python is not easier than in other languages -- it's arguably harder, but since that's debatable, I won't argue it here.
Even a "perfect" language is faulty if the barriers between its current state and mass adoption are insurmountable.
Completely reform education in this country to make purer languages like Haskell more palatable for younger generations than, say, PHP, and I'll totally be wrong in 50 or so years.
And I'm arguing that the average newcomer (if we need a specific definition of average, how about chosen at random among low-income American sixth graders far removed from big cities like San Fransisco or New York?) would have an easier time understanding Python to the level of being capable of basic file/network I/O than they would with Haskell, because Python will be more immediately familiar to them because they don't need to even know what a thrice-damned monad is.
I understand that's what you're saying, and I'm saying you're wrong because:
- Beyond toy examples, writing Python isn't easier. Writing reliable, easy to maintain, bug-free Python programs is just as difficult, and your average person won't be able to do it right off the bat.
- You don't need to really know what a monad is in order to write Haskell as a beginner; that's a red herring.
If you want to argue that it's easier to write toy examples in Python, without regard for good programming practices, then... it'd still be debatable: if I remember correctly, some years ago there was a post here about someone teaching Haskell to highschoolers, to great success. They found it fun and easy.
That's a fallacy. Just because something is harder to operate doesn't mean it can't be better. Example f1 cars vs normal cars, two propeller ships vs single propeller ones.
There is no language that is innately understood. All computer languages are learned, so when they describe "intuitive" I don't think this is what is meant. However, a large portion of early programming education does take place amongst C-style curly-brackets.
It's this learned setting for our precepts that makes other languages intuitive or not. If we were all learning fortran or pascal in college it might be different, but we're not.
That said, having C-style syntax is clearly not a pre-requisite for the success of a language as is attested by the success of Python, Ruby, various flavours of BASIC and other less loved languages like COBOL ...
But "intuitive" is very important for getting traction. Once you can "intuitively" model a problem in a language such that somebody familiar with the problem can understand what's going on, then that's intuitive. I'm talking about a different kind of intuitive here.
Most people engage with computers on imperative terms, i.e. they want to tell it to do things. Imperative languages are "intuitive" because they allow you to map out a list of instructions in order.
So for instance, when you're writing a program to make a cup of tea you issue those steps one by one. You don't want to have refine the model into a functional space, do a handstand and flip the bag into a mug with your little toe while inducing a small raincloud and microwaving the drops on the way down.
Similarly true object oriented langauges (I'm not talking about C or Java here, where classes are glorified structs) model how we think of information in terms of object-relations.
Functional languages to me as an experienced programmer are "intuitive", but even I sometimes flinch when I'm exposed to a stack of lisp ellipses ...
I think you're under-stating some things. Imperative programming languages are hard beyond their initial appeal at the "this is like a recipe" level. It's debatable how people best engage with computers. There are plenty of anecdotes, if you look for them, of people failing to understand that the assignment operator in imperative languages means "place this value in this box" instead of "this means that". It's just that you (and me) are used to this learned mode of understanding.
Modern programs seldom look like a list of imperative actions anyway, beyond toy examples. They look weird and unintuitive. If you can make the leap to "this is what an actual imperative program looks like nowadays", you can make a leap to declarative/functional programs just as well. Doubly so if you don't have to unlearn years of conditioning about how programs are supposed to look :)
It currently is a self-inflicted hurdle. I don't pretend this problem doesn't exist. One way to fix it would be to start teaching programming in a different way, and with different languages.
> There are plenty of anecdotes, if you look for them, of people failing to understand that the assignment operator in imperative languages means "place this value in this box" instead of "this means that".
Are there anecdotes of non-absolute-beginners failing to understand that? For first-year students, sure. Do working software engineers have trouble with it? Do they have bugs and/or lower productivity because of it?
> If you can make the leap to "this is what an actual imperative program looks like nowadays", you can make a leap to declarative/functional programs just as well.
My own suspicion (completely unsupported by data) is that some peoples' brains find imperative languages to be more the way they think, and some find functional languages to fit their way of thinking better. You could run an experiment to test that - you'd take a group (call it A) of functional programmers, and a group B of imperative programmers, and measure their productivity. You'd then split the groups in half. A1 stays functional; A2 starts programming in imperative languages. B1 stays imperative; B2 goes to functional. Two years later, you measure everybody's productivity again. What I expect you'd find is that some of the people who switched (either way) increased productivity, and some declined.
What you might find is that everybody who switched from functional to imperative was less productive, but that might be because the (somewhat rare) people who are already functional programmers are almost exclusively the ones whose minds work better that way. You could fix that by starting with students or with fresh graduates, and arbitrarily assigning them to group A or group B. Then you'd have to wait a couple of years to measure their productivity the first time.
The difficulty, of course, is figuring out a way to at least somewhat objectively measure their productivity...
> Are there anecdotes of non-absolute-beginners failing to understand that? For first-year students, sure. Do working software engineers have trouble with it?
Sorry, I was unclear: I was talking about beginners. My argument was about intuitivity and "it's easier/harder to learn programming this way". Software engineers are already down the road of "I'm used to this, therefore this is the best way" :P
If I understand you correctly, what you say is entirely possible: that some people think best one way or the other, and that there is no universal paradigm that is more intuitive.
So a language is more intuitive if it's similar to what we already know, and we already know math, and therefore "=" for assignment is not intuitive? OK, for first learning a language, I can buy that.
I don't recall ever having trouble with that myself, but that's anecdote, not data...
To be fair, I never had trouble with that either. It was just an example of something I've occasionally read about some people approaching programming languages for the first time.
> Programming languages are not intuitive. They are a learned skill.
True.
> C-like syntax is NOT intuitive! Reading C code is a learned skill.
Also true.
> Haskell is no more or less intuitive than JavaScript.
This does not follow. I have to learn the syntax of any language, true. But that doesn't mean that all languages are equally easy/hard to learn. I learned C by reading K&R over Thanksgiving weekend while in college. I understood everything except argc and argv, even though I didn't have a compiler to experiment with. I had to learn, true; I wasn't born knowing it. But I found it to be pretty intuitive to learn.
I doubt I could have understood Haskell from reading a book over a four-day weekend, without being able to experiment, no matter how good the book.
And, sure, there could be someone out there to whom Haskell syntax is intuitively obvious, and they look at C and wonder what all the crazy symbols mean. But I suspect (but cannot prove) that such people are less common than those who find C more intuitive.
TL;DR: No language is innately known. But some can still be more intuitive (for most people) than others.
Note well: I do not take any position on JS vs. Haskell as far as how intuitive they are.
I don't think the relative intuitiveness of Haskell vs JavaScript is a settled matter. I'm arguing one or the other may seem more intuitive because of past familiarity with similar languages/paradigms.
For example, some people -- though not in this thread, thankfully -- make much about Haskell's allegedly weird syntax and/or operators. Never mind that its syntax is not particularly large, but also there's nothing immediately intuitive about a lot of C code in comparison. What's with all those "{}" and ";" and "*" and "&"? Parsing operators, especially with parens and pointer dereferencing involved, can be difficult, even without deep nesting, and even experienced coders occasionally trip over some production C code. Yet no-one uses this as an argument for C being "too difficult" or "too unintuitive". I argue this is because C was a language they learned long ago, and it has colored their perception of what is familiar or "easy" about programming languages.
Here's a thing about mathy languages too ... I've done a bit of lisp so I'd like to think I kind of get it ... but aren't computers by their very nature "imperative"? i.e. such that C or Pascal perhaps map more naturally to the underlying system? Can these mathy languages (oriented around our rationalist perspective of the world) truly ever be sympathetic to the hardware?
What I mean is, nice as these are ... is there always going to be a bit of waste when you use them?
Depends on how you define "great". Haskell intentionally keeps itself off the mainstream. That has always been a deliberate choice. There are now already plenty of more practical functional languages, e.g. OCaml, F#, Julia, Elixir, Clojure, which are in part driven by the advancement in research brought about by Haskell, so it has been fulfilling its duty in that way.
I love functional programming, but nobody use Haskell. Clojure, yeah.
Guy next to me at work was trying to build a web app with haskell for a hackathon, and I was blown away by how little the community had to offer for basic things he couldn't get working.
So yeah, languages people complain about, and ones nobody uses.
Haskell was the first thing that came to mind. I can show with one hand, by joining my pointer-finger and thumb, the number of people I know that use it.
It looks lovely, and it's something I'd very much like to learn some day but I can't for the life of me think of what I would use it for. Are there any killer apps out there for it?
My two cents is that I currently find Elixir and Julia to combine productivity and all the goodness from functional programming really well. Not sure what sort of backlash they'll get if they go more mainstream in the future (which I believe they will). I don't think it's totally hype since I also tried my hands on Rust a lot but I really struggled and eventually disliked it a lot. I couldn't seem to implement any complex structure without resorting to unsafe code. Maybe I'm just a shit low-level programmer in terms of thinking about ownership though.
Complex data structures often need unsafe; writing them isn’t a good way to learn Rust. Most already have implementations you can just use, so it’s not something most rust programmers do often.
My response to this is usually that Ruby is a great language because it's easy to get useful work done with a large, meaningful subset of the language. You can ignore the warts just by not using them. You can't do that in JS, because the warts are so fundamental. (yes, you can be tripped up by library authors in Ruby, but there's community backpressure against providing footguns).
I don't agree. The ruby community had a recent love affair with dsl. Taking a peak at rspec library source made my eyes bleed. There's also a huge preference for "magic" even outside of rails, so much that when you want to augment or add functionality you're supposed to monkey patch. There's also a huge preference for "clean" syntax when it doesn't necessarily improve maintainability--it just makes the number of odd syntax rules you have to learn and internalize more convoluted. Also I feel as though the reason there's so much preference for tests and strict rubocop is exactly because there are too many footguns baked into the language.
That's not to say other dynamically typed languages (including js) or even statically typed languages are all that much better. But I would say ruby is really showing its age with the number of warts and hacks that have accumulated.
FYI, there is a significant contingent of the Ruby community that doesn’t use rspec (for exactly the reasons you mention). Heck, the test suites for Rails and Ruby itself use minitest, not rspec. It’s hard to notice this, though, because the rspec people have a vastly larger written output.
It sounds like most of your criticisms are criticisms of dynamic languages. Ruby gives you a million and one footguns, but they are beautiful and elegant footguns.
The difference between the hostility to php and the hostility to js is that there are many alternatives to php whereas, right now, if you want code to execute in the browser or on many different platforms, you don't have a choice. So where I would normally tell people who boo php to use whatever language they prefer, and get over it, that's not possible with js.
While technically true, don't you still have to debug and diagnose issues from the generated JavaScript? I'd love to write front-end code in anything else, but if I have to know exactly how it gets converted to JavaScript it kind of defeats the point.
Elm stands out in this regard, as it gives fairly robust guarantees of no runtime errors, so the debugging you'll do when working with Elm will almost always be limited to its compiler or Elm Debugger. The price to pay for this is limited interoperability with JS, but it may be acceptable to trade interop for type safety, depending on the use case.
Generally, the alt-js languages provide 'source maps' so that developer tools know to map errors in the 'transpiled' code to their source, and it's possible to avoid JS to a practical degree.
Compile-to-JS exists, and there are good ones out there. E.g. you can develop in Dart for web, server and mobile, and it is a solid alternative in every segment (the language and tooling is anyway).
No alternatives to JS browser runtimes & environments maybe but you can use one of many transpile-to-JS languages and you shield yourself from most of JS badness.
Not sure many people would think that "Ruby is the only language", and not sure what's your point there. From my impression, if somebody can decently do backend work with Ruby, then they're probably a better programmer than some JS-only newcomer. Is Ruby already becoming the new PHP? Don't think it's time yet, and Ruby despite its many drawbacks is still generally much better. Not to mention Node seems to be all the rage in recent years and Ruby isn't even that "popular" anymore. Though indeed I personally always had doubts about Ruby. I haven't touched Ruby ever since I started programming projects in Elixir, which I like much more.
The threadless/nonblocking model is "interesting" but in my opinion its wholly suitable for user-oriented scripting as it forces a style of development that doesn't block.
The null/undefined thing actually makes sense to me. The concept of "Null" is a swirling vortex of uncertainty in most languages and it's nice to see it get some more nuanced treatment.
There's something about the bloody-minded pragmatism of javascript that appeals too ... it's very much a language that has evolved from the bottom up based on need, and much of it is very much community driven. You see problems solved in interesting and unusual ways that you mightn't see in a more stringently stewarded language.
I wouldn't use it for everything. I wouldn't prescribe it for beginners to programming either. But it's great for what it does. I like lots of other languages too, but I respect their applicable limitations. It's a nice language.