Clean code is a concept that was born from a shit ton of practical experience... Uncle Bob has what? 40 years experience in the field? And it's not like he's alone, or that the concept of clean code wasnt adopted and put in to practice for the past 14 years...
You can claim all you want... No junior developer is going to understand what your JSDoc comments really mean, or know how to use it properly themselves. With typescript they have no choice... But more importantly, they don't have to care at all because Typescript does type inference automatically and it will just tell them what they're doing wrong if they try to assign the wrong type to a variable or function :B no understanding JSDoc required and a bunch of other tools and VS code plugins that you need... I have the complete opposite experience than what you claim... The junior devs I have encountered found Typescript very easy to learn and use.
JSDoc, like PHPDoc is archaic, from a century before we had modern type systems and stems from Javadoc which is even more archaic...
I agree, the example you give is a horrible obfuscation of logic that you should not do at all. If someone changes what is returned by one of the functions in your composition and doesnt update the JSDoc for it, Javascript is going to crash in runtime and I would love for you to let a junior dev try to find and fix that runtime error with your function composition. If you work with 10 devs, I guarantee atleast 5 of them are not going to care much about updating code comments when they're writing code. I much prefer devs who try to write clean code, instead of trying to explain their mess with JSDoc.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
I am using JS since TS is just superset of JS, but yes, for typesafety and to avoid a million runtime errors everytime you forget something, I will use TS until something better comes along.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
So you took a decision based on other decisions you made before (learning TS and ignoring vanilla JS as much as possible).
“If the only tool you have is a hammer, you tend to see everything as a nail.”
Taking in mind that TS does not check types at runtime and also knowing the context where you are working on (in this case React), where runtime errors are mostly due to some API error (the backend guy forgot to add some property, the swagger says that in this contract you should get a string but instead you got an integer and so on) you'll face exactly the same amount of runtime errors either using one thing or another but hey, those are your projects, not mine.
The amount of assumptions you make about my work experience with other languages shows how narrow minded you really are.
There are ways to avoid runtime errors from API changes, but i'm sure you have a very strong opinion about those tools as well and frankly I have come to the conclusion that its utterly pointless to discuss these things with you.
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.
Clean code is a concept that was born from a shit ton of practical experience... Uncle Bob has what? 40 years experience in the field? And it's not like he's alone, or that the concept of clean code wasnt adopted and put in to practice for the past 14 years...
You can claim all you want... No junior developer is going to understand what your JSDoc comments really mean, or know how to use it properly themselves. With typescript they have no choice... But more importantly, they don't have to care at all because Typescript does type inference automatically and it will just tell them what they're doing wrong if they try to assign the wrong type to a variable or function :B no understanding JSDoc required and a bunch of other tools and VS code plugins that you need... I have the complete opposite experience than what you claim... The junior devs I have encountered found Typescript very easy to learn and use.
JSDoc, like PHPDoc is archaic, from a century before we had modern type systems and stems from Javadoc which is even more archaic...
I agree, the example you give is a horrible obfuscation of logic that you should not do at all. If someone changes what is returned by one of the functions in your composition and doesnt update the JSDoc for it, Javascript is going to crash in runtime and I would love for you to let a junior dev try to find and fix that runtime error with your function composition. If you work with 10 devs, I guarantee atleast 5 of them are not going to care much about updating code comments when they're writing code. I much prefer devs who try to write clean code, instead of trying to explain their mess with JSDoc.
So, to recap, you'll use TS always instead JS, isn't it?
I am using JS since TS is just superset of JS, but yes, for typesafety and to avoid a million runtime errors everytime you forget something, I will use TS until something better comes along.
So you took a decision based on other decisions you made before (learning TS and ignoring vanilla JS as much as possible).
“If the only tool you have is a hammer, you tend to see everything as a nail.”
Taking in mind that TS does not check types at runtime and also knowing the context where you are working on (in this case React), where runtime errors are mostly due to some API error (the backend guy forgot to add some property, the swagger says that in this contract you should get a string but instead you got an integer and so on) you'll face exactly the same amount of runtime errors either using one thing or another but hey, those are your projects, not mine.
The amount of assumptions you make about my work experience with other languages shows how narrow minded you really are.
There are ways to avoid runtime errors from API changes, but i'm sure you have a very strong opinion about those tools as well and frankly I have come to the conclusion that its utterly pointless to discuss these things with you.