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

Is JavaScript getting worse?

buzzdecafe.github.io

Post reply on HN
Print view View original

61–70 of 117 posts

Re: Is JavaScript getting worse?

#61

Post by collyw »

vim-guru wrote: post #37
collyw wrote: post #24

Whats his problem with classes? I find them a whole lot easier to reason about than prototype based inheritance. (But then I have more experience with class based languages).

Classes adds complexity and reduces composability. With OO you end up with a soup of inheritence and patterns. Functions are way easier to compose and reason about.

They don't necessarily introduce complexity. Its a case of using thing s in the appropriate place. I use Python Django. Class based inheritance is useful, though it probably not overdone like it is in the Java world. I also use functions - I find these tend to be better for smaller units of computation and classes for overall organization.

Re: Is JavaScript getting worse?

#62

Post by rtpg »

phpnode wrote: post #34
JackMorgan wrote: post #31

Earlier quoted context omitted.

I think he means OO adds unnecessary complexity, hence the "bad bet".

ugh, really sick of this meme. OO is a tool in the box, it's useful a lot of the time, sometimes it isn't. The reason ES6 introduces the `class` keyword is that people are doing that already .

Just because a tool is in a box doesn't mean its useful. Considering the relative cleanliness, refactorability of code coming from the functional world (see Haskell and the like), it is debatable whether OOP is a "good" style to develop at all!

If I look at most of the libraries commonly used in production JS, pretty much none of them apply classic OOP principles.

Re: Is JavaScript getting worse?

#63

Post by TeMPOraL »

ajanuary wrote: post #45
makomk wrote: post #32

Earlier quoted context omitted.

If I'm following the blog post correctly, let does have effects outside of its lexical scope: it effectively makes the variable even more undefined than a totally non-existent variable . That is, the following code will not throw anything: // x has not been defined or initialized anywhere console.log(typeof x) However, if you add a let statement after it like so: // x has not been defined or initialized here console.…

It's not having an effect outside of its lexical scope. You introduce the let into the same lexical scope as the console.log. It will also throw an exception every single time. So unless you're adding a variable, and then never testing the code path that hits the new line, you're probably going to catch it pretty early.

Well, but doesn't let itself create a new implicit scope, from the point of the let statement to the end of the scope the statement is in? It seems to me that here let is indeed acting on things outside of lets own implicit lexical scope.

Re: Is JavaScript getting worse?

#64

Post by collyw »

Mithaldu wrote: post #42

Why didn't they call "spread" by the same name it's called virtually everywhere else, "flatten"?

I hate this. Why can languages try and standardize on things to at least some extent.

else if (JavaScript) elsif (Perl) elif (Python)

There is no good reason that these are different.

Re: Is JavaScript getting worse?

#65

Post by TeMPOraL »

umurkontaci wrote: post #44
makomk wrote: post #32

Earlier quoted context omitted.

If I'm following the blog post correctly, let does have effects outside of its lexical scope: it effectively makes the variable even more undefined than a totally non-existent variable . That is, the following code will not throw anything: // x has not been defined or initialized anywhere console.log(typeof x) However, if you add a let statement after it like so: // x has not been defined or initialized here console.…

I understand, but I believe this still happens only within the lexical scope where the variable has been defined with let. TBH, It doesn't bother me at all. I think I can even go ahead and say the latter makes much more sense. Using the former one is abusing the weaknesses of the language that has come along with it throughout its history. We have been whining about the bad parts of JavaScript for a long, long time a…

> I understand, but I believe this still happens only within the lexical scope where the variable has been defined with let.

Doesn't let itself introduce a new, implicit, scope? Here it seems let acts on things outside its own scope, which seems at least ugly.

Re: Is JavaScript getting worse?

#66

Post by bananaoomarang »

gamesbrainiac wrote: post #4

This is one of the few posts about javascript that I've encountered that sees hoisting as a good thing. I like `let`.

I guess the argument here is that let adds inconsistency? ie: var statements are hoisted and let statements aren't. It's a double edged sword: On the wone hand it can be used to improve readability, but it also adds complexity/more to bear in mind.

Re: Is JavaScript getting worse?

#67

Post by [deleted] »

kaoD wrote: post #60
gildas wrote: post #56

Earlier quoted context omitted.

Hoisting is great thing, it is really helpful to improve readability when doing asynchronous function calls. function a(){ setTimeout(b, 1000); } function b() { setTimeout(c, 1000); } function c() { }

If I'm not mistaken that's not hoisting, since that code will work as long as a() is called after b is declared regardless of the hoisting. Keep in mind b is only accessed when a() is actually executed, not when it's declared! Hoisting works like this: a(); function a() { console.log("FOO"); } Which might or might not be more readable, depending on your tastes.

[deleted]

Re: Is JavaScript getting worse?

#68

Post by gildas »

kaoD wrote: post #60
gildas wrote: post #56

Earlier quoted context omitted.

Hoisting is great thing, it is really helpful to improve readability when doing asynchronous function calls. function a(){ setTimeout(b, 1000); } function b() { setTimeout(c, 1000); } function c() { }

If I'm not mistaken that's not hoisting, since that code will work as long as a() is called after b is declared regardless of the hoisting. Keep in mind b is only accessed when a() is actually executed, not when it's declared! Hoisting works like this: a(); function a() { console.log("FOO"); } Which might or might not be more readable, depending on your tastes.

You're right, my example was not very good indeed.

Re: Is JavaScript getting worse?

#69

Post by TeMPOraL »

jrochkind1 wrote: post #52
umurkontaci wrote: post #22

Earlier quoted context omitted.

Function scopes and variable hoisting was not the best parts of JS anyway. let brings lexical scope into the game, which I think is a great progress. And you cannot expect a variable to be defined outside of its lexical scope. That's not any different that trying to access a variable outside of a function that is defined in. If people were abusing variable hoisting in some way, they can continue to do so, by not usin…

> And you cannot expect a variable to be defined outside of its lexical scope. Okay, but since `typeof x` can return "undefined", I would expect it to return `undefined` if x is no defined. Now, sometimes `typeof x` returns `undefined` if x is not defined, but other times it raises if x is no defined. That's the issue. I too predict this is going to give people a lot of trouble. We will see.

And the worst thing is, introducing a let variable affects code outside of the implicit lexical scope created by that let. The switch from "undefined" to "more undefined" happens one scope above. Even if it doesn't create much of a trouble for people, it feels like a very ugly design.

Re: Is JavaScript getting worse?

#70

Post by BonsaiDen »

chriswarbo wrote: post #53
collyw wrote: post #24

Whats his problem with classes? I find them a whole lot easier to reason about than prototype based inheritance. (But then I have more experience with class based languages).

Well, even if you prefer classes, you've now got to reason about prototypes and classes, and possible mixtures of both.

ES6 classes are nothing more than syntactic sugar for the existing prototypical inheritance model.
Post reply on HN