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

51–60 of 96 posts

Re: JavaScript. The Core: 2nd Edition

#51

Post by nightski »

sh87 wrote: post #46
nightski wrote: post #45

Earlier quoted context omitted.

It has not overcome any of the flaws, we have just learned to work around them. They are still there and can bite you. Some of us value our time and would like to improve our discipline. In other fields it's called being professional. It's a shame we care so little about it.

You've got me thinking now. Can you/anyone give me 3 solid cases where the flaw was in javascript and not the programmers understanding of the language ? I can't. (Not at the moment at least). Most of the times I got things wrong it was my understanding of how js works that was at fault.

Of course the flaw is always in the programmer's understanding. Langauges do not manipulate or lie to you, they are what they are.

However, better tools and languages reduce your cognitive burden. The less mental context you have to work with the more you can focus on the problem at hand. If you have to constantly worry about language edge cases and odd behavior, it really detracts from being able to focus on the problem you are trying to solve.

There is a reason languages like TypeScript and Flow exist, they are helping to reduce this large burden JavaScript carries with it.

JavaScript is really great for small scripts (which is the use case it was designed for).

Anything beyond a few hundred lines starts to carry a lot more cognitive load. Not to mention that we are now building full fledged applications with tens of thousands of lines in this language.

Re: JavaScript. The Core: 2nd Edition

#52

Post by eropple »

always_good wrote: post #26
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)

It's hard for me to take these comments seriously unless you feel this way consistently across most other dynamically-typed languages -- at least it'd be consistent. I've used most dynamically-typed langs at this point and I've run out of reasons to use something aside from modern Javascript if I would have originally used Clojure or Ruby in the past. Though it feels sheepish to reward your low-effort comment with a…

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 in JavaScript is that it still kind of sucks. It's not the worst, that wonderful spot goes to PHP, but it's distinctly harder to get something usable and maintainable done than Grape/Ruby. Probably worse than Flask/Python, too. The Swagger tools out there for JavaScript aren't very good and none of the lesser-used alternatives seem any better; maybe it's the stateful/metaprogramming-friendly nature of Ruby, but `grape-swagger` is really nice and nothing comes close in JS, at least not that I've found.

Data representation worries me, too. I have not yet found a decent `grape-entity`/`representative` library in JS (think a `grape-entity` or a `representative`). On top of that, SQL library support out there is pretty bad, Sequelize being the best I've found but much worse than Ruby's Sequel or even ROM. Sequelize is still frustrating and clunky.

I'm also uncomfortable dealing with money and financials in JavaScript, in part because of the lack of a BigDecimal/fixed class that I feel like I can trust (as I'm not really qualified to judge the implementations of the billion gems out there). A standard library I feel like I can trust is still out there, somewhere.

If all I have to do is plop out an endpoint, then JS (shouts, Express!) is as easy as it gets, and that's fine. But these days I need more, I want my tools to help me with it, and I don't really have time or inclination to build them, either.

If I'm missing any that are worth checking out, though, by all means, I'm very interested.

Re: JavaScript. The Core: 2nd Edition

#53

Post by jandrese »

CJefferson wrote: post #40
eitland wrote: post #32

Earlier quoted context omitted.

It gets flak for the same reason php gets flak. They both more or less accidentally became popular. None of them were very well designed. They both lacked type safety. Unlike php though javascript became not only popular but it actually ended up being the only alternative.

I don't think they accidentally became popular. The features which make a language rise rapidly might just be different to the features that make a language "good". PHP in particular is amazing for getting started at speed. I remember taking a HTML file and popping in a couple of lines of PHP in the middle. I still haven't found anything anywhere near that easy for making a server backed website.

You aren't the first person to think of this. It is otherwise known as Worse is Better[1]. Stuff that doesn't have all of that nice formalism but lets you get simple applications working without a lot of up-front training and boilerplate tends to be what people gravitate towards instead of "properly designed" languages.

[1] https://en.wikipedia.org/wiki/Worse_is_better

Re: JavaScript. The Core: 2nd Edition

#54

Post by busterarm »

CJefferson wrote: post #40
eitland wrote: post #32

Earlier quoted context omitted.

It gets flak for the same reason php gets flak. They both more or less accidentally became popular. None of them were very well designed. They both lacked type safety. Unlike php though javascript became not only popular but it actually ended up being the only alternative.

I don't think they accidentally became popular. The features which make a language rise rapidly might just be different to the features that make a language "good". PHP in particular is amazing for getting started at speed. I remember taking a HTML file and popping in a couple of lines of PHP in the middle. I still haven't found anything anywhere near that easy for making a server backed website.

