>> ... programming in TypeScript every day.
That explains why OP got depressed, considered quitting the industry and then switched to F#. If I keep using TypeScript, I might just snap and switch to COBOL.
That explains why OP got depressed, considered quitting the industry and then switched to F#. If I keep using TypeScript, I might just snap and switch to COBOL.
Maybe not this person's case, I wouldn't be too surprised if someone has another reason, but I seriously haven't heard anyone else with a strong opinion against typescript founded upon any other context. I could probably google around for other reasons.
That sounds kind of like saying, "the vast majority of people with cilantro in their burritos like cilantro."
But in general, yeah, it's kind of like that saying :)
Perhaps this leads to a different coding styles & expectations. The former end up with a preference for strong typing. Perhaps their coding style also depends on that.
The latter don't seem to find types to be a source of bugs.
Like early childhood experiences, each programmer I've discussed the subject with seems to have their own unique professional experience that has molded their opinions. It's less a religion and more a coping mechanism for bad experiences.
TypeScript gives an illusion of added productivity and safety but when you actually look at results, bug density is exactly the same as JavaScript.
As a TS developer, most of your time is spent on catering to the compiler's complaints, but doing so doesn't actually yield any benefits in terms of producing high quality software.
TS and TSLint are bandaid solutions which don't address the root problems behind what makes code bad (which 99% of the time comes down to bad design/architecture). TS simply cannot prevent bad design/architecture - It can only formalize it.
It's nice to have linted code with everything typed and statically locked into place but that means very little in terms of actual code quality.
Weak typing and dynamism just don't go well together, but other combinations are fine. Strong dynamic typing can lead to an "exploratory" approach to coding that looks a bit like what the author describes except that you can do it in such a way that your program compiles and runs the whole time you are fleshing it out, which is nice.
I find this sort of exploratory programming to be by far the most productive available in a research/prototyping mode. I do think the model falls down a bit when multiple programmers are involved, and in production. You could argue this is a feature though, as it is strong incentive to not ship the prototype ...
I mean, I started with Pascal, then C and C++, then PHP, then Ruby then C# and some Java, then Scala, then JavaScript, and now Elixir and TypeScript. Of all those, I like TypeScript the best (barring the NPM / deployment / transpilation / packaging mess, that is). I mean, I like it the best by far. It combines functional with OO much like Scala set out to do, but in a much simpler and more accessible way. I really love it, I think in its structures. All JS I write feels like TypeScript. Even a lot of the Elixir I write (for better or worse) feels like TypeScript with a funny syntax.
I now feel like structural typing is the big missed opportunity of most statically typed languages. The fact that I can define a type simply by writing, say, an object literal, continues to make my day.
let a = { name: "Pete", age: 6 };
a.nmae = 7; // type error!
a = { nmae: "Mike", age: 7 }; // type error!
function moo() {
return { name: "Pete", age: 6 };
}
const a = moo();
a.+---------------------+
|name string |
|age number |
+---------------------+
I'm not claiming any of this is new. I mean truth is I haven't seen any Haskell or F# or Scala code that does this, but I bet that's just my limited exposure to functional languages. I've heard these languages are pretty powerful, so sorry if I insulted your cult there :-)
Still, I've used no other language that enables this ability to write code the way one would write dynamically typed code - head-first, straight down into the operational stuff, and finetune the data structures as we go along - while still getting type checking and all the confidence and tool support that comes with it for free.
I agree with the OP. TypeScript is my cult. <3
As compatible as it is, there is definitely a lot of friction/awkwardness around type-casting JSON objects to typed objects within a statically typed programming language; there is an impedance mismatch. It's not as awkward as trying to type cast objects designed under one type system to a different type system (e.g. SOAP APIs) but it's still really awkward.
The impedance mismatch goes away completely if you use a dynamically typed language like JavaScript. For example, JSON produced by a python program can be parsed by a JavaScript/Node.js program without any issues.
The root reason why types are bad is because they're opinionated. There is no absolute right way to type something; and because of this, it's not correct to force other projects which interface with your project to adhere to your type definitions.