4 ms·

Alternative title: how to write unmaintainable, unreadable code that nobody understands and cannot be fixed or modified without introducing compiler errors for

Alternative title: how to write unmaintainable, unreadable code that nobody understands and cannot be fixed or modified without introducing compiler errors for code that just works. These features are why I don’t like Typescript. It is too complicated.

BenoitP 2y ago
> It is too complicated. I wouldn't say this. It can bring complications, yes: but only because like a lot of expressive tools people will over-engineer things with them (probably like this sentence) To me, Typescript saved JavaScript from under-constraining. It's bringing me some peace of mind.
ngruhn 2y ago
I think using more descriptive type parameter names (instead of just T, K, F, …) already goes half way reducing the complexity.
- mrkeen 2y ago
  OK so what would you call them? TypeParam1, TypeParam2, ... ?
  - code_biologist 2y ago
    A common convention I've seen is using T at the start of a type parameter, [1] for example. TKey, TData, TError, TSuccessCallback, etc. I always liked T at the end, but I've not seen that as often. [1] https://github.com/TanStack/query/blob/59a6d3df3035d6effeaed884f4575b1a0ef8e788/packages/react-query/src/useQuery.ts#L15-L23 https://github.com/TanStack/query/blob/59a6d3df3035d6effeaed...
    - toastedwedge 2y ago
      Seems apt that the error for a generic type would (and should) be spelled "terror."
epolanski 2y ago
There's so many things wrongs in your post imho: 1) the destructive yet not helpful nature of your post. What are better alternatives to write JavaScript than TS? Elm and flow are not. 2) not realizing that any powerful type system (or language) has advanced concepts, this isn't exclusive to TypeScript 3) Not realizing this is mostly a tool for library authors to provide better inference to API consumers 4) Last but not least, 99% of TypeScript users can't even tell what a mapped type is (it's in the docs) nor define it or say when to use it, people don't even bother to read the docs fundamentals so attitudes like yours are unsurprising 5) Typescript is verbose, but very simple to follow and read if you know the basics. It's unmaintainable only because people don't bother to master any topic
- toolslive 2y ago
  > What are better alternatives to write JavaScript than TS? Elm and flow are not. Why do you want to write javascript ? Most self-respecting programming languages have a javascript backend (Let's list a few pretty ones: Rust, OCaml, Haskell). There's no need to manually generate javascript and you can treat it like you would treat assembly language: something you don't want to touch 99% of the time.
  - epolanski 2y ago
    None of the languages you list allow a small team to move ahead web, native and server code with ease. None of the languages you list make hiring easy, at all. None of the languages you list are easy to setup across platforms/cloud environments. None of the languages you list make handling a monorepo simple. I am most certain (I know Haskell, lisps, Elm, C, Java, Scala) that there are different good tools for different use cases, but I ain't picking any of those 9 times out of 10 without a solid reason to do so in the context of web development.

BenoitP 2y ago

> It is too complicated. I wouldn't say this. It can bring complications, yes: but only because like a lot of expressive tools people will over-engineer things with them (probably like this sentence) To me, Typescript saved JavaScript from under-constraining. It's bringing me some peace of mind.

ngruhn 2y ago

I think using more descriptive type parameter names (instead of just T, K, F, …) already goes half way reducing the complexity.

mrkeen 2y ago
OK so what would you call them? TypeParam1, TypeParam2, ... ?
- code_biologist 2y ago
  A common convention I've seen is using T at the start of a type parameter, [1] for example. TKey, TData, TError, TSuccessCallback, etc. I always liked T at the end, but I've not seen that as often. [1] https://github.com/TanStack/query/blob/59a6d3df3035d6effeaed884f4575b1a0ef8e788/packages/react-query/src/useQuery.ts#L15-L23 https://github.com/TanStack/query/blob/59a6d3df3035d6effeaed...
  - toastedwedge 2y ago
    Seems apt that the error for a generic type would (and should) be spelled "terror."

epolanski 2y ago

There's so many things wrongs in your post imho: 1) the destructive yet not helpful nature of your post. What are better alternatives to write JavaScript than TS? Elm and flow are not. 2) not realizing that any powerful type system (or language) has advanced concepts, this isn't exclusive to TypeScript 3) Not realizing this is mostly a tool for library authors to provide better inference to API consumers 4) Last but not least, 99% of TypeScript users can't even tell what a mapped type is (it's in the docs) nor define it or say when to use it, people don't even bother to read the docs fundamentals so attitudes like yours are unsurprising 5) Typescript is verbose, but very simple to follow and read if you know the basics. It's unmaintainable only because people don't bother to master any topic

toolslive 2y ago
> What are better alternatives to write JavaScript than TS? Elm and flow are not. Why do you want to write javascript ? Most self-respecting programming languages have a javascript backend (Let's list a few pretty ones: Rust, OCaml, Haskell). There's no need to manually generate javascript and you can treat it like you would treat assembly language: something you don't want to touch 99% of the time.
- epolanski 2y ago
  None of the languages you list allow a small team to move ahead web, native and server code with ease. None of the languages you list make hiring easy, at all. None of the languages you list are easy to setup across platforms/cloud environments. None of the languages you list make handling a monorepo simple. I am most certain (I know Haskell, lisps, Elm, C, Java, Scala) that there are different good tools for different use cases, but I ain't picking any of those 9 times out of 10 without a solid reason to do so in the context of web development.