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…
Is JavaScript getting worse?
91–100 of 117 posts
Re: Is JavaScript getting worse?
#92Earlier 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
Re: Is JavaScript getting worse?
#93Earlier 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.
Re: Is JavaScript getting worse?
#94Earlier 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?
#95Earlier 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 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?
#96Earlier 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.
This comment will be very light gray ;D
Re: Is JavaScript getting worse?
#97Earlier 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.
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?
#98Earlier 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)
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?
#99When are proper tail calls expected to show up? Looks pretty bleak.
Re: Is JavaScript getting worse?
#100Earlier 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#.
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.