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

71–80 of 117 posts

Re: Is JavaScript getting worse?

#71

Post by phpnode »

rtpg wrote: post #62
phpnode wrote: post #34

Earlier quoted context omitted.

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.

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

Sorry but that's total nonsense. For instance, node.js makes heavy use of classes, as does Backbone, Ember, React, etc

Re: Is JavaScript getting worse?

#72

Post by jerf »

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.

You might be interested in trying Go's OO out, which privileges composition above inheritance. It's not often talked about on HN under the low-signal furor about generics, but it is a case of a small change that has a surprisingly profound effect on the language. I am becoming convinced that the current backlash against OO should really be against inheritance, not OO. Inheritance is a thing that is occasionally useful and often painful; composition is occasionally painful and often useful. The latter should be the syntactically-privileged default.

Re: Is JavaScript getting worse?

#73

Post by Demiurge »

rtpg wrote: post #62
phpnode wrote: post #34

Earlier quoted context omitted.

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.

Just because it's possible to write a program without a tool, doesn't mean it's more productive. Functional programming doesn't even directly oppose OOP, it opposes imperative. It is absolute basics of CS that there is data and logic and many problems are easy to reason about as logic modifying data (state). OOP is a tool that allows to encapsulate some data and logic that go together. Functional programming doesn't allow you much more than that. Just because you may (or may not) end up decomposing a program into the smallest units of logic, doesn't mean you've done something useful, or clean.

Re: Is JavaScript getting worse?

#74

Post by CmonDev »

rtpg wrote: post #62
phpnode wrote: post #34

Earlier quoted context omitted.

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.

"pretty much none of them apply classic OOP principles"

Most of them are forced to be using some poorman's OOP. See Angular 1.x vs Angular 2.0. OOP is always around the corner, even if it is standard DOM.

Re: Is JavaScript getting worse?

#75

Post by CmonDev »

chriswarbo wrote: post #50
mmahemoff wrote: post #20

Whoop-dee-freakin’-doo??? Sure there's a zillion frameworks and patterns for shoehorning OO into JavaScript. But the point is, ES6, is standardising it. That means libraries going forward will assume this is the way it's done and build on top of it. It gives them more expressive power and better inter-op. Also, default params are long overdue but I'm not sure that makes them "so what". I'd rather avoid mangling the a…

How exactly can OO be "shoehorned" into a language which is already OO?

He meant proper OO as opposed to the shanty prototype one.

Re: Is JavaScript getting worse?

#76

Post by svisser »

arcatek wrote: post #33
hasenj wrote: post #23

Earlier quoted context omitted.

`typeof a` right now returns the string value "undefined" (assuming `a` was not defined anywhere) If it can either return "undefined" or throw an exception, can you see why that would be a problem?

No, because it can only throw if there's a flaw in the code. Not randomly according to the argument passed to the function. Unless I'm missing something, it will either always throw, or never throw.

If a statement didn't throw before and might start throwing now, that would be a problem for existing code wouldn't it?

Re: Is JavaScript getting worse?

#77

Post by ajanuary »

TeMPOraL wrote: post #63
ajanuary wrote: post #45

Earlier quoted context omitted.

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.

They are in the same lexical scope.

Inside a lexical scope, all matching variable names refer to the same variable. Because they are in the same lexical scope, all instances of the variable name "x" refer to the same variable.

Separate (but related) to this is the concept of where it is valid to dereference variables (this is where my knowledge breaks down - is there an accepted term for this?). Javascript says that for variables declared with "var", it is always valid to dereference them, but it might dereference to "undefined". For variables declared with "let", it is only valid to dereference variables in the lexical scope. In addition to this, it defines a "temporal dead zone", which covers the span between the start of the lexical scope and the "let" declaration. This isn't a novel thing - other languages do it, though they may use different terminology.

It's this "temporal dead zone" that you seem to be referring to when you say it's creating a new implicit scope.

It's still impossible for a let declaration to affect anything outside of its lexical scope. If it's shadowing a variable name in a parent scope, what it can do is stop variable names earlier in the scope from referring to the parent scope and make it refer to the variable in inner scope. This may seem like a problem, but most other languages will do the same thing (C++, Java, C#, Python, Ruby etc.) and I've never seen it be much of an issue.

Re: Is JavaScript getting worse?

#78

Post by jbergens »

CmonDev wrote: post #75
chriswarbo wrote: post #50

Earlier quoted context omitted.

How exactly can OO be "shoehorned" into a language which is already OO?

He meant proper OO as opposed to the shanty prototype one.

The problem is for anyone who sees prototype OO as a better solution. They kind of give their blessings to the other OO, which is a bit sad. (edit: spelling)

Re: Is JavaScript getting worse?

#79

Post by antimagic »

phpnode wrote: post #51
chriswarbo wrote: post #49

Earlier quoted context omitted.

I somewhat agree, but "adding tools" at the language level doesn't come for free: it causes an explosion in the number of interactions to keep track of. How do classes interact with prototypes? How do they interact with lexical scope? How do they interact with exceptions? etc. The egregious part is that, by turning something into a language feature, those who don't use it are often forced to take it into account in t…

> those who don't use it are often forced to take it into account in their code; especially library authors. No, `class` is syntactic sugar for the most common way of doing classes in ES3 and ES5. There is no semantic difference between: function Thing () {} Thing.prototype.greet = function () { alert("hello"); }; and class Thing { greet () { alert("hello"); } } They are the same, so it introduces no new traps for li…

About the only thing that might be interesting to see is how constructor parameters are handled. With the prototyping system, I consider it to be a bug to initialize members in the constructor - if you always just call an 'init' method straight after construction (typically chained, much like in Objective C - var thing = new Thing().init(param); ) then protyping is very simple and does nothing surprising. It's only if you really really really want to have RAII that things become complicated...

Re: Is JavaScript getting worse?

#80

Post by ajanuary »

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.

typeof isn't raising the exception, the runtime is raising it before typeof is even evaluated.
Post reply on HN