JavaScript brief history and ECMAScript(ES6,ES7,ES8,ES9) features
https://medium.com/@madasamy/javascript-brief-history-and-ec...
JavaScript: The Modern Parts
111–120 of 122 posts
Re: JavaScript: The Modern Parts
#112Earlier quoted context omitted.
> at the peak of Javascript fatigue Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse. You just mentioned webpack is going to be replaced?? That's unfortunately very typical for the JS eco system. 7 years ago we had Grunt, then about two years later Gulp, then about a year later Webpack, now apparently Bazel? Interesting, never heard of it, but I still feel fatigue. I spent quit…
While the JavaScript ecosystem is on the volatile side, learning new tools and frameworks every few years is just part of our job. Only in very boring tech jobs would you only have to learn new things maybe once every 5 years. I wouldn't really bother wasting time "mastering" something like Webpack or what replaces it - as the other commenter said we just end up using an abstraction over it anyway.
The reality of the situation is that JavaScript was designed at a time when there was NO CLUE that it would become the de-facto client-side language for decades.
So now the ECMAScript standard is pushing JavaScript towards a "proper" language, but we need additional tools (TS, Babel, etc) to write in an even more "proper" language/syntax that will give us something that the browser still needs to understand (JavaScript).
This isn't a fun process for those of us who have been developing a long time. Look, JavaScript has classes! And modules! Ok, that's good I guess, we're getting there. But that's not learning, that's just getting closer to something we are already familiar with as software engineers.
Re: JavaScript: The Modern Parts
#113Earlier quoted context omitted.
There's a bizarre, naive belief that all programming is web programming. It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.
Javascript is a frustrating language. On the one hand it's more "serious" than [legacy] C, C++, Java, and Python because it had first-class functions and real lexical closures from day one. On the other, it had imprecise typing, no multiprocessing, and no access to the file system. Some of that has been fixed, but Javascript was designed by one person in a week to script web browsers and that's still painfully obviou…
> On the one hand it's more "serious" than [legacy] C, C++, Java, and Python because it had first-class functions and real lexical closures from day one.
Why do closures make a language "serious"? To me languages are just languages. Seriousness is defined the problem you are solving. Are flight controls serious? Probably. Is yet another small scale CRUD app serious? Probably not.
There is a lot of "serious" code written in every major language. There is a huge amount of "serious" code written in C and C++, and all of this without first class functions or lexical closures.
Re: JavaScript: The Modern Parts
#114Earlier quoted context omitted.
There's a bizarre, naive belief that all programming is web programming. It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.
Javascript is a frustrating language. On the one hand it's more "serious" than [legacy] C, C++, Java, and Python because it had first-class functions and real lexical closures from day one. On the other, it had imprecise typing, no multiprocessing, and no access to the file system. Some of that has been fixed, but Javascript was designed by one person in a week to script web browsers and that's still painfully obviou…
It is such a "serious" language that it has only floating point numbers. I think you will find it is not fit for serious work.
Re: JavaScript: The Modern Parts
#115Earlier quoted context omitted.
Javascript is a frustrating language. On the one hand it's more "serious" than [legacy] C, C++, Java, and Python because it had first-class functions and real lexical closures from day one. On the other, it had imprecise typing, no multiprocessing, and no access to the file system. Some of that has been fixed, but Javascript was designed by one person in a week to script web browsers and that's still painfully obviou…
> On the one hand it's more "serious" than [legacy] C, C++, Java, and Python because it had first-class functions and real lexical closures from day one. Why do closures make a language "serious"? To me languages are just languages. Seriousness is defined the problem you are solving. Are flight controls serious? Probably. Is yet another small scale CRUD app serious? Probably not. There is a lot of "serious" code writ…
Good question. I'll try to give my answer, but others will have their own opinions. Computer languages move in the direction of supporting "good ideas" as those ideas become generally recognized as being good. Usually those ideas start in academia and gradually find their way to industry. Some examples: Structured ("goto-less") programming, object-oriented programming, automatic memory management, strong typing, lexical closures, first-class functions, functional programming, automatic bounds checking, and prevention of memory ownership violations.
A "serious" language is indeed partially defined by its fitness for the stated job at hand, but also for how well it handles the often unstated requirements of productivity, security, maintainability, and robustness in the face of likely future needs. Languages that have more of the above features tend to do better at these unstated requirements.
What is and isn't a "serious" language can change over time depending on what we learn is important. C was a serious language for a while, but it has not been one for a couple of decades because of its non-support of anything remotely resembling security. C is still used because of its extreme portability, but it probably should be abandoned.
Conversely, languages that support first-class functions, lexical closures, and automatic memory management are now in the serious category because those things present huge improvements in productivity, maintainability, and robustness in the face of future changes. (I'll even go out on a longer limb and say that programmers who learn to think in terms of functional composition become more productive coders in any language.) Pure O-O languages are beginning to move in the non-serious direction because they cannot be readily parallelized in an era when parallel computing is the only way forward now that Moore's law is dead.
Javascript anticipated a couple of these features before other mainstream languages, and now it's moving beyond web browsers. So yeah, with some reservations I'd call it serious.
Nowadays I'd never write major code in a language that doesn't directly support most of the "serious" features I listed above; it would be too much of a hit to my productivity. It would feel like building a house with a hammer and nails when nailguns were readily available.
If I were writing embedded apps like flight controls today, I'd use Lisp for the high-level parts and Rust and maybe a bit of assembler for the low level parts.
Re: JavaScript: The Modern Parts
#116JavaScript is fun, but I wish they had chosen Scheme - both for scripting and instead of HTML.
Re: JavaScript: The Modern Parts
#117Earlier quoted context omitted.
Typescript solves the biggest issue I have with using JS which is a lack of a static type system. It however does it in a very pragmatic way, giving the closest experience to Vanilla JS you could hope for. You are not learning a new language like you would be with Elm or Reason etc. It has a powerful type inference system that puts C# to shame in places, and in some places I prefer TS to C#. I don't feel like Typescr…
> Typescript solves the biggest issue I have with using JS which is a lack of a static type system. Hmm, the biggest problem with JS is types? Are you sure? I rarely had issues with types in JS. With JS I just used my trusty dynamic type checker at specific places in the codebase, and testing coverage of course even more importantly. But with TS, the codebases I see on a daily base are mostly a terrible mess of wrong…
Tell me more as I want to grok the dynamic typists viewpoint as I’m sure I’ll learn something. So are you doing type check assertions at runtime and throwing errors? Or are we talking about something else?
What I like most about static typing is tooling support for refactoring and how much easier it can be to change a name or significantly change internal apis and jig stuff around with confidence.
Re: JavaScript: The Modern Parts
#118Earlier quoted context omitted.
"I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking" Surely the biggest benefit from static typing is for static-analysis tooling. (e.g. strong compile-time checks).
I don’t disagree but the way people speak about static typing is as if it’s present during the life of the application.
Different languages have different types of behaviour under the "static typing" umbrella.
Typescript has chosen to interop nicely with JS, and they took the tradeoff that if you are passed an object (e.g. from an Ajax request) and you assert that it's a Duck, TS will assume that is correct during static typing. Of course this might be wrong at runtime, you may get returned {'foo':1} instead of {'foo':'bar'} and your object.foo.length now returns undefined.
Static typing in general (in other languages) does persist into the lifetime of the application. By persist, I mean the guarantees persist, even if the types are thrown away. Haskell for example throws away the types at runtime (you can't reflect on them) but because it's so strict, you can be sure that X: String->String does indeed return a string. This you cannot be 100% sure of in Typescript.
So why is Typescript useful? Well if you write an entire app in TS (which I am doing now) then all the code you write ... which is the new non-battle-tested code ... is now type checked against itself. Also well written libraries using TS will be well type checked against. People doing stuff like casting to etc. could break things for you. But in general you get Pareto's rule applied and because most of your code is type checked (and it only isn't when getting stuff from the server or using a dodgy library that has exported an incorrect .d.ts or something), then you get almost 100% of the benefit.
Basically am I getting errors due to incorrect types at runtime in Haskell? Never. Am I getting them in Typescript? Not yet but it's possible, maybe 0.1% chance?
Re: JavaScript: The Modern Parts
#119>In that era, I wrote one of the most widely deployed pieces of JavaScript on the web, and maintained a system powered by it. Anyone know what he is talking about here? I searched google but couldn’t find what he was talking about.
I'm the original author of the post. I was talking about Parse.ly's analytics engine, where most of the data we provide to our customers on first-party analytics around their audience stems from some lightweight JavaScript code they embed in their websites. It's now installed on thousands of high-traffic sites[1] and provides analytics on over a billion web/mobile browsers per month (as described in this Strata talk[…
Very cool and interesting stuff. Many thanks for the reply and info.
Re: JavaScript: The Modern Parts
#120Earlier quoted context omitted.
There's a bizarre, naive belief that all programming is web programming. It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.
Javascript is a frustrating language. On the one hand it's more "serious" than [legacy] C, C++, Java, and Python because it had first-class functions and real lexical closures from day one. On the other, it had imprecise typing, no multiprocessing, and no access to the file system. Some of that has been fixed, but Javascript was designed by one person in a week to script web browsers and that's still painfully obviou…
Java has closures and has had since node was released.
Same for C++.
Javas functions aren't first class, but only to the extent that there's some syntactic sugar.