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

81–90 of 96 posts

Re: JavaScript. The Core: 2nd Edition

#81

Post by SwellJoe »

FLUX-YOU wrote: post #28
sh87 wrote: post #22

Earlier quoted context omitted.

I fail to get the flak that javascript faces ! Coming from java it was a breath of fresh air. This was the car that let me drive without a seatbelt when i wanted, let the doors be open if i wanted, stepping on the gas accelerated without fail and the brakes functioned fine, i could change the gearbox orientation, choose which side the steering wheel i wanted to be in general let me do what i wanted to without getting…

>I fail to get the flak that javascript faces ! I personally don't like that Javascript has had to have a ton of work done on it to get it to the point of other languages that were better at their first release. It was just a ton of time spent on something that was weak to begin with. If Javascript were better at the beginning, and this same effort was spent on it, it probably would be ruling the world, front and bac…

"it probably would be ruling the world, front and back-end"

So, what would be different about that? JavaScript does rule the world, front (definitely) and back-end (arguably, but there aren't a lot of contenders for the language that's more popular for new projects).

Re: JavaScript. The Core: 2nd Edition

#82

Post by Roboprog »

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.

That's what fixed precision types are: integers + a scale factor -- whether it's cents, mils or something else.

Javascript does badly need a native fixed precision type beyond "everything is a double" or some web assembly hack.

And I like Javascript, but this is a real problem.

Re: JavaScript. The Core: 2nd Edition

#83

Post by Roboprog »

mvaliente2001 wrote: post #76
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.

... and the Smalltalk gangs squares off to rumble with the Simula67 gang :-)

(meanwhile, Scheming away in the background ...)

Re: JavaScript. The Core: 2nd Edition

#84

Post by Roboprog »

As many useful things as there are in ES2015 (and beyond!), it's probably worth pointing out a few "corporate" environmental constraints that might limit one to ES 5.1:

* IE11 isn't dead yet. MS still supports it.

* The "Nashorn" engine inside (Oracle) Java 8 only supports 5.1.

Scoff at them if you will, but some of us have to live with these things, and aren't using a transpiler.

Re: JavaScript. The Core: 2nd Edition

#85

Post by Roboprog »

One issue I have with this JS tutorial is that it spends little to no time talking about FP, just OOP (functional vs object-oriented programming).

What text it does devote to Closures makes them sound like a "problem" to be worked around. Funny, I thought "this" was the problem (to be worked around, or avoided entirely whenever possible).

Class based languages such as Java do an excellent job of modeling how I thought about programming back in 1990. It's how we were taught in school, so as to be able to manage mutable data in a turing tar pit. (remembering a lecture about garbage collection, which essentially scoffed at the overhead...)

Having learned a good deal more about FP in the last 10 or 15 years (beyond the little bit of Lisp I did in an AI class back in the 80s), Javascript really starts to shine in many ways, whereas Java (and other [Simula67 subset] C++ derivatives) looks like the intellectual cripple in comparison.

I wish people would stop trying to turn Javascript into something more and more like C++/Java. Just stop, already. It was supposed to be like Scheme and/or Smalltalk, but The Management (marketing) got involved, and the rest is tragedy, er, history.

Re: JavaScript. The Core: 2nd Edition

#86

Post by yugoja »

Roboprog wrote: post #85

One issue I have with this JS tutorial is that it spends little to no time talking about FP, just OOP (functional vs object-oriented programming). What text it does devote to Closures makes them sound like a "problem" to be worked around. Funny, I thought "this" was the problem (to be worked around, or avoided entirely whenever possible). Class based languages such as Java do an excellent job of modeling how I though…

The last paragraph describes perfectly frustration JavaScript developers face while going deep into the language.

Re: JavaScript. The Core: 2nd Edition

#87

Post by vog »

sAbakumoff wrote: post #43
vog wrote: post #13

Earlier quoted context omitted.

Do you care to elaborate? What do you see missing, what should be improved?

I mean downvoters didn't care to elaborate, so why should I do that.

> downvoters didn't care to elaborate

Obviously not true. You just replied to the counterexample, where I did elaborate on my downvote.

Re: JavaScript. The Core: 2nd Edition

#88

Post by baddox »

chubot wrote: post #47
baddox wrote: post #42

Earlier quoted context omitted.

I think the most common way to accomplish that idea is to run a linter. Linters should be able to statically catch most of the unsafe operations you're probably describing.

Yeah, that's probably true -- linters do an OK job at attacking this problem. But then there are still people complaining about JS semantics... I think there is a gulf between what tools professional JS programmers use, and what tools X programmers use when they write JavaScript, where X != JavaScript.

I think most JS fans these days recognize the inherent problems with JS, and work around them with best practices (on the lenient side) or linters and more advanced preprocessors like type checkers (on the strict side). At the end of the day, by far the main advantage of JS is the fact that there are mature and reliably-updated implementations with a relatively easy and open distribution platform on virtually every modern computing device (browsers and the World Wide Web). Some of the other fundamentals of the language are nice (particularly first-class functions), while the bad fundamentals (particularly the hopelessly messy type coercion) are now well-recognized and hopefully avoided through various techniques.

Re: JavaScript. The Core: 2nd Edition

#89

Post by oweiler »

tomatsu wrote: post #71
chubot wrote: post #41

Earlier quoted context omitted.

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 s…

Dart has strong mode.

Re: JavaScript. The Core: 2nd Edition

#90

Post by sp4rki »

andreasgonewild wrote: post #65
aaron-lebo wrote: post #34

Earlier quoted context omitted.

It's jealousy. Most languages had major design flaws. Rubyists will gladly complain about how OO is bolted on in Python, Python users will gladly talk about how slow Ruby's interpreter was and how god awfully complex the syntax is. Both of them have limitations in their runtimes and are actually catching up to JS in some areas (see Python's adoption of async). We can talk about how baroque CL is or how much Java suck…

JavaScript and PHP are badly/barely designed languages, period; no amount of excuses and comparisons is going to change the fact. Anyone with a bit of experience in either Ruby or Python will tear their hair out when doing JS, because they know it doesn't have to be that difficult. These days it's looking more and more like C++ every day...

This is of course my personal opinion, but I think you're suffering from exactly what OP mentions. I'm not trying to be conflictive or anything, but this is in my experience the same argument that every language evangelist uses.

I started with C in my early teens (first book I found, lucky me) and I've gone through the VB, PHP, Java, Python, Ruby, and Javascript phases. Honestly I've seen great engineering in all those languages (maybe not VB) and those projects have all been easy and pleasurable to work with (maybe not Java). I've also seen hideous stuff that's a total sanity destroyer. At least for me the main contributing factor to language dislike is dealing with shitty code. Except Classic ASP... That stuff is poison.

Post reply on HN