I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
Thanks for mentioning the history. I already mentioned that originally TS had classes earlier than JS had them, that is true. Also I don't see a big difference between using class-based and not classed based OOP. Class is just definition of some class of objects, you can make it by closure sure, but fundamentally there is no difference, as OOP is mostly about encapsulation, and this is Kay way of thinking. The second school teaches that OOP is about inheritance and classes, and this goes from C++ and Stroustrup. I will not argue about definition here.
This article was showing that the same OOP you can do in JS and in TS, so how you can state that TS is more object oriented if there is no real difference? Latest years shows that TS is going more into FP because that is what community demands. You can write TS without any class, and as I mentioned I am doing that successfully many years. I said FP is little harder as FP in JS has dynamic origins, it is based on LISP. Adding types to that is not easy task, but I think TS made a great progress with that.
Also about your last two links, it has nothing to TS, you can do function based OOP in TS. But why? I don't see a point in trying to avoid classes if you do OOP, I mean the only reason to avoid them is more like allergy after being too much exposed to Java. Creating objects by constructors being simple function is ok, but in the end of the day we achieve the same result. Even more "class" is just syntax sugar over setting prototype, yes the famous JS prototype which nobody wanted to use.
I have nothing against doing OOP without classes, but saying that it is something better is overstatement, they are two sides of the same coin.
And also pay attention I didn't write article "TypeScript the FP language", and this is what you are trying to argue with. I said that TS is multi-paradigm as JS is.
Also I don't see a big difference between using class-based and not classed based OOP.
In class-based languages the object's "membership" is static - i.e. an object cannot change "classes" during it's lifetime. In JavaScript an object's capabilities can be augmented after construction - effectively changing its "class".
DCI (Data Context Interaction) for example needs objects to dynamically present roles while not changing their identity. Static class membership of mainstream class-based OO languages gets in the way, requiring workarounds. This lead to trygve.
So whether or not you see "lifetime class membership" as a feature for objects depends on your particular needs.
as OOP is mostly about encapsulation, and this is Kay way of thinking.
Erlang (and independently the Actor model) uses a shared-nothing asynchronous message passing system. So data-hiding isn't an objective but simply the result of sharing nothing.
Other than that many FP languages don't care about data-hiding but simply respect the notion of a opaque data type when necessary. As Rich Hickey observed:
"And if you have a notion of “private”, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn’t."
So encapsulation may not be as desirable in all contexts, possibly not even in most.
so how you can state that TS is more object oriented if there is no real difference?
By taking the position that TS makes a functional style harder to practice compared to an object-oriented style. Just because it doesn't stop determined individuals doesn't weaken the claim. Typing OO code in TypeScript is fundamentally easier than typing functional code (which is also less awkward to type in a dedicated FP language). Given that JavaScript isn't statically typed it doesn't discriminate either way.
In a world with TypeScript but without JavaScript I doubt something like JavaScript Allongé would have ever been written.
Adding types to that is not easy task, but I think TS made a great progress with that.
TypeScript's priority was to type JavaScript's imperative aspects - so the later additions feel bolted on and awkward.
but saying that it is something better is overstatement,
I didn't imply it was better. Some would say it is better because it eliminates inheritance, forcing the use of composition. The point is that there are different ways of practicing object-orientation - class-based is just one of them. JavaScript's OO was inspired by Self.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for mentioning the history. I already mentioned that originally TS had classes earlier than JS had them, that is true. Also I don't see a big difference between using class-based and not classed based OOP. Class is just definition of some class of objects, you can make it by closure sure, but fundamentally there is no difference, as OOP is mostly about encapsulation, and this is Kay way of thinking. The second school teaches that OOP is about inheritance and classes, and this goes from C++ and Stroustrup. I will not argue about definition here.
This article was showing that the same OOP you can do in JS and in TS, so how you can state that TS is more object oriented if there is no real difference? Latest years shows that TS is going more into FP because that is what community demands. You can write TS without any class, and as I mentioned I am doing that successfully many years. I said FP is little harder as FP in JS has dynamic origins, it is based on LISP. Adding types to that is not easy task, but I think TS made a great progress with that.
Also about your last two links, it has nothing to TS, you can do function based OOP in TS. But why? I don't see a point in trying to avoid classes if you do OOP, I mean the only reason to avoid them is more like allergy after being too much exposed to Java. Creating objects by constructors being simple function is ok, but in the end of the day we achieve the same result. Even more "class" is just syntax sugar over setting prototype, yes the famous JS prototype which nobody wanted to use.
I have nothing against doing OOP without classes, but saying that it is something better is overstatement, they are two sides of the same coin.
And also pay attention I didn't write article "TypeScript the FP language", and this is what you are trying to argue with. I said that TS is multi-paradigm as JS is.
In class-based languages the object's "membership" is static - i.e. an object cannot change "classes" during it's lifetime. In JavaScript an object's capabilities can be augmented after construction - effectively changing its "class".
DCI (Data Context Interaction) for example needs objects to dynamically present roles while not changing their identity. Static class membership of mainstream class-based OO languages gets in the way, requiring workarounds. This lead to trygve.
So whether or not you see "lifetime class membership" as a feature for objects depends on your particular needs.
Erlang (and independently the Actor model) uses a shared-nothing asynchronous message passing system. So data-hiding isn't an objective but simply the result of sharing nothing.
Other than that many FP languages don't care about data-hiding but simply respect the notion of a opaque data type when necessary. As Rich Hickey observed:
"And if you have a notion of “private”, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn’t."
So encapsulation may not be as desirable in all contexts, possibly not even in most.
By taking the position that TS makes a functional style harder to practice compared to an object-oriented style. Just because it doesn't stop determined individuals doesn't weaken the claim. Typing OO code in TypeScript is fundamentally easier than typing functional code (which is also less awkward to type in a dedicated FP language). Given that JavaScript isn't statically typed it doesn't discriminate either way.
In a world with TypeScript but without JavaScript I doubt something like JavaScript Allongé would have ever been written.
TypeScript's priority was to type JavaScript's imperative aspects - so the later additions feel bolted on and awkward.
I didn't imply it was better. Some would say it is better because it eliminates inheritance, forcing the use of composition. The point is that there are different ways of practicing object-orientation - class-based is just one of them. JavaScript's OO was inspired by Self.