For very limited tasks that PHP is still oddly popular for: NGINX's Server Side Includes module. ;)

If that's already your web server, anyway.

Re: JavaScript. The Core: 2nd Edition

#55

Post by thanatropism »

eropple wrote: post #52
always_good wrote: post #26

Earlier quoted context omitted.

It's hard for me to take these comments seriously unless you feel this way consistently across most other dynamically-typed languages -- at least it'd be consistent. I've used most dynamically-typed langs at this point and I've run out of reasons to use something aside from modern Javascript if I would have originally used Clojure or Ruby in the past. Though it feels sheepish to reward your low-effort comment with a…

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…

Money comes in integers. Any function that works with monetary values needs to eat integers and output integers.

This is not pedantry, it's a real-world constraint.

Re: JavaScript. The Core: 2nd Edition

#56

Post by wlesieutre »

sh87 wrote: post #46
nightski wrote: post #45

Earlier quoted context omitted.

It has not overcome any of the flaws, we have just learned to work around them. They are still there and can bite you. Some of us value our time and would like to improve our discipline. In other fields it's called being professional. It's a shame we care so little about it.

You've got me thinking now. Can you/anyone give me 3 solid cases where the flaw was in javascript and not the programmers understanding of the language ? I can't. (Not at the moment at least). Most of the times I got things wrong it was my understanding of how js works that was at fault.

I understand that Javascript will silently do something stupid and keep going if I accidentally call a function with an argument left off, but I'd still prefer to get an error message.

I understand that I need to use === instead of == to check if two things are actually equal, but I don't like that either.

It's not that you can't understand how the language works, it's that the language does some things that feel stupid when you're coming to it from any other programming language. Even if I can work around all of them it doesn't feel like I should have to when we have a lot of better planned programming systems, and that makes trying to get into js feel frustrating.

Re: JavaScript. The Core: 2nd Edition

#57

Post by sh87 »

nightski wrote: post #51
sh87 wrote: post #46

Earlier quoted context omitted.

You've got me thinking now. Can you/anyone give me 3 solid cases where the flaw was in javascript and not the programmers understanding of the language ? I can't. (Not at the moment at least). Most of the times I got things wrong it was my understanding of how js works that was at fault.

Of course the flaw is always in the programmer's understanding. Langauges do not manipulate or lie to you, they are what they are. However, better tools and languages reduce your cognitive burden. The less mental context you have to work with the more you can focus on the problem at hand. If you have to constantly worry about language edge cases and odd behavior, it really detracts from being able to focus on the pro…

> Anything beyond a few hundred lines starts to carry a lot more cognitive load. Not to mention that we are now building full fledged applications with tens of thousands of lines in this language.

Agree completely.

Re: JavaScript. The Core: 2nd Edition

#58

Post by eropple »

thanatropism wrote: post #55
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…

Money comes in integers. Any function that works with monetary values needs to eat integers and output integers. This is not pedantry, it's a real-world constraint.

I thought your "real-world constraint" existed too. Then I had to keep track of thousandths of a cent.

When you have experienced the "no, a cent is no longer granular enough" problem, the conversion of DECIMAL(7,2) to DECIMAL(9,4) and the attendant code compatibility is something you'll appreciate.

Re: JavaScript. The Core: 2nd Edition

#59

Post by erokar »

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…

Probably because the WTF cases are exaggerated. After a couple of months coding JS you will know it well enough so it doesn't bite you. It really is a non-issue for people who work with it daily.

Re: JavaScript. The Core: 2nd Edition

#60

Post by FLUX-YOU »

sh87 wrote: post #46
nightski wrote: post #45

Earlier quoted context omitted.

It has not overcome any of the flaws, we have just learned to work around them. They are still there and can bite you. Some of us value our time and would like to improve our discipline. In other fields it's called being professional. It's a shame we care so little about it.

You've got me thinking now. Can you/anyone give me 3 solid cases where the flaw was in javascript and not the programmers understanding of the language ? I can't. (Not at the moment at least). Most of the times I got things wrong it was my understanding of how js works that was at fault.

>Can you/anyone give me 3 solid cases where the flaw was in javascript and not the programmers understanding of the language ? I can't.

These were problems in various stages of JS's history, but not necessarily now:

Browser differences in javascript by not having a good specification or strong governing body.

Not having block-level scope despite convention in other C-like languages.

Optional semi-colons.

typeof inconsistencies.

Another problem with JS changing so much is developers picking up the language at various points in that development.

Post reply on HN