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

111–117 of 117 posts

Re: Is JavaScript getting worse?

#111

Post by CrossEye »

chriswarbo wrote: post #58
arcatek wrote: post #21

Earlier quoted context omitted.

My bad, I misread. However, my point is still the same: there was two equally valid choices. Should the other path had been prefered, the author would now be complaining about it too. I don't find it very constructive. As for Whoop-dee-freakin’-doo, no, it don't think it means anything in the context. That's not an argument, and the following sentence isn't either. Maybe I don't understand because english isn't my na…

From my understanding, the author was complaining about the way default arguments mess up implementations of currying. If default arguments were included in the .length, then all existing currying implementations would carry on working with no modifications, they would just ignore the default values and require that we pass in values explicitly. Let's say we have these functions: function getElem(arr, index=0) { retu…

Very well said. I work on the Ramda (http://ramdajs.com/) FP JS library with the OP. Ramda is heavily invested in currying, and I don't yet have a clue how we'll deal with default parameters. At first guess, we'll simply have to explain that we can't curry such functions. Such a shame!

Re: Is JavaScript getting worse?

#112

Post by CrossEye »

collyw wrote: post #64
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.

Yes, and those damned Italians still refuse to switch to English too!

Re: Is JavaScript getting worse?

#113

Post by ajanuary »

CrossEye wrote: post #109
ajanuary wrote: post #107

Earlier quoted context omitted.

> Now, sometimes it will throw. No, typeof /isn't/ throwing. let x = 1; function some_random_function(y) { } (function() { some_random_function(x); let x = 2; })(); This will throw the same exception for exactly the same reason. You're using a variable defined using "let" before the variable definition. Sod all to do with typeof. I don't see it as massively confusing that a variable declared one way behaves different…

I think the concern is simple, really. People are going to be told (rightly so) to use `let` instead of `var`. If they do so too mechanically, and their code is structured in certain ways, an expression which could never before throw an exception in Javascript, `typeof x`, now will do so. This is not the end of the world, by any means. And it doesn't add an exception into unchanged code, but it still is a legitimate…

In pretty much every case, if changing 'var' to 'let' would trigger this issue, the original code isn't doing what the author thought it was.

Re: Is JavaScript getting worse?

#114

Post by ajanuary »

jrochkind1 wrote: post #110
ajanuary wrote: post #107

Earlier quoted context omitted.

> Now, sometimes it will throw. No, typeof /isn't/ throwing. let x = 1; function some_random_function(y) { } (function() { some_random_function(x); let x = 2; })(); This will throw the same exception for exactly the same reason. You're using a variable defined using "let" before the variable definition. Sod all to do with typeof. I don't see it as massively confusing that a variable declared one way behaves different…

I understand that it's not typeof that's throwing. The statement `typeof x` still results in a throw. I understand that it's not `typeof` doing it. It is still the case that before, you could write `typeof x` to see if `x` was defined in all cases, and the line you wrote, `typeof x` would never throw, for any possible state of `x`. Now, that is no longer true. That is what people are "up in arms" about. Although as f…

> ... before, if I wanted to know if `x` is defined, i could write `typeof x !== "undefined"`. In all cases. And the result of that statement would never be a throw. Now, if I want to know if x is defined, there are at least two kinds of "undefined", one that will be returned by `typeof x` as "undefined", and another where I am not allowed to mention `x` at all, including to do `typeof x`.

You can still write 'typeof x !=== "undefined"' and not worry about an exception being thrown. There are pretty much no situations where you're going to write legitimate code and 'typeof x !=== "undefined"' is going to throw. Any situations where it will would also break if you used var, but in much less obvious ways.

"Is this variable reference before its variable declaration" is never a question that you would ever want to ask at runtime.

I really don't think we'd be having this discussion if it had started with any statement other than "typeof x", but the function/operator (as we've tediously established) has no bearing on the behaviour exhibited.

You have variables. It's illegal to refer to a variable before its been declared in it's lexical scope. Once declared, variables start with the value "undefined" until you assign them a value. I don't see what's massively complicated about that. Its the same as in many other languages, just replace "undefined" with "null".

I have seen exactly zero blog posts about people being confused that they can't reference a variable before its been declared in other languages. I have seen dozens about people being confused by "variable hoisting". When looked at along with how it interacts with other language features, 'let' is definately less confusing than 'var'.

Re: Is JavaScript getting worse?

#115

Post by klibertp »

tel wrote: post #100
Demiurge wrote: post #97

Earlier quoted context omitted.

As long as I'm not using C++ I don't feel harmed by any OOP features I don't have to use. I don't feel being restricted. I'm curious, what are these commonly harmful things you're talking about? On the other hand, most FP languages I tried feel very restrictive. The only language that is inclusive of all good ideas, seems to be F#.

I'm not a big fan of languages allowing mutability anywhere. You can use it, sure, but advertise in big bold letters as to where. This plays out repeatedly for any side effect. There are some OO systems with effect types I suppose. Those would be interesting. There are also OO systems that don't have mutability. But I think that it you remove mutation, all that class nonsense, and are careful with subtyping (since it…

> There are some OO systems with effect types I suppose. Those would be interesting.

Nim has something IIRC, but I didn't look into it yet.

Re: Is JavaScript getting worse?

#116

Post by lgunsch »

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.

>Classes adds complexity and reduces composability.

I could easily argue the opposite. Classes reduce complexity, and increase composability. Classes allow you to group methods in a cohesive manner into a single entity. For example, a class named Queue, List, or Vector would imply to the programmer what it does without them reading any code at all.

>With OO you end up with a soup of inheritence and patterns.

Just because programmers don't make clean code, doesn't mean the whole idea is somehow lesser then just using functions. Having a hodge-podge of 2000 line functions in one massive file is just as evil as "dirty" OOP code. At least classes encourage you to group your functions in some hopefully sane manner.

>Functions are way easier to compose and reason about.

Functions are easy to compose and reason about, however, that does not mean that classes and OOP are not as easy. Each have their own clear costs/benefits. OOP, and procedural programming, should both be in a programmers toolbox.f

Re: Is JavaScript getting worse?

#117

Post by buzzdecafe »

lgunsch wrote: post #116
vim-guru wrote: post #37

Earlier quoted context omitted.

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.

> Classes adds complexity and reduces composability. I could easily argue the opposite. Classes reduce complexity, and increase composability. Classes allow you to group methods in a cohesive manner into a single entity. For example, a class named Queue, List, or Vector would imply to the programmer what it does without them reading any code at all. > With OO you end up with a soup of inheritence and patterns. Just b…

(article author here) I very much agree with this point of view. The most important concern is a developer who thinks and writes clearly, irrespective of style or programming paradigm.

That said, I find FP easier to reason about and comprehend, but that is just one man's opinion. I also find it more fun.

The "bad bet" I was referring to was that you can make JS impersonate Java. That strikes me as a losing proposition. Sugaring up prototype inheritance to look like class-based inheritance just muddies the water.

Post reply on HN