Live data from Hacker News

Is JavaScript getting worse?

buzzdecafe.github.io

91–100 of 117 posts

Re: Is JavaScript getting worse?

#91
post #81

Earlier quoted context omitted.

Without backing a horse exactly: * FP as I understand it doesn't much oppose imperative or even most of OO. It opposes non-composability using discipline from pure/total languages. * Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that (ADTs, existential types, modules, what-have-you do it fine if not far better). The remaining 90% may be a waste or acti…

>FP as I understand it doesn't much oppose imperative or even most of OO I think this is definitely true, if you take 'oppose' as 'incompatible'. If we look the design concept and plot them, there will be axes, and I think this is what we'll see. >* Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that That's also true, but it's not an argument against th…

My point is merely that the benefits of are gained using essentially nothing more than real ADTs and yet are almost always bundled with harmful other things in practice. FP can include these core ideas nicely, much like how monads include imperative ideas nicely, by focusing on what composes well.

Re: Is JavaScript getting worse?

#92
post #71
post #62

Earlier quoted context omitted.

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

To whoever downvoted me, am I wrong? Please explain.

Re: Is JavaScript getting worse?

#93
post #90

Earlier quoted context omitted.

Remember, it's not the function that's throwing the exception, it's the runtime. In order to make it not throw an exception, we'd have to special case typeof to make the runtime behave differently just for it. /That/ is inconsistent.

This throws an error: typeof x; // throws an error let x = 1; This doesn't: typeof x; // returns "undefined" var x = 1; While using variables before declaring them is bad practice, I think it's fair to argue that this behaviour is inconsistent.

[deleted]

Re: Is JavaScript getting worse?

#94
post #90

Earlier quoted context omitted.

Remember, it's not the function that's throwing the exception, it's the runtime. In order to make it not throw an exception, we'd have to special case typeof to make the runtime behave differently just for it. /That/ is inconsistent.

This throws an error: typeof x; // throws an error let x = 1; This doesn't: typeof x; // returns "undefined" var x = 1; While using variables before declaring them is bad practice, I think it's fair to argue that this behaviour is inconsistent.

    let x = 0;
    function typeof_wrapper(y) { return typeof y; }

    (function() {
        typeof_wrapper(x); // throws an error
        let x = 1;
    })();

    (function() {
        typeof_wrapper(x); // returns "undefined"
        var x = 1;
    })();
Again, typeof isn't throwing the error, the runtime is, because a variable declared with "let" is being referenced before the declaration. It's not inconsistent, it's one of the main points of "let".

You're essentially arguing that a feature added because the old behaviour was undesirable is inconsistent because it's not exhibiting the old undesirable behaviour.

Re: Is JavaScript getting worse?

#95
post #62

Earlier quoted context omitted.

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.

> it is debatable whether OOP is a "good" style to develop at all! You've drank way too much Kool-Aid here. First of all: there are many different styles of OO, some more cumbersome than others, some so far removed from "classic OOP principles" that it takes effort to see how are they related. It's utterly useless to talk about "OOP style" as if it was a well defined, canonical set of rules - because it's not. Second…

To be clear, "closures" are merely an implementation of lamdbas which were invented in the 30s. I wouldn't mention it except you're trying to shame someone for not "knowing" that Smalltalk beat Haskell to the punch despite both of them borrowing from a much richer history.

To drive the point home, you can implement lamdbas (and thus Haskell) without using closures. In fact, this is easy in a pure language since bindings are static. One way to do this is to compile the language into a basis of combinators like SKI. These no longer have any notion of binding so we don't need closures. Likewise, you could compile it into a categorical semantics and maybe implement this on FPGAs—again, no need for closures.

Lamdbas are merely a syntax and theory. Closures are merely one interpretation given a Von Neumann machine.

Re: Is JavaScript getting worse?

#96
post #92
post #71

Earlier quoted context omitted.

> 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

To whoever downvoted me, am I wrong? Please explain.

Most of the time downvoting stands for 'Your comment hurts my feelings.'

This comment will be very light gray ;D

Re: Is JavaScript getting worse?

#97
post #91

Earlier quoted context omitted.

>FP as I understand it doesn't much oppose imperative or even most of OO I think this is definitely true, if you take 'oppose' as 'incompatible'. If we look the design concept and plot them, there will be axes, and I think this is what we'll see. >* Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that That's also true, but it's not an argument against th…

My point is merely that the benefits of are gained using essentially nothing more than real ADTs and yet are almost always bundled with harmful other things in practice. FP can include these core ideas nicely, much like how monads include imperative ideas nicely, by focusing on what composes well.

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#.

Re: Is JavaScript getting worse?

#98
post #75

Earlier quoted context omitted.

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)

I see it the other way--prototype OO was given the blessing of the Creators of the language back in the mid 90s when it was created.

Though the people who 'get' prototypes swear that they're the greatest paradigm ever you will still get a huge amount of people coming in from other languages which find the prototype chain awkward and prefer to think in complex class hierarchies.

These people who choose to create their abstractions out of classes are in no way 'wrong.' To each their own.

Adding `class` syntactic sugar is just standardizing on something which many people already do every day.

Re: Is JavaScript getting worse?

#100
post #91

Earlier quoted context omitted.

My point is merely that the benefits of are gained using essentially nothing more than real ADTs and yet are almost always bundled with harmful other things in practice. FP can include these core ideas nicely, much like how monads include imperative ideas nicely, by focusing on what composes well.

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 breaks things badly often) then you basically have (badly typed) ML modules with open recursion.

The open recursion (a.k.a. late binding) bit is probably the most interesting thing but you can play with it in Typed LC just fine. It's just another form of recursion.

Post reply on HN