Is then functional programming harder in TS than in JS? Yes it is slightly ...
In my view this statement undermines the title. I would also observe that slightly is an understatement. Functional style TypeScript requires a much better grasp of TypeScript's typing meta-language - to a degree that isn't usually necessary when practicing a class-based object-oriented style (example: Learn Advanced TypeScript).
Once we accept that in TypeScript the class-based object-oriented style is the path of least resistance (according to: "make the right thing easy and the wrong thing hard") I think it is fair to say that TypeScript skews the choice of implementation towards class-based object-orientation much more than JavaScript does.
In Dependency Injection revisited (2018) (Blog post) Mark Seeman juxtaposes F# code against the somewhat equivalent C# code which looks like a verbose mess. Functional-style TypeScript is often reminiscent of that C# mess.
So I don't think that stating that TypeScript favours class-based object-orientation a lot more than JavaScript is too far off the mark. It takes a lot more determination to pursue a functional style in TypeScript than it does in JavaScript.
What's more insidious about this is that TypeScript's perceived OO-ness over JavaScript is taken by the mainstream as further corroboration that class-based object-orientation is the "true software development paradigm" - even when there are hints that we're moving away from OO.
Did you know that original idea of object oriented programming had nothing about inheritance. Alan Kay who had made this term was focusing on encapsulation and message passing.
Original object-orientation dates back to Simula (1962) and Simula 67 had classes and inheritance - i.e. it was class-based. Alan Kay's statement was made in 1998, some 30 years later and identifies Carl Hewitt's Actor Model as his mental model. At OOPSLA '97 he was quoted as saying: "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind" - but it's unclear whether he actually originated the term.
The big issue is that the mainstream currently uses "object-oriented" when they are actually talking about "class-oriented" - i.e. classes being used exclusively to create objects.
However you can work with objects without needing classes:
TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web.
... so class-based object-orientation seems to have always been TypeScript's primary priority.
More to the point with TypeScript you are confined to practicing Guerilla-FP because TypeScript is sanctioned while other more suitable but niche statically typed functional to-JS transpilers are not:
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.
Title ...
... then In article body:
In my view this statement undermines the title. I would also observe that slightly is an understatement. Functional style TypeScript requires a much better grasp of TypeScript's typing meta-language - to a degree that isn't usually necessary when practicing a class-based object-oriented style (example: Learn Advanced TypeScript).
Once we accept that in TypeScript the class-based object-oriented style is the path of least resistance (according to: "make the right thing easy and the wrong thing hard") I think it is fair to say that TypeScript skews the choice of implementation towards class-based object-orientation much more than JavaScript does.
In Dependency Injection revisited (2018) (Blog post) Mark Seeman juxtaposes F# code against the somewhat equivalent C# code which looks like a verbose mess. Functional-style TypeScript is often reminiscent of that C# mess.
So I don't think that stating that TypeScript favours class-based object-orientation a lot more than JavaScript is too far off the mark. It takes a lot more determination to pursue a functional style in TypeScript than it does in JavaScript.
What's more insidious about this is that TypeScript's perceived OO-ness over JavaScript is taken by the mainstream as further corroboration that class-based object-orientation is the "true software development paradigm" - even when there are hints that we're moving away from OO.
Original object-orientation dates back to Simula (1962) and Simula 67 had classes and inheritance - i.e. it was class-based. Alan Kay's statement was made in 1998, some 30 years later and identifies Carl Hewitt's Actor Model as his mental model. At OOPSLA '97 he was quoted as saying: "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind" - but it's unclear whether he actually originated the term.
The big issue is that the mainstream currently uses "object-oriented" when they are actually talking about "class-oriented" - i.e. classes being used exclusively to create objects.
However you can work with objects without needing classes:
and considering:
... so class-based object-orientation seems to have always been TypeScript's primary priority.
More to the point with TypeScript you are confined to practicing Guerilla-FP because TypeScript is sanctioned while other more suitable but niche statically typed functional to-JS transpilers are not:
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.