Agreed about JavaScript's chaotic origins - I can feel that it wasn't designed as much as Ruby and ActiveSupport are, but with ES8 JS feels like it's paved over the shoddy foundations
- things that should have always been there, like array.includes() and multi line strings are there out of the box
- 'class' means you're not having elaborate discussions with newcomers about prototypal vs class based inheritance or asking them to writr elaborate boilerplate
- async and await makes JS feel similar to traditional direct style languages
Class is a bit of a shambles. Yeah, it does make it easier to create constructors. But it also papers over the underlying prototype inheritance structure and can mislead beginners into assuming there is class system in place.
Yeah, 'class' is a lie, but for practical purposes - ie how to make a thing that other things will inherit from, most of tech uses the term 'class'. Also a prototype that is never used directly itself could be considered a class if you squint the right way ;-)
Class was one of the things that summed up ES678* for me - its nice, but it's pure syntactical sugar.
The fat arrow notation and destructuring are part of my everyday code lexicon, promises are hawt, im genuinely excited you can cancel a fetch() now, but so many other thing (proxies ffs) feel like they haven't added anything meaningful.
Which isn't to say I dislike the sugar, I have a hella sweet tooth, it's just that ES8 feels like it contains perhaps a little too much abstraction.
Do you mean cancellable promises were cancelled, or AbortSignal was cancelled? Because they went with the latter in the end. It got a bit fuzzy for a couple of years tbh. Personally I wanted cancellable promises because reasons, but i can appreciate the DRY aspects of AbortController and stuff going on in other APIs.
As recently as September the AbortSignal approach was implemented in Edge 16 and Firefox 57!
Pertinent piece from prominent professional Promise proponent Jake 'i don't only write about bloody promises' Archibald...
Feel like both languages aren't great first programming languages, but might edge towards Ruby if only for being a strongly typed language.
As I explained to a friend who was doing a python data science course, the beauty of Ruby and Python are that they get pretty damn close to the semantics of your code. As such even someone who doesn't understand the language could have a reasonable stab at trying to understand what's going on.
The bad side of this is that that syntactic sugar and other magic obscure what is really going on under the hood and can funnel students down false assumptions about how a language works.
Personally, I'd recommend Scheme as a first language, but apparently that's far too arcane for some...
Totally agree regarding semantics and the problem of too much syntactic sugar.
Where JS wins for me, is that you can quickly create something that you can click on and have it do something. From a teaching perspective that kind of interaction and quick feedback is very empowering for students. This experience will quickly inspire students to think "what else can I make this thing do". I appreciate this is not the traditional CS approach, but making things fun for students is key to getting them started coding.
A new programmer could learn both at the same time because mostly what a new programmer is learning is programming not a language. Javascript and Ruby are more like Excel and Powerpoint than English and Italian. Ruby and Javascript are software.
My opinion might be unpopular but I think neither are good as first languages.
The reason is that both languages mix many programming paradigms.
I think it is better to introduce programming paradigms one at a time. Once you understand the paradigms, you can move from language to language effortlessly.
When I introduce people to programming, I start without code. I start using cooking recipes as an example. The ingredients are the input, and the recipe is a function that produces an output.
13 comments
[ 2.3 ms ] story [ 48.6 ms ] thread- things that should have always been there, like array.includes() and multi line strings are there out of the box
- 'class' means you're not having elaborate discussions with newcomers about prototypal vs class based inheritance or asking them to writr elaborate boilerplate
- async and await makes JS feel similar to traditional direct style languages
The fat arrow notation and destructuring are part of my everyday code lexicon, promises are hawt, im genuinely excited you can cancel a fetch() now, but so many other thing (proxies ffs) feel like they haven't added anything meaningful.
Which isn't to say I dislike the sugar, I have a hella sweet tooth, it's just that ES8 feels like it contains perhaps a little too much abstraction.
As recently as September the AbortSignal approach was implemented in Edge 16 and Firefox 57!
Pertinent piece from prominent professional Promise proponent Jake 'i don't only write about bloody promises' Archibald...
https://developers.google.com/web/updates/2017/09/abortable-...
Atleast you can transpile to it.
As I explained to a friend who was doing a python data science course, the beauty of Ruby and Python are that they get pretty damn close to the semantics of your code. As such even someone who doesn't understand the language could have a reasonable stab at trying to understand what's going on.
The bad side of this is that that syntactic sugar and other magic obscure what is really going on under the hood and can funnel students down false assumptions about how a language works.
Personally, I'd recommend Scheme as a first language, but apparently that's far too arcane for some...
Where JS wins for me, is that you can quickly create something that you can click on and have it do something. From a teaching perspective that kind of interaction and quick feedback is very empowering for students. This experience will quickly inspire students to think "what else can I make this thing do". I appreciate this is not the traditional CS approach, but making things fun for students is key to getting them started coding.
Aren't you confusing Ruby with Python?
The reason is that both languages mix many programming paradigms.
I think it is better to introduce programming paradigms one at a time. Once you understand the paradigms, you can move from language to language effortlessly.
When I introduce people to programming, I start without code. I start using cooking recipes as an example. The ingredients are the input, and the recipe is a function that produces an output.