Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript. The Core: 2nd Edition

dmitrysoshnikov.com

Post reply on HN
Print view View original

71–80 of 96 posts

Re: JavaScript. The Core: 2nd Edition

#71

Post by tomatsu »

chubot wrote: post #41
Sawamara wrote: post #9

This is a very solid foundation to work with, for anyone who might have struggled with the contexts and how arrow functions, local variables, thises (hah) and prototypes fit into the bigger picture. It also clearly shows that Javascript is not the mess that it looks like from a beginner's perspective. Yes, anyone can create a 15-20 min video about how == and === can mess up stuff, how you cant just pass around a func…

I wonder why nobody has created a version of JavaScript that just throws exceptions for all the WTF cases? That is, it would basically be a mode like 'use strict-at-runtime'; . This would be incompatible, but it would be a useful development aid. Surely most frameworks like React and Angular avoid these corners of the language, and they could be trivially modified to run on such an interpreter? It would improve their…

> why nobody has created a version of JavaScript that just throws exceptions for all the WTF cases?

Google experimented with something they called "strong mode". Classes were read-only, accessing nonexistent properties was an error, and things like that.

I liked it. Unfortunately, the experiment didn't go anywhere and strong mode was removed from Chrome.

Dart is somewhat similar, though. It got more straightforward semantics than JS and most of those WTF things are an error.

Re: JavaScript. The Core: 2nd Edition

#72

Post by eropple »

always_good wrote: post #69
eropple wrote: post #52

Earlier quoted context omitted.

I still find a lot of reasons to use Ruby, though like you I spend a lot of time doing JavaScript in places I wouldn't have a couple years ago. (For a long time I've been anything-but-JavaScript, but I was also using JavaScript before it was cool--somewhere on a hard drive somewhere is a JavaScript implementation I wrote as a scripting layer for a game I was working on in like 2006...) My experience with API design i…

I don't like ORMs or abstractions like grape-swagger. I like working with the node-postgres client and knex when I need a query builder. It sounds like if that's the sort of kit you want, then Ruby is for you compared to Clojure/Javascript. What I do like about Javascript is that it's easy to write ad-hoc types via Typescript for my SQL functions to specify the shape of the data that comes from the database. I would…

I'm very confused as to why you don't care for "abstractions" like grape-swagger. Do you enjoy writing API client boilerplate?

As far as ORMs go, I'd certainly prefer not to use Active Record ones, but I also don't want to have to update my code when somebody else adds a field that I don't care about. My representations specify what I care about and how it should be presented to clients (for example, hashids rather than integer primary keys); I update them only when there's a new field that I care about. I can do this with functional mapping but the database boilerplate sucks more than Sequel does (it's a big part of why I've dropped ROM, though I much prefer it in theory). Computers exist to help me do less programming, not more, and what you describe is more programming for, to me, little benefit.

Re: JavaScript. The Core: 2nd Edition

#73

Post by mvaliente2001 »

Sawamara wrote: post #9

This is a very solid foundation to work with, for anyone who might have struggled with the contexts and how arrow functions, local variables, thises (hah) and prototypes fit into the bigger picture. It also clearly shows that Javascript is not the mess that it looks like from a beginner's perspective. Yes, anyone can create a 15-20 min video about how == and === can mess up stuff, how you cant just pass around a func…

I agree, this post is super-b, but it also shows why JS is the mess everybody knows it is. When you use a function as a constructor, the function creates an object and assigns as its __proto__ the value of the function's 'prototype', which is an object with the class' methods and that has an attribute 'constructor' that points back to the constructor function... and all that... for what? What purpose has this over-complex dance of references? Before trying to justify the current status quo, let's ask ourselves "could it be done easily?"

The answer is a resounding yes. Javascript is a prototype oriented language (nothing wrong with that) who is ashamed of being prototype oriented and wanted to look object (class) oriented, and that's a shame.

And of course, we have ECMA, a committee whose motto is "let's not change any past error no matter how flagrant it is, let's add just another layer of painting over it". That's why we have to live with hoisting and var/let, and crazy type conversions that are an affront to every living neuron in the universe, and typeof which return useless values, and yes, two comparison operators because the first one was worse than wrong.

Re: JavaScript. The Core: 2nd Edition

#74

Post by mvaliente2001 »

sli wrote: post #24
macspoofing wrote: post #14

Earlier quoted context omitted.

