My first post seemed to disregard tho concept of deminishing returns. I do think their is a limit but that isn't what I'm seeing with Typescript. My initial return is surely beyond reasonable, but that doesn't the end result isn't.
Many would probably consider the return on functional languages to have a demished return, especially now that so much has been brought into our more frequented languages. I straddle that fence as I have yet to dive deep into one.
But if we had a company push to switch to Haskell with a few developer buy-in, I would not be complaining about the struggle it puts me in to learn those languages.
Many would probably consider the return on functional languages to have a diminished return, especially now that so much has been brought into our more frequented languages.
Again that is another one of those fallacies - functional programming isn't about the presence of features but sometimes the absence of features and more to the point an adjustment in thinking.
While OO is supposed to be about class, responsibility and collaborator functional programming is about solving problems through data transformation.
From that perspective learning a new paradigm in a multi-paradigm setting is problematic because of the familiarity trap - you will always tend towards familiar patterns of thinking unless the constraints of a single paradigm force you to change your thinking. This is most dramatically reflected in the Scala community - teams using Scala as "a better Java" who have no hope of understanding/maintaining code written by the "I'd rather be working in Haskell" teams.
I found the easiest way to learn functional programming was through something like the Erlang MOOC (simply because you didn't have to to worry about types, type classes, laziness etc.) and later the OCaml MOOC for statically typed functional programming. (In the absence of those Learn Functional Programming with Elixir might be worth it).
But if we had a company push to switch to Haskell with a few developer buy-in, I would not be complaining about the struggle it puts me in to learn those languages.
That's not how it works from what I've seen. Typically the leadership of an organization is already convinced that a particular language is their "secret weapon" and then they hire people already competent with it or who show enough promise to be successfully trained in it.
Unfortunately this familiarity trap is the driving force around user interface design. Due to familiarity we got C, C++, Java, C#, ORM, Typescript.
And while typically the language is chosen early on and the company forms around it, the context here is with Typescript and this very much can come through as a push onto the majority of existing devs (hiring to Typescript for replacement of those who choose to leave). My example of Haskell was not realistic but used as it is my parallel to what javascript devs would be going through.
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.
Very good points.
Thank you!
My first post seemed to disregard tho concept of deminishing returns. I do think their is a limit but that isn't what I'm seeing with Typescript. My initial return is surely beyond reasonable, but that doesn't the end result isn't.
Many would probably consider the return on functional languages to have a demished return, especially now that so much has been brought into our more frequented languages. I straddle that fence as I have yet to dive deep into one.
But if we had a company push to switch to Haskell with a few developer buy-in, I would not be complaining about the struggle it puts me in to learn those languages.
Again that is another one of those fallacies - functional programming isn't about the presence of features but sometimes the absence of features and more to the point an adjustment in thinking.
While OO is supposed to be about class, responsibility and collaborator functional programming is about solving problems through data transformation.
From that perspective learning a new paradigm in a multi-paradigm setting is problematic because of the familiarity trap - you will always tend towards familiar patterns of thinking unless the constraints of a single paradigm force you to change your thinking. This is most dramatically reflected in the Scala community - teams using Scala as "a better Java" who have no hope of understanding/maintaining code written by the "I'd rather be working in Haskell" teams.
I found the easiest way to learn functional programming was through something like the Erlang MOOC (simply because you didn't have to to worry about types, type classes, laziness etc.) and later the OCaml MOOC for statically typed functional programming. (In the absence of those Learn Functional Programming with Elixir might be worth it).
That's not how it works from what I've seen. Typically the leadership of an organization is already convinced that a particular language is their "secret weapon" and then they hire people already competent with it or who show enough promise to be successfully trained in it.
Unfortunately this familiarity trap is the driving force around user interface design. Due to familiarity we got C, C++, Java, C#, ORM, Typescript.
And while typically the language is chosen early on and the company forms around it, the context here is with Typescript and this very much can come through as a push onto the majority of existing devs (hiring to Typescript for replacement of those who choose to leave). My example of Haskell was not realistic but used as it is my parallel to what javascript devs would be going through.