> "this trend is subjective dogma not objective value"
Ironically, the author own phrasing is not objective and somewhat hypocritical. S/He described the use of Typescript as "selling out and the Microsoft way of doing things". S/He's trying to leverage anti-Microsoft sentiment to boost her/his argument. Feels more like a smear campaign then an objective opinion.
How's that old saying go? Fool me once, shame on you. Fool me 47 times, shame on me.
I've never seen a person who actually is familiar with Typescript say anything negative about it, and it has huge uptake in the open source community.
Ref Book: The New Kingmakers
"It’s hard to feel too sorry for SOAP’s creators, however — particularly if what one Microsoft developer told Tim O’Reilly is true: “It was actually a Microsoft objective to make [SOAP] sufficiently complex that only the tools would read and write this stuff,” he explained, “and not humans.”"
I guess my take is overall they earned high marks from the dev community despite whatever misses they may have had over the years.
I was addressing the phrasing and lack of objectivity of the Typescript statement. At no point did I discuss the merits of anti MS sentiment.
Yes I agree with you that MS has burnt people in the past. At the same time it's not binary so 100% of MS != evil.
also, even though the MS anti-sentiment didn't pop up out of nowhere, it's not relevant in the static-vs-dynamic typing discussion...
Unfortunately I can't hear that song anymore without picturing the opening scenes of CSI Miami.
If you’re working on a large, unstructured project that you’re trying to refactor, you’re problem probably isn’t with the types. It’s that the people working on it used types as a crutch so that they thought it was okay to write classes that were thousands of lines long with giant methods that are impossible to make sense of.
The interview question I’ve been asking lately is about object design. I tell them not to put things into one big method—that it needs to be readable for junior devs. They always ignore me. The ones who struggle the most are the ones who try to do it in a staticly types language (which I’m sure you agree is crazy to use in an interview for a tiny problem). Their mental model forces them to think about types first, and they then can’t think about anything other than that and just making the thing work.
If you aim to keep your objects and you methods small enough that anyone can read them and make sense of them, then you don’t need static types and refactoring becomes easy. There are plenty of developers of mediocre talent who never use types and are able to build huge features and projects quickly and with high maintainability and flexibility because they write code that sticks to good object oriented design principles.
A class I work on regularly has become so big that everyone, especially the more senior, more talented engineers at my company are too afraid to touch, let alone try to refactor. It’s stayically typed.
Your one big method interview example - so you think had they not been able to reply on static typing for refactoring in their previous work they would have gravitated toward cleaner code? That just seems wildly speculative as a counter to me. A fair amount of projects don't get the refactoring they need in the first place, so developers working on those don't get the experience to begin with. Developers who write large functions often have reasons like "if you use multiple functions you have to jump around to see whats going on." If i'm attacking a straw man, its unintentional.
Anyway having unit tests in a projects would encourage smaller units more, you can have tests easily in static languages - so you get the best of both worlds - smaller units and the ease static typing brings to refactoring.
The go-to sources on writing good code in c#/java land are proponents of keeping methods and classes small as well - that's where i learnt from. (Not to start any wars on over use of design patterns)
Your comment assuming we'd all agree choosing a static language is a bad choice for a small example is also very strange to me. When i'm under pressure id go with what i'm most familiar with, likely C#. Though, with JS and PHP being my dynamic alternatives, i may just be sounding like a very bad programmer to you ;)
I've seen plenty of very long functions in javascript (and c#), and dont think it has anything to do with static typing.
I imagine most people using vanilla JS have significant amounts of objects memorized.
However, in my experience, once a code base is big enough, you can open almost any file and find documentation that's out of date, incorrectly copy-pasted, or some other major issue. TS, on the other hand, at least forces you to stay correct, which is ultimately what convinced me to switch.
Which are a form of type annotations. Case in point: the typescript compiler can actually parse those, in .js files, and yield appropriate warnings on errors. See the //@ts-check annotation.
The author strikes me as someone who has a very narrow breadth of experience.
There are trade-offs between choosing typed and non-typed languages. It’s not wrong to prefer one or the other. But to accuse the other side of selling out or not having objective reasons for the choice is naïve.
Don’t assume that everyone who disagrees with you is stupid. It only demonstrates that you lack an important skill of critical thinking: the ability to consider others’ perspectives and understand them.
Wow, biased much. I love JavaScript and ES6. But anything that I work with a team on or expect to live beyond a month or so, I love types for. Making a large refactor without types is the wild west. Types help provide structure/understanding about the data flowing through your system. And if you need to eject you can with Any. I used to prefer pure JS (or Python), certainly quicker to prototype, but also more difficult to grow and maintain. Tradeoffs in both directions. Such an amateur statement makes me question the rest of the document.