>It also clearly shows that Javascript is not the mess that it looks like from a beginner's perspective. Let's agree to disagree. I suspect your bar is too low. You could have made that argument for early versions of PHP (i.e. before 5)

Full disclosure: I've been writing JS for pretty much as long as I can remember and currently do it professionally, and I'm speaking mostly to my personal experience with having used both of them personally and professionally. The question is how often you get bitten in the ass by it, specifically as a professional rather than a beginner, and in my experience it's been very little with Javascript but quite often with…

In my case, my problem is that I like clean languages, languages whose mental model I can keep in my mind. I found "== is broken, use === instead" a terrible way of designing a language. It should have been "== is broken, let's fix it today so tomorrow will be better for everybody."

I can program in JS, and sometimes I even enjoy it. I had a friend who liked snakes and had several as pets, even some poisonous. I prefer kittens.

Re: JavaScript. The Core: 2nd Edition

#75

Post by abiox »

johnhenry wrote: post #29

> "ECMAScript is an object-oriented programming language, having concept of an object as its core abstraction." I'm curious as to whether or not this definition makes sense to other developers? ECMAScript does have a built-in "Object" data type, though I wouldn't say that this is it's "core abstraction". Further, firmly object-oriented languages, such as Java, seem to lack this abstraction. Perhaps I'm missing someth…

"object oriented" can mean a wide variety of things.

java isn't necessarily more object-oriented than other options. generally, i think when people say "oo", they're really just referring to nominal subtyping; probably due to the language's ubiquity (as well as c++ and c#).

this nominal subtyping gives rise to the hierarchical taxonomies of object-classes that are a quintessential characteristic of java, c# and friends.

Re: JavaScript. The Core: 2nd Edition

#76

Post by mvaliente2001 »

johnhenry wrote: post #29

> "ECMAScript is an object-oriented programming language, having concept of an object as its core abstraction." I'm curious as to whether or not this definition makes sense to other developers? ECMAScript does have a built-in "Object" data type, though I wouldn't say that this is it's "core abstraction". Further, firmly object-oriented languages, such as Java, seem to lack this abstraction. Perhaps I'm missing someth…

It's a Prototype Oriented Language, a language where the inheritance chains follows objects. Although, in all fairness, Object Oriented programming should be called Class Oriented, and Prototype Oriented should be called OOP.

Re: JavaScript. The Core: 2nd Edition

#77

Post by johnhenry »

FLUX-YOU wrote: post #33
johnhenry wrote: post #29

> "ECMAScript is an object-oriented programming language, having concept of an object as its core abstraction." I'm curious as to whether or not this definition makes sense to other developers? ECMAScript does have a built-in "Object" data type, though I wouldn't say that this is it's "core abstraction". Further, firmly object-oriented languages, such as Java, seem to lack this abstraction. Perhaps I'm missing someth…

Huh? All objects in Java implicitly derive from java.lang.Object. Same for .NET and System.Object. The exceptions being value-types and structs.

Sorry, as a Javascript developer, my understanding of the Objects in Java is crude at best, so I may not have made a lot of sense here.

Re: JavaScript. The Core: 2nd Edition

#79

Post by madhadron »

Rapzid wrote: post #36
Scarbutt wrote: post #27

Earlier quoted context omitted.

Hey, Toyota and Honda are good quality cars, did you mean chevrolet, ford or renault?

Hey, I own a Fiesta SE and ST and they are great. Ford quality is way up.. Actually, maybe that's a perfect analogy for javascript :)

That's because they're designed in Germany now.

Re: JavaScript. The Core: 2nd Edition

#80

Post by scottmf »

chubot wrote: post #41
Sawamara wrote: post #9

This is a very solid foundation to work with, for anyone who might have struggled with the contexts and how arrow functions, local variables, thises (hah) and prototypes fit into the bigger picture. It also clearly shows that Javascript is not the mess that it looks like from a beginner's perspective. Yes, anyone can create a 15-20 min video about how == and === can mess up stuff, how you cant just pass around a func…

I wonder why nobody has created a version of JavaScript that just throws exceptions for all the WTF cases? That is, it would basically be a mode like 'use strict-at-runtime'; . This would be incompatible, but it would be a useful development aid. Surely most frameworks like React and Angular avoid these corners of the language, and they could be trivially modified to run on such an interpreter? It would improve their…

https://github.com/eslint/eslint
Post reply on HN