JavaScript is Good, Actually
ashfurrow.com
ashfurrow.com
Other problems exist, which are just stupid (null/undefined, in/of, ===, ;, this, etc) or minor design choices like coersion and lexical rules. But these above are stoppers for turning JS into something great. It is now a BASIC-level language with scoping and sugar. Yeah, you can write like that snippet presented in an article, but you are forever stuck with doing all things by hand, from asyncing to orm, from exporting to update scheduling. I don’t find that great in any way, especially when that is the only semantics you have in a browser.
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.
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.
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
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.
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".
What I mean is, nice as these are ... is there always going to be a bit of waste when you use them?
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.
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.)
Where did I say it "can't" be better?
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? :)
Yes, because that property is totally absent from Haskell.
https://github.com/RNCryptor/rncryptor-hs/issues/2#issuecomm...
Oops. Surely the JS and Python implementations are just as bad?
https://github.com/RNCryptor/RNCryptor-python/blob/649ca23a5...
https://github.com/RNCryptor/rncryptor-js/blob/08250e00a1140...
(END SARCASM)
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.
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.
I'm arguing that "Python is easier" is false, simple as that.
- 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.
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 ...
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.
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...
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.
I don't recall ever having trouble with that myself, but that's anecdote, not data...
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.
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?
At least with lisp, I can configure emacs ...
You could start your own project. You could contribute to an existing project. You could evangelize Haskell at your job, if possible.
All of these are hard, of course. It'll be easier to use a more mainstream language. But if Haskell strikes your fancy, maybe it's worth the effort?
Yep. Sure. Just as soon as I get done shaving this Yak ;-)
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.
Hugs> last [0,1/3..2] > 2
False
Prelude> last [0,1/3..2] > 2
True
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.
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.
Maybe 5 years ago. For nowadays, I beg to differ: https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
A significant amount of the choices there produce generally better-performing code than the hand-written JS, there's also the WebAssembly.
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.
./file.src:
func api_foo()
for x in objs
x.a = fetch(x.b)
ui.btnok.enabled = yes
commit()
I also find that python has reserved a whole bunch of keywords that I can't use as function names, making APIs hard to create with appropriate names. You also have to pollute your code with self everywhere.
It is also really slow, has no where near the number of libraries on github as javascript, is not a client-side language, doesn't have anything like babel, which can allow you to do a lot more than reflection/introspection (but not the same things exactly), etc.
Also, I think scoping rules in Python are terrible. I always end up with a namespace that is a mess. And you can't do something like this in a clean way:
counter = 0
def add(n):
counter += n
add(1)
add(2)
add(3)What's messy about it?
>>> (lambda f: lambda x: f(x) * 2)(lambda x: x + 1)(100)
202clos = 42
def foo(x): return x + clos
def bar(y): return y * clos
higher_order(foo, bar)
What's so hard about that?
You could do this with a lambda construct in Python; but this only works if the function has a single expression-statement; it doesn't work e.g. when you have a bunch of assignments inside the function you are inlining.
Sure, it's ugly but I think it's a silly challenge. Complex functions defined in the function call are un-maintainable anyway IMO.
That's what nonlocal is for: https://docs.python.org/3/reference/simple_stmts.html#the-no... Just stick "nonlocal counter" in your function and it works.
Also nonlocal implies that other variables are local, which is not true. E.g., the following works without "nonlocal" keyword:
counter = [0]
def add(n):
counter[0] += n
add(1)
add(2)
Your example works because you are mutating an existing object, not reassigning a new one.
It's a disingenuous comparison IMO.
1) In scientific/ML CPython libraries, most critical parts are compiled anyway, and the core language is fast and expressive enough to provide a nice and fast interface to it; so your statement makes little sense without more context
2) Python != CPython
Python is really neat to quickly experiment platform independent but it's definitely extremely slow.
The difference between 'npm install' (and even an added 'gulp') and the chickens I've had to sacrifice at crossroads to get Python packages working is notable.
Oblig XKCD - https://imgs.xkcd.com/comics/python_environment.png
It's kind of ironic, really. With the Zen of Python stating "There should be one-- and preferably only one --obvious way to do it" why is it that it's so common for people to not do the thing that makes it reasonably portable?
I mean, I currently am working with some code that, as part of its readme, has a pip install of a lib -off of master-, and yes, obviously that caused problems. Is the author not a Python developer? Well, he's a researcher. Why is the obvious thing for someone coming naively to develop in the language not building a portable environment?
I think this is why the situation is bad in Python: we have too many non-programmers in the community, that simply want something to work and get on with theirs life. If they can get by it by installing a bunch of libraries by running some command incantations as root, they're happy enough.
You don't have this problem with Node because the only niche that Node really matters is Web, and WEB DEVELOPERS know that their environment should be reproducible.
*: Even in Node this isn't really true, since we have yarn vs npm. Ruby is way more stable thanks to bundler.
The impact of those people in the ecosystem is zero, though. They don't inconvenience anyone by producing badly-written libraries, they literally do their job, produce what they want to produce and everyone is happy. I'm not sure why they get lumped in with "this problem".
I don't know why I hear this a lot, it certainly doesn't echo my experience. I've rarely had dependency problems, even the regular requirements.txt (without pinning to specific versions) tends to work well enough on reasonably current code. Pipenv pretty much solves the problem by introducing a lockfile.
It doesn't impact the ecosystem very much for sure, however I wouldn't say that the impact is zero.
Yes, you need to get the right version of Node, just like you need the right version of Python. I've had both largely just work with directions of "Version Y.X", where Y is defined. I've also had the occasion where it still broke with a specific version where both Y and X were defined.
In general, if I have the right version of Node (and I agree, I'd prefer package.json to also indicate the version of Node that was used to initialize it), things work when installing from package.json. Things also generally just work with Python if I have the right major version of Python, and an environment file. My issue is more that the 'simple' steps a lot of people do when creating Python projects -don't- use an environment. They just use whatever is installed globally on their computer, and they pip install any dependencies, then write a readme to pip install things with, rather than lock it down with a virtual environment.
Python is one of the imperative languages with fewer number keywords in existence. Compare for example the number of keywords in Python[1] with Javascript[2].
Maybe you're confusing the built-in functions in Python language, like len() or str(), however since they're functions you can reassign them (not a good idea, however in a limited scope it works).
[1]: https://en.wikipedia.org/wiki/Python_syntax_and_semantics#Ke... [2]: https://www.w3schools.com/js/js_reserved.asp
> It has so little syntax you can't tell the difference between various things. A variable declaration, a reassignment, a keyword, a whatever else, they don't have any visual distinction from each other.
The fact that you don't know the difference between keywords and built-in functions makes your argument weak. But I will bite, if you're having difficult to make the distinction between a keyword and a variable you probably have a very bad editor. Syntax highlighting helps a lot here (like in almost every other language).
> You also have to pollute your code with self everywhere.
I really like the fact that self is explicit in Python. It makes OO patterns more explicit (there is no magic variable like self or this, just a parameter that is passed as the first argument in any Class method) and it helps making a distinction between attributes and local variables. Really, I would go even further and make super() a method from Object, so instead of calling a magic method super() I would call:
class Test:
def __init__(self):
self.super().__init__(self)
> has no where near the number of libraries on github as javascript
Most JavaScript libraries in GitHub are pure toys/garbage, though. Python has a number of useful libraries and if you don't concur with me, please give examples of areas where Python is lacking a good library (I can easily give an example for JavaScript: ML and scientifc computing).
I'd hate to see Python become as popular as JavaScript and to have it be used as the defacto standard in browsers because honestly, it's nowhere near as enjoyable to use as JS.
It feels to me like JS is more for people who want to write "clever" code and Python is for people who want to write boring, more maintainable code. It doesn't help that JS has a gentler learning curve and attracts more people who just want to get things done without thinking whether those things should be done that way.
IMO JavaScript is for people who want to get things done quickly and efficiently and have their program work everywhere. Python is for people who like to think they are doing things “the right way” as if there were such a thing.
Indeed I can't. I can say no to "JS is more enjoyable than Python", which is what you said in your upstream comment.
> JavaScript is for people who want to get things done quickly and efficiently and have their program work everywhere
If by "everywhere" you mean "in a browser", sure. I don't see how that's related to the common definition of "everywhere", though.
> Python is for people who like to think they are doing things “the right way” as if there were such a thing.
I don't know what you mean by that.
As a concrete example, here's a library I made that relies on symbols and dynamic inheritance to extend the built-in data types: https://github.com/slikts/symbol-land
./file.js:
function foo(ctx) { // @export
for (let x of ctx.objs.iterate()) {
x.a = await fetch(ctx, x.b);
}
ctx.ui.btnok.enabled = true;
ctx.commit();
}
autoexport(module, x => eval(x));
(Thank you and all commenters here for sharing your code and experience. In particular, symbol-land looks very interesting and haskell-y.)
Destructuring would make your example look better: foo({ui, commit, objs}), and then there's no need for typing out ctx. Another thing that's not needed with for-of loops is .iterate().
Using eval() is a very strong anti-pattern, and it's not needed there anyway. JS has the `with` statement that allows running code with a specific context, but its use is discouraged as it's really bad for readability and hard to optimize.
Destructuring looks good here, you’re right. Actually, this thread somewhat relaxed my js hostility and I see it as an alternative that has reasonable tradeoffs (but still not as a friend though).
The Function constructor is a better alternative for eval(), but still only as a last resort. eval() itself has no use cases.
I find that most JS criticism is ill-informed, because people are too quick to jump to blaming the language due to its reputation. Not that I'd call JS a great language, but it has redeeming aspects.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
>almost every example of an issue that you have with the language seems to be resolvable using Proxy objects. I don’t think that light threading, introspection, scoping, etc is resolvable with proxy objects. If it is, it would be nice to know how.
Here the code of the model implementation: https://github.com/zandaqo/compago/blob/master/src/model.js
As an aside, there exist green threads in JS, namely node-fibers, although it's only a Node.js extension.
You actually can reflect on module exports and dynamically change them with node modules; you can't do it with ES modules, but that has the significant advantage of enabling static analysis.
Proxies absolutely can trap the property assignments you mentioned, but Vue can't take advantage of this because Proxy can't be polyfilled in older browsers.
As for the enumerate handler, it would only have worked with for-in loops, which are a legacy feature. The iteration protocols used by for-of are a much more flexible solution. It might seem silly to have both for-in and for-of loops, but the context of the language is that it can't just go and break older websites. Same goes for == and ===, etc. Linters come in very handy for dealing with this.
Your criticism is better than most, which usually just point out some "wat" moments with mis-features like implicit coercion, but you didn't really make a case for having to do "all things by hand" in JS.
And yet even that advantage got thrown out from the language with the introduction of "import()". Apparently static analysis is a non-goal (see discussion in [1]).
[1]: https://github.com/tc39/proposal-dynamic-import/issues/35
Aren't Web Workers real threads, and supported natively in browsers? (Haven't used them myself, maybe there's some limitation that excludes them from the criteria above...)
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
I also bet that I couldn't make 'in' work for proxy with empty abstract target, but maybe it's just me. Btw, 'in' and 'of' are two separate iterators, one iterates array elems and the other iterates object's keys -- something essential to metaprogramming. My whole point on in/enumerate is that it considered legacy by someone special.
And on Vue: I didn't know that, but if Vue can't take advantage of Proxy, can I?
for-in is a legacy feature; due to dynamic inheritance, it's generally not safe to use without also calling Object#hasOwnProperty() every iteration. for-of is not for "array elems", it uses the iteration protocols that are implemented for all built-in collection types, not just Array, and some DOM types, and can be implemented for any user types. Protocols are a much more flexible and clean approach to metaprogramming than overloading the for-in looping construct would be.
You can't use Proxy if you need to target legacy browsers like IE9, and Vue needs to, since it's about 15% of all browsers.
V8 (and probably others) now has some special cases for async functions (and generators, I think, but those are much more rare) to show useful stack traces with the lineage of async calls. For example, this code shows the stack trace you'd expect when run in latest Chrome or Node.js.
async function c() { throw new Error('Some error'); }
async function b() { await c(); }
async function a() { await b(); }
a();Saying that the community is more advanced in the JavaScript ecosystem than it is in the iOS world is a nonsense to me. Don't we have more JS developers than iOS developers ?
Moreover, saying that JS syntax is really good with tools like TypeScript is another nonsense. You can also write Swift code and use another transpiler to get JavaScript code from it and you would say that JS is great.
Last but not least, giving a state of the art of JS without event talking about tools like npm, babel or webpack is like scratching only the surface of the subject. I mean come on, JS is not only about == and === in 2018
Probably not what they meant though :)
FWIW, I don't really approve of the self-description of "world class software developer", either because (i) I'm not really sure what it means, but (ii) it sounds a bit pretentious. Still, it doesn't really relate to the quality or validity (or otherwise) of the post.
Leica manufacture cameras made of brass and, like apple, are more "experience-oriented". I can appreciate putting a picture of yourself on your blog, but taking a photograph of yourself holding a camera which obscures everything but a brand name... that's equally suggestive of "a bit pretentious".
Without spending more time or having some domain knowledge of his problem, I can't really comment on the architecture setup/choices.
I’d work with Ash any day of the week.
s/good/busy/I haven't read the article yet, but what you're saying is something completely different, in my opinion. If you write Swift you're writing a completely different language, with all the hassles usually introduced when transpiling. TypeScript, however, is just Javascript with some of the assumptions made explicit and a transpiler that actually checks whether you're violating those assumptions. In that sense, it's not much different from a linter - another tool that makes Javascript more pleasant to write.
Reducing all that to "but it has to be transpiled to Javascript" is a simplification that doesn't help in highlighting potential concerns associated with transpilation, in my opinion.
and I just thought, hmm, here's this guy with ~5 years of ~professional dev(mainly with iOS) and he self qualifies himself as world class.
Looking at his bio, I see he's worked for 3 companies doing quite ordinary things.
I would love to know what gave him the confidence/ignorance to describe himself as such.
I personally blame Jeff Atwood who pretty much green lit a lot of developers to consider themselves "elite" just because they were reading a blog about programming.
That attitude is something I'd love to see stamped out.
Do you frequently launch into personal attacks on authors whose articles you disagree with?
It's ok to sell oneself but I'd be careful with exaggerations in a field with probably >1 million professionals.
This guy's not writing an opinion piece about which brand ketchup tastes best. He has published an opinion piece in which he speaks authoritatively about matters related to the domain he claims he's a world expert in.
As for the harmless exaggeration, it's not harmless. It's poison to my chosen profession.
That you are good enough that people would accept your work in the United States?
Coding is less explicitly competitive, but there is an element of competition to it. If you were a major contributor to a project that had displaced multiple international competitors, that'd clearly be world class. For example, Linus is a "world-class" coder because Linux is used all over the world and has displaced many operating systems.
Now you seem to be the one exaggerating there. While yes I agree that is a crappy way of describing himself, there is no reason to start being so mean about it.
If the author is joking about being world class, that would be kind of odd. So is saying you're world class at something in general (unless you're the tiger woods of that something and can demonstrate/back it up).
I have found it is commonly a trend with frontend/javascript/rails devs to be senior/lead/etc after a few years of experience. I think there's a variety of reasons for this, but going back to the author he probably is very adept at his given field. But to brand yourself as world class seems a bit much.
Personal attack? Nope. But if I saw that line before interviewing a candidate - I'd definitely probe them about it
Ash is a pretty well known developer in the iOS world. He contributes to a lot of well used open source projects and what Artsy is doing (open source by default) isn't something I would describe as "quite ordinary" even if what they're working on is.
I don't know if those credentials are enough to be described as world class, but I would bet it's a bit tongue in cheek anyway.
I care less about the performance benefits of web assembly than the fact that it will open browser/cross platform scripting to other languages and I’d be curious to find out if we are still talking about JavaScript in 10 years.
I personally find all programming languages limiting in one or another way and I use almost daily C#, Python and JS (sometimes I use other programming languages as well).
Funny you should mention it. Excel will now support JS scripting.
bash is good, for chaining small utilities together.
python is good, for single-threaded problems which don't hurt performance
go is good, if you don't want to manage memory and need easy concurrency, strong typing/etc
rust is good if you want to prevent having a footgun and low level access.
C++ is good for giving you complete control over hardware.
R is good for data science (although is being supplanted, many say, by python).
Javascript doesn't have to be the "best" if it's not competing at all things, unfortunately, as Jobs famously said: "The future is web applications" and now javascript (which, if we remember is from a spec written by 5 guys in 2 weeks) has to fit all use-cases... it's a tall order for any language.
VBA, on the other hand, hasn't really changed at all over the past decades. It's still as annoying as it can be with no help from the IDE. That's helpful as scripts from Office XP usually run with only minor edits but it also means that flaws annoying a decade ago are now much more severe. Luckily, we'll get JS on Office, although it'll probably take another decade until a reasonable share of companies have upgraded to a version that supports it.
I don't really judge a language based on the number of design flaws. That is like judging a computer based only on its specs.
>and most of its users never really got a chance to solve the same problems with a better language.
I don't really think there is such a thing as "better languages". Also your statement is probably true, and was said about php as well. It is only true though because it has the most number of people using it, so will have the highest percentage of casual programmers. As with php though, you also have very good programmers using it.
I am not really sure what the point of characterising the users is other than to subtitute for a lack of any arguments related to the language. But of course, the arguments on these topics are just a bunch of copy and paste from "list of reasons javascript sucks" articles. These just list design flaws like === and so on.
"My PC is better because it has 2GB more ram than the mac". etc....
>web assembly
Web Assembly is not supposed to remove javascript, it is supposed to be used in addition to it when you need high performance. If people try to promote it as a way to not have to use javascript, it will just result in a more fragmented client-side programming situation, where libraries are not available for particular languages, etc.
I guess you have been missing the news what is being done in Go, Java, .NET, Rust, Unity and everyone else regarding WebAssembly.
We will have the revenge of plugins, like it or not.
The only way out is if the browser vendors backtrack and remove WebAssembly support.
There are lots of developers that stayed as backend engineers as they couldnt stand javascript (as a language and its integration with DOM), they stepped over the beginner phase with their development skills while javascript forced them to write BASIC (LOGO) level code. On the top of it, there were always some junior engineers that barely started to develop and were playing smart and bragging how cool the javascript is. There is a lot of rage stored in those circles and there are lots of excelent developers (I can tell you that 90% of top developers (not 25 years old kids, people that are able to write runtime compilers and OSes if given enought time) I know never wanted to work in javascript). Different reasons but I can tell you that most of them would say "I dont like java, but javascript is humiliating".
Now the webasm is comming, I am preparing to bet that the frameworks will start to pop out in year or something after DOM is supported and they will overrun javascript in shortest possible time, just to prove the point - it sucks big time. QT is beeing prepared, all the "real" languages are starting to prepare to support compiling into webasm... the traditionally backend languages (that... you wouldnt believe... backend engineers know very well) are now having a chance to shine in browser that was restricted for them due to javascript monopoly.
I wouldnt take the javascript future as really bright, in best case it will be used in same way as today shell scripts are (this is what they meant that webassembly is not replacement for javascript). To glue some parts of "system" (read as: browser) together.
And quite frankly, this is step that should be done 10 years back. It would save world a lot of trouble.
And have fun: https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGard...
Even once support exists, there's a payload issue. Nobody wants to spend loads of bandwidth downloading runtimes.
But the web is only one aspect. Web apps are likely going to take over a huge part of client development.
In both cases, the GC issue is non-trivial. LLVM has finally started to make performant GCs possible. Wasm (to my knowledge) doesn't have similar capabilities and guarantees (I suspect the are actually impossible with untrusted GC code). The only viable solution IMO is the addition of GC primitives and hope that your particular language maps well on that specific browser's GC.
It is certainly possible to package a runtime way smaller that the analytics crap most people have to endure.
Unity WebAssembly games are just a few hundred KB.
Who cares about DOM, WebGL takes care of the UI part.
If that goes up to 10-15mb (which can't be split), you're now going to have major usability issues. That's before all that analytic stuff that isn't going away. People do notice the difference and will just leave.
Unity complex with basically zero runtime and uses webgl so it doesn't need to include that either (just the actual game itself).
People use the Dom because it's standard, doesn't have to be downloaded every time, and offers tons of features.
Nobody is going to write directly to webgl for a standard website (That's easily 9,999 out of 10,000 sites). That means you have to do something like drag Qt or GTK everywhere which takes even more time to download and parse.
Your idea seems to be: download and parse a bloated runtime, download and parse a huge display library set, download and parse the misc shim pieces, and then download and parse your app. This is all done with the hope that your crud app that spends most of it's time doing nothing will be a fraction faster and you can write it in something that isn't JS.
Not a great plan.
Not all languages are like Python, a language that I only use for shell scripts anyway.
Blazor, Qt, Unity are all getting there.
Adobe can even bring Flash back.
Adobe won't be bringing flash back. It was basically just ES4. ESnext and HTML5 have almost all the good stuff plus quite a bit more while having far better performance than flash could achieve.
https://blogs.msdn.microsoft.com/webdev/2018/05/02/blazor-0-...
Anyway, if you remeber flash, there was one runtime for all flash apps and once you had it, this was it (until next security update :D), and with todays CDNs, it will be no different than, for example, angular. Downloaded once, cached forever.
Wasm (like asm.js before it) is target at unmanaged languages. A C++ codebase likely does very well with good performance. That was not what I was talking about. Convincing a game company to write their games in C++ is trivial. Convincing that same game company to write their normal CRUD website in C++ would be incredibly difficult.
Looking at apps, there's still issues. Consider Qt. While it's very possible to write everything in C++, loads of companies jumped straight onto the QML/JS bandwagon because its (generally speaking) much faster to write safe code in JS (also, running the v8 version that Qt requires would be terribly slow compared to the native engine). UI development is hard no matter what and C++ doesn't do it any favors. JS features like closures and dynamic objects make many things easier than static classes functions.
This means we need to look away from C++ to something that is managed and has faster code turnaround times. The best possible languages for this are (IMO) Scheme (or maybe Common Lisp) and SML (or maybe Ocaml or F#). You could also make arguments for something in the vein of Dart or Kotlin.
How do you bring these languages to wasm? If you use a JIT, you run into a rather large payload (4-10mb of code is going to have obvious impacts). In some cases like Ocaml where a native compiler to wasm is in the works, you still have a GC issue (basically, you can make an advanced GC that is slow or a basic GC that is "fast", but with other issues).
The addition of DOM API will solve the GUI issues (and maybe they'll rework them to be more like dart's API). Adding hooks into the builtin GC would reduce payload size down to something closer to unmanaged languages. 10 years after those are added (when outdated browsers can finally be ignored), wasm will finally be ready to replace JS.
Adding those features doesn't seem to be highest priority. Unfortunately, you and I will probably be nearing retirement age before they are generally usable.
As a point of interest, JS code could be getting much smaller and much faster to parse (plus becoming a better compilation target) with the JS binary AST proposal.
I have heard this runtime considerations before but they are taking into account that someone will run webassembly compiled JRE in browser (and I am sure that right now, there are some freaks trying to achieve that). But there is still good old C++ (or Rust) not as productive as scripting languages but this is just due to much less open source "technological stack" (or some might argue, tribute to low quality of software today, "technological garbage") rather of not beeing capable of beeing competitive.
I think that the coolest trick that web based technologies pulled out was to convince the world, that the whole GUI needs to be primitive, simplistic, as they were unable to create something that desktop applications were doing for decade (speed/size considerations) and it might just happen that we will return back to owner drawn controls, where you wont be able to make distinction if app is running locally or in browser (no, I don't mean Electron, pun intended). There js will be unable to compete.
Anyway, push for webassembly is not here as corporations want to do something good. They want to push all computer users into old mainframe scenario, where you would have to rent space and cpu in a cloud and have just dumb terminal and javascript has hit its limits to replace desktop environment as it is, even with Windows Metro look (another simplification of GUI, done for mainframe scenario, Windows 365 are not far away)
Javascript was usefull in era of simplistic web pages as a small hack into html, but for next step we need something more and here there are other languages that can offer much more but are now limited to running in backend as they don't have browser support. But this will change with webassembly.
https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...
The biggest reason for JavaScripts greatness to me is JSON. I couldn't understand how Java developers put up with such bulky ways to deal with data. After some time in Java land I've come back to appreciating its strengths again though. Code completion is nice. I'm kind of hoping for more typescript in the future.
Is there any serialisation standard that specifically addresses this? I know YAML and TOML doesn't at least (correct me if I"m wrong)
No more trying to have short names to keep file size down.
https://blog.octo.com/en/protocol-buffers-benchmark-and-mobi...
The primary purpose of binary data formats is that they can be parsed quickly and some even allow direct access without a parsing step.
First class treatment would be if the language had JSON-typed objects with functionality, e.g. something like
const myJson = j'{"key":"value"}';
const value = myJson['key'];
const newJson = myJson.set("otherkey", "newValue");
But AFAIK it doesn't, not even in ES6.
Implementing j`{"key":"value"}`; as a tagged template literal is left as an exercise for the reader.
I miss the "and a project which doesn't use modern standards"-part in your post. It's not as if JSON or other modern things are not used in many Java projects. Your project seems to be stuck in the past, as are many JS projects. Legacy code is no fun most of the time.
Whereas javascript you can just go `require(myjsonfile)`
I love java, but Javascript is indeed great for some of these kinds of things :-)
I'm not current on Node features, but that looks dangerous to do. Is that equivalent to reading the file and `eval()`ing it?
No:
> const fs = require('fs')
undefined
> fs.writeFileSync('file.js', 'console.log("yes")'); require('./file')
yes
{}
> fs.writeFileSync('file.json', 'console.log("no")'); require('./file.json')
SyntaxError: file.json: Unexpected token c in JSON at position 0You can have a one-liner class like
class Person(val name: String, val email: String, val yearOfBirth: Int? = null)
When I suggest switching to Kotlin everyone's always smiling dismissively like "ah, you with your crazy ideas again".
Might do it though. Maybe.
To me, it's much better to let every company send error messages in the format that makes sense to them rather than having the One True Error that doesn't quite work for anyone.
My biggest complaints about JSON are syntactic. Optional comments, multi-line strings, and trailing commas would do wonders for day-to-day readability without significantly bloating the specs.
With respect to your "lack is strength" argument, I can't help but find this unconvincing. We all know JSON is derived from JavaScript object/array literal syntax; your argument is akin to retro-fitting the requirements for service payload serialization to the suboptimal de-facto situation with JSON.
JSON5 is something that should've been.
If you take a language like Java and an IDE like Eclipse or Intellij IDEA, it is trivial to find from where a particular piece of code is called from. Whereas in JavaScript, particularly in huge codebases, you can't easily tell how a piece of code ends up getting called. You will need to run the code, make some educated guesses and put breakpoints or console.log statements to verify that yes, this particular line does end up getting called on this particular action.
Refactoring is also a joy in a language like Java. You can easily modify a method signature and the IDE will take care of updating all the places this method is called from. Now imagine you add a new argument to your JavaScript function and want to update all the places where the function is called from.
So judging JavaScript on these factors, it isn't such a good language.
Lambdas, First class functions, and closures are a great feature missing in basically every other popular language (things like Javas lambdas or function pointers aren't even close in real world use).
Proper tail calls is another feature missing from that list and despite some browsers refusing to honor the spec they ratified, it's still implemented in Safari/javascriptCore, XS6, duktape, node 6-7, etc.
The interplay between js dynamic objects and closures is difficult to describe, but a thing of beauty when fully understood. Object literals are also basically unique to js on that list as well.
There's a lot to love about most languages and JS is no exception.
For disadvantages, how serious are they, how easy are they to be abused, to creep into the codebase, to be prevented from happening again, etc.
It also depends on the team. If it is a small team of 5 people and they are all excellent engineers, I think whatever languages are fine. The 5 engineers will discuss and decide what features to NOT use, etc. and abide to them. If it is a team of 500 engineers, it will take much more efforts and eductions and much longer to achieve that.
None of the languages are new.
Then play musical chairs and have each team develop a new feature in one of the other teams' project/language. Measure how long that takes.
As a matter of fact, you can even use IntelliJ for checking function usages and refactoring in JavaScript.
Yes, modern IDE do wonderful thing to help you with JS but they will never be able to match the help they can give with a language that is statically typed.
That being said, TypeScript is not sound and obviously in a real TypeScript program you'll eventually touch things that are untyped. But still, getting a different set of trade-offs than "statically typed" and "dynamically typed" is useful. It makes me wish there was something like this for Python (no, MyPy and Pyre are not this. They only provide nominal typing, which is definitely not good enough for everyday Python like Django.)
Obviously it's far from pure FP, but I think it's much more at the heart of JS than it is say Python. The Scheme parts of JS are the good parts.
I think some of the resurgence of FP is down to JS. The wealth of libraries available is pretty impressive [0]
One day I got curious about monads and spent over a month trying to wrap my head around it, which obviously set me on the path to Haskell which is now my favorite thing in the world.
Javascript is a great language because it allows you to develop incredibly fast (scripting language) for a platform that runs everywhere (the web).
It used to be far simpler, but IMHO, insecurity because of all of the FUD that this sort of article prescribes, has meant that the language has bloated to incorporate all sorts of syntax improvements and new patterns.
It's not a systems programming language, so all the comparisons against typed, compiled languages are moot. Introducing transpiling as a mandatory pattern for JS development was a mistake.
The reason JS has won is because the web has won. Arguing about its merits misses the point.
No they are not 'moot'. At least not if you're building applications with 100k+ LOC. For dinky websites and small projects I'm with you.
>Introducing transpiling as a mandatory pattern for JS development was a mistake.
Again, what are you building? A dinky website, or a large application that you'll have to maintain for the next 10 years?
If you want to build a web application, at some point, until we have true web assembly, you will have to use javascript, which does make a lot of the arguments here moot, regardless of the size of the project.
You answered your own objection. The language is deficient so alternatives are sought (lack of standard modules is one problem). Nobody likes transpilation and nobody would do it if JavaScript was conducive to building and maintaining large applications.
>If you want to build a web application, at some point, until we have true web assembly, you will have to use javascript
No. You can build it in TypeScript or Dart or any number of more sane language and transpile to JavaScript. Which is what people are doing.
Exactly, you can't avoid javascript. Transpilation is at best a level of indirection.
I'm not answering my own objections, rather I'm pointing out that transpilation is a necessary evil, but it _was_ a mistake compared to the alternative, namely fixing modules.
You will have to refactor everything and entirely change your toolchain every two years. If you had the misfortune of using some framework, it will no longer be supported by then.
No JS application has that kind of longevity, because the entire ecosystem is extremely volatile.
Also, people making legitimate criticisms about a technology (in this case to try and cut through the hype train a bit) are not 'trolls'.
I can say a lot of good thing about elm, but the most important one, and something that outweight a lot of thing is maintainability. Each time I had to change something in a shipped app it was painless, stressless (I know I won't add regression) and fast.
I won't say JS is bad, but the absence of a compiler makes it much more fragile, especially when working on old code.
JavaScript does has two good typecheckers, TypeScript and Flow.
I'm really surprised that whilst the language on the one hand gives nice tools like the object spread syntax, the last time I checked it didn't make it easy to make the interpreter enforce immutability.
It seems strange to me that the language evolves in this way to recognise foot-guns but doesn't give you the tools to turn them off. Object.freeze looked like it would do the trick, but it's shallow. Freezing doesn't survive the spread syntax, which makes perfect sense because it freezes the original object, and of course the whole point of immutable objects is to create a new object.
It feels like you're able to program in this style, but the language designers didn't really consider it very much and were just introducing the syntax to be consistent with the other spread syntax.
I recommend that you read : https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallac...
I think a fundamental problem with the language is that it's not particularly memory-efficient, and it's hard to make it memory-efficient. The V8 team has done a lot to make it better but they are still limited by the design of the language.
That's particularly painful in mobile where memory is constrained, and on the desktop it's making the typical 4 - 8GB of RAM less and less sufficient. That's important when discussing why Javascript is still an issue when using stuff like Electron and React Native.
Any meaningful definition of good has to draw a line between things that are and things that aren't. The definition here is broad enough to include basically any language that is popular. C++ is also good because it has a good syntax for the things people use C++ for, a big community that builds tools for it, and it has quirks but come on every language has quirks.
"Just because you disagree with the decisions doesn't make the language bad" is a funny way of describing absolute bald-faced mistakes like typeof null == 'object', the baggage of 20 years of browser quirks (JS tristate logic: true, false, and document.all), and "no that was totally intentional minimalism" oversights like the lack of coherent collections and iteration primitives.
When I think about good, I think about Rust's memory model, Erlang/OTP's supervisor trees, Java's standard library, Clojure's immutable data structures, Python's syntax, .NET's LINQ, Haskell's type system, Idris's type system, Go's mascot, or Elm's delightful mix of programming language and solo performance art piece.
Despite the author's attempt to head this criticism off, the reason we use Javascript really is just because it's in the web browsers. Web developers had to use it, so we made the best of it. We wrote libraries and tools to make it bearable, we built new languages on top of it so we didn't have to deal with its bullshit, and once Ballmer quit ruining the internet we built those improvements back into the language itself.
But is that good? Layers upon layers of accreted improvements, each with more legacy carve-outs than the last? "We can never throw away a bad idea" is a one-way complexity ratchet that precludes unqualified goodness unless there were no bad ideas to begin with. With Javascript, that is not the case. The best it will ever achieve is that it has good parts.
If INTERCAL was the de facto language of the web, we'd be writing Medium posts about the benefits of Automatic PLEASE Insertion and how excited we are for ASYNC COME FROM to land in INTERCAL2018. And, hey, it's not perfect, but it gets the job done, there's a good community, and at least it's not Objective Malbolge. Who are we to criticise?
Brilliant.
That made my day and next few mornings, thank you.
For the first and third use case, really not much has changed since ES3/ES5: if you want portable JavaScript and appreciate simple "press reload button" workflows without babel or other complex transpilation steps, then ES6+ features don't add any essential capability, and I tend to avoid them.
If OTOH you really need to develop SPAs with massive code bases and third-party libs, then ES6 and in particular ES7 with async/await is a big win.
But I can't help wondering if the tension between these language profiles is going to work well for JavaScript in the long run. IMHO for full-blown apps there are much better alternative back-end languages available, and in any massive ES6 code base I've come across the desire to introduce types and type metadata is very much noticable (Angular and Typescript come to mind).
He claims on one hand that Javascript is great and then cites the awesome tooling like Typescript. Well, a great language would not need Typescript, now would it?
I think the most obviously damning thing about Javascript is how the rest of the world bends over backwards and speaks JSON now because it's less trouble if we adapt to JS than if we adapt JS.
Well, yeah, if you change the problem to fit your programming language better, then your programming language will feel convenient and like it always fits well. Duh.
That said, I agree with the rest of the points. I do love JSON though.
[0] The Pipeline Operator Stage 1 proposal is currently the closest proposal to making something like that happen: https://github.com/tc39/proposal-pipeline-operator
[1] Stage 1 Proposal: https://github.com/gsathya/proposal-slice-notation/
{Garbage code example} "Syntax is just syntax". "Tool writers are neutral, then get to work fixing this terrible language".
Really?
> You may have noticed that the code above isn’t even JavaScript, it’s TypeScript, which brings me to my next point.
Which kind of invalidates the entire premise of the article.
It has almost no new "features" (apart from enums and namespaces, I think) and only contains a typing + visibility system and related syntax on top.
The only part that is not ES2015 in the given code example is the ' as ConsignmentSetup' cast.
http://node.green/#ES2017-features-async-functions
I had to look it up because i could've sworn async functions were es2015. The lines get blurry when things are implemented out of order.
I agree with the other posters - there are probably good defences of JavaScript that can be written, but writing an article about how great JavaScript is and then showing a code sample from a different language just reinforces the idea that JavaScript developers probably don't have much experience with other kinds of programming.
You could say that about C++ and C, but that's an entire different can of worms.
So why not give the example in JavaScript then? Arguing that JavaScript is "Good, Actually" and then showing examples of tools people have build to avoid using vanilla js because it lacks X or Y is actually an argument for js being "Not Good Enough".
Removing the cast means removing static typing. It might be a small change for this snippet, but at the project level, you'd need considerably more changes, and you'd lose type safety.
Javascript the language is getting much better, and is quite nice in many dimensions. Javascript the ecosystem has a lot of strengths, while also having embarrassingly poor base libraries that require stupid levels of duplicated effort and a platform that is still painfully inconsistent. The fragmentation around Coffescript/Typescript and linters hints at a much stronger need for a language that does more than JS does at its core... As traditional languages encroach into the browser space I see a lot of the "SPA" and cutting edge fat-client-in-html moving away from JS because of those warts.
The point the author is making is that the haters love to point at these quirks and claim that they cause "untold pain"; yet in actual practice I've only been bitten by == maybe twice in 15 years.
This argument applies equally well to using PHP for most anything. Not impressive.
Also I never seen anyone complain about Electron apps because of the language they're written in. The main complaint is that it's a tremendous waste of computer resources. If your chat app needs more than 1gb of RAM, I don't care what language it's written it, it sucks period.
Also JS + Typescript is a force to be reckoned with (the added safety is great), and once a multi-threaded runtime like Chakra[0] takes shape, it'll be even better. JS's early introduction of concurrency primitives (callbacks, futures/deferreds, promises) will make javsacript developers much productive much faster than the equivalent ruby/python 2 developer with not as much early exposure to managing concurrency.
- easy accessibility of higher order functions (AKA functions as a first class object from the get go)
- graceful inclusion/addition of concurrency-handling functionality despite the language being single threaded (this might be much more to do with the context javascript was to be used in)
I agree with your sentiments on the value of type systems and compile-time type checking, but so many languages are in the same boat as JS in this regard -- it even applies to a bunch of lisp dialects (CL does have the `declare` form), and not many could consider lisp a "bad" language.
2. Concurrent execution has also been introduced in the 1960s (Dijkstra 1965), Ada and Erlang supported that behaviour since the 80s.
3. LISP has a type system and basically any LISP runtime will yell at you for comparing strings with numbers just like that. SBCL can do this check at compile time even.
Additionally LISP lets you add a type system on top using macros and other tricks (some going as far as implementing a Haskell-like typesystem in LISP).
My point wasn't that javascript invented higher order functions, it was that making them first class isn't something all languages have chosen to do, and is clearly a good choice.
> 2. Concurrent execution has also been introduced in the 1960s (Dijkstra 1965), Ada and Erlang supported that behaviour since the 80s.
My point was not that concurrent execution was somehow invented by javascript, that would be an asinine claim. My point was that javascript has done surprisingly well to introduce these concepts to it's users (perhaps out of necessity given the runtime environment it's in), whereas concurrent programming is considered an advanced concept in other languages and isn't taught till very late if not at all.
> 3. LISP has a type system and basically any LISP runtime will yell at you for comparing strings with numbers just like that. SBCL can do this check at compile time even.
this depends on the dialect of lisp you're using. SBCL will certainly do basic type checking and even advanced if you make use of `declare`. I'm not sure what I implied that would make you think I am crediting javascript with inventing type systems (?). I know lisp is great -- that's why I mentioned it as a language people highly regard, but is not compile-time typechecked depending on the dialect you're using, but people wouldn't say that makes it a bad lanaguage.
It's like you read my comment and decided that I said javascript was the best language ever invented. My point was that it's made some choices with some good outcomes. Java as a language consciously chose not to have first class functions for the longest time (1.1 to 1.8 IIRC), yet people from Java will continuously bash JS as being the worst language they've ever seen.
Rightfully so.
What positive things can we say about a programming language where this is valid code?
[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!!)
Just a snippet, more fun can be had at http://www.jsfuck.com/
Or the community tradition of writing one liners as npm packages?
Just because it parses doesn't mean anyone would ever write it in a serious project.
Also, I've seen worse in Java (AbstractSingletonProxyFactoryBean), the only difference being that someone wrote the code with good intentions -- not as a joke. "Idiomatic" Java code is often bloated, and people who write it have been trained to defend the bloat until their dying breath.
> Or the community tradition of writing one liners as npm packages?
I'd pick npm over the hellscape that is maven +/- gradle and managing the class path anyday.
I honestly think in about 5~10 years, something like Golang is going to be more common at most forward thinking companies than Java, with or without generics.
For anything else, we have seen the future.
C and Assembly are probably the only languages left where this isn't the case.
And even C has the blocks extension on Apple platforms, although I would take the "easy" part out of it given the lifetime semantics.
I've seen java developers struggle with the concept of futures/promises while for web developers it was covered in Javascript 102 and they've been using them day in and day out for years. This was the benefit i meant.
Also, I wonder if anyone actually uses http://libcello.org/
Before we used anonymous classes for the same effect.
Also plenty of developers on the Java platform are polyglot.
To be fair, good alternatives also haven't really existed for a long time either -- alternative languages on the JVM weren't popular, Golang and Rust didn't exist, C# required changing to a MS shop, ObjC was ObjC... But I'm not going to sit here and forget about a bad decision persisted for 19 years just because they fixed it 4 years ago. In that very specific case, Javascript did the right thing, from the beginning, and deserves to be praised for that individually.
I never worked in a company of "Language X developer", rather developers that would use whatever language suited the project. Including mixing multiple languages on the same project if that would be the best approach.
In those 19 years, JavaScript was mostly used to make graphics jump all around the page and form validation, hardly something worthy of high order functions and currying.
Javascript, the language that was largely tolerated until a book called "JavaScript: The Good Parts" came out, in 2008.
The developers do, yes; with Javascript, they don't have to worry about compiling for multiple platforms like, say, a C developer would, they could even just ssh into a server and edit a single text file while everybody across Windows/Linux/MacOS/iOS/Android/etc can run the new version as soon as you save the file (mod browser compatibility issues, of course). I think their point was that Javascript is the only language that can do end-to-end simplicity like that.
I don't hesitate to say I like JS. These days I try creating any small experimental programs I need in JS and run them in FF instead of starting the whole build process with C++ code. If there is file i/o needed, I use an extention that I have created for this purpose. When necessary, converting this prototype into C++ code is not a big deal.
As for its flaws, well, which language doesn't have flaws. Part of being an experienced dev is to learn, respect and avoid the shortcomings of the technology you use, aka paying attention. Its arguable that some flaws in some systems are worse than some flaws in other systems since the design factor comes into play, but with something as pervasive and monopolistic as JS, there is a clear choice to be made - create something better for the community or shut up and live with it. I am sort of doing both. (To pull off the first one, I need some serious credeitials, which I hopefully earn in the near future.)
Totally agreed. Same coming from Java. It is crazy how much I prefer it over Java. Maybe this is a consequence of coming from verbose languages? The lack of boilerplate is very refreshing!
Tell that to Brainfuck.
Sure, JavaScript is a great language if you ignore all the shitty parts.
Re the Javascript advantages of JSON and quick writing: Python! It too has its flaws, but so many fewer and writing in it is a breeze. Python 3 is only getting better to, so if you do start, take the time to start in 3, not 2.
Javascript is indeed pushing more function programming type stuff, but if you really want that, go with a Lisp/Scheme or Haskell IMO. It's simply what I've been exposed to, but Racket is a great language for quick little programs. You can also go functional in Python easily enough as well.
The problem is, the children did do it, skipped going to school to learn the basics, and now we see clearly reflected in the evolution of the ecosystem their efforts to slowly re-discover and re-invent everything.
Browsers should have just created a Lua dialect, which is like a more sane version of JS, and throw JS back into the nineties-fads hellscape that spawned it. Perhaps in an alternate dimension Eich will have done a non experimental port of Scheme or would just have done WASM from the start. I’m pretty sure at least there every PC would just boot into Netscape by now.
It’s true that the infrastructure around JS has gotten a lot better, but that’s despite the language. If anything I should thank it for popularizing FP which will hopefully eventually slay the chimera that is OOP.
[1] Or, more specifically, “POOP” to emphasise its prototypical nature.
That flux capacitor diagram is super interesting but I think it is missing a point. The bizarre equality happens due to truthy and falsy evaluation, which is a very practical concept that saves you a lot of time when you actually want to get shit done.
The fact it was named "standard" is quite infuriating, as it's just a bunch of random people churning out an arbitrary set of formatting rules. This is not how standards are acquired. Now, many devs unfamiliar with JS use it because they google "javascript standard formatting" and obviously find this.
That's like saying that Java is good, actually, if you use Kotlin. But not really, because the UX of using Kotlin is 100x nicer than using transpilers.
The JavaScript ecosystem is large and this question can be broken down into:
- Is JavaScript good on the browser for the front-end work?
- Is JavaScript good on the server?
Also for those interested, I create a Poll HN: favorite web server language and front-end submission over here:
JavaScript is popular because the learning curve is low and it was good enough for the web. Otherwise it is pretty mediocre even when just compared to scripting languages.
Then, the "about" page of that blog is very concerning: "I am a world-class software developer". A world-class software developer would be people like John Carmack, Linus Torvalds or Dennis Ritchie.
That's a weird criticism. Object-oriented programmers are premised on mutation. As for JavaScript itself, mutations can be avoided. 'const' to prevent reassignment, using Object.freeze, or just applying functional programming principles and keeping functions pure.
2) Mutate the prototype of a "frozen" object and you would indirectly affect it through its prototype chain... or mutate an nested property inside a "frozen" object.
Most of JS standard library and most popular frameworks and libraries have fully mutable definitions. That sucks and is BAD design decision.
This counterargument is not a good one. Just because other languages do things a certain way doesn't mean it's the right way in every situation. C++ has multiple inheritances and template metaprogramming, but that's C++.
> Most of JS standard library and most popular frameworks and libraries have fully mutable definitions. That sucks and is BAD design decision.
It's subjective whether this is a bad design decision. For the standard library, this enables polyfills. As for the popular libraries / frameworks, they have the option of freezing the prototype. They don't do this because they make the fair assumption that the client is not mutating the library state. It's the programmer's fault for breaking the interface contract and mutating the implementation. At any rate, this would be a criticism of the ecosystem, rather than language. If the criticism is about untrusted third party code, it's not an apples-to-apples comparison between JavaScript and other languages that are operating in different environments.
2) Just like you can polyfill your code, malicious input can poison your prototypes.
I'm a Java OOP developer, and I make everything I can immutable. It's a design decision adopted by most of my colleagues.
And aren't frontend dev essentially forced to use javascript since we can't compile to anything else at the current time? yes webasm is coming and yes there are languages that compile to js
He seems to be saying, “Hey, this ting that everyone calls a shit sandwich isn’t really a shit sandwich. Let me tell you why.
I go to this nice restaurant and eat things that are not shit sandwiches. And they are fantastic. But they all end up as shit eventually, so it does t matter. Therefore JavaScript is not a shit sandwich.”
It's not better that the example isn't even JS itself but rather the only JS dialect I don't refuse to work with since it has a type system that is more solid than wet tissue paper.
As the author themself admit, syntax is not important, so why bring it up? That genuinely seems like a way to A) bring up the argument and B) in case anyone refutes the argument being able to simply say "well it didn't matter anyway".
---
Toolchains are another bad point. VSCode doesn't only exist for JS, it has support for other languages as well and I very rarely make use of it as JS IDE.
If I need a third-party toolchain to fix up the most basic mistakes of the language's design I don't think the language under that mess will be terribly good.
Other languages don't require an entire toolchain to provide a minimum of coding safety.
People agree that writing in C is something hard and dangerous, it also needs an entire toolchain to achieve a minimum of "not segfaulting on startup".
I should be able to simply take the first party language tools and use those to get to a point where my application starts and the correctness of my code not being coerced to false.
---
While it is indeed commendable that JS has such a big community, I think the community still has lessons to learn. The churn in the ecosystem is beyond fantastical levels, not in a good way.
When I pull in sqlite3 for my project I can be reasonably sure that this project will be maintained for the next 20 decades and I will be able to use sqlite3 in 20 decades without much problem.
With JS dependencies I will always ask myself subconsciously if they're going to be maintained next week.
I don't write software that runs for next week, software I write is intended to function for the next 20 decades. Of course it'll get patched and maintained but I don't want to switch out my underlying framework because Google decided that their JS code has become too boring after 4 months of work.
The GraphQL examples is just an example of this. The tech is barely 5 years old, the tooling in all languages other than JS was extremely immature last I checked. Why should I bet on something like that to work and be maintained in 20 years?
---
I'm getting a bit rant-y but I'll take this last paragraph to disagree with the conclusion too. Most languages have some bad design. Usually that is fixed in the language or by first party tooling. That's not my problem with JS.
My problem with JS is that the moment I write JS I have to involve myself with the community of JS, a community that has laughed (!) and scoffed (!) at me for suggesting that I want to maintain software for a long time beyond $CURRENT_YEAR.
The ecosystem and community of JS are rotten and flawed, that's why I don't use JS where I possibly can and if I do it's vanilla browser JS pushed through the minimum installation of typescript I can get away with.
We are moving to Go for our backend because dynamic languages don't scale with complexity or team size, but that's another matter.
I'd say that holds for pretty much any language. The blog starts with an example to show how clear and concise etc the syntax is. I, personally, find the syntax unclear, verbose and I have no clue what that code does at a glance.
But I guess that is actually the crux of it: if you enjoy Js and are productive with it, great! Just don't ask me to work on your code, I'd make a mess :)
It was there.