6 ms·

Same here, I hate it when I land in a TypeScript codebase where they followed "clean code" and "best practices" and have nice OOP abstractions everywhere.. its

Same here, I hate it when I land in a TypeScript codebase where they followed "clean code" and "best practices" and have nice OOP abstractions everywhere.. its always a kludgy monstrosity that yields everything but actual agility or performance. The whole "lets use classes in JavaScript" movement makes me very sad. Its as if today's web developers are now rediscovering the 90's and all the mistakes that were made back when OOP was the new shiny thing. I get WAY more annoyed fighting with TypeScript's type-system than fixing the rare runtime type error, which is usually trivial to find anyways. This all feels like a very superficial and inefficient way to achieve correctness. The real hard to find bugs come from state and complexity, both of which are completely ignored by static type systems. Instead I see the exact opposite: the new shiny typed abstractions introduce so much state and complexity that any advantage gained by having static types is lost there. I probably sound very pessimistic here; the older I grow the more I appreciate Alan Kay's quote about the internet and the web for being so damn spot-on.

TAForObvReasons 10y ago
The computer industry is the only industry that is more fashion-driven than women's fashion. -- Larry Ellison These cycles come and go. Sometimes static typing is hot, sometimes dynamic typing is hot. Best bet for pragmatic people is to figure out what works for you and run with it.
- qwertyuiop924 10y ago
  Indeed. But I'd quote Kay, not Ellison, myself. Personally, I wouldn't trust Ellison further than I can throw him.
RyanCavanaugh 10y ago
It's important to not conflate static typing with OOP. If you think about static typing only in terms of OOP, of course you're not going to like it - classes are not the right abstraction for many problems. The TypeScript compiler (which is written in TS) itself uses zero classes. There's no need to use classes to get static typing. If you're writing TS the "right way", you write the JavaScript you would have written anyway, and add type annotations to create contracts and descriptions of behavior.
- shados 10y ago
  TypeScript has an okay type system, but it has a very "C#"feel to it. I don't mean from a technical point of view, but the way its advertised, the way its documented, the language used in the terminology, and obviously, the company behind it. So of course, when you give TypeScript to someone who doesn't have a strong "normal" JavaScript background, they'll jump straight in what they are comfortable with and go full enterprise Java on it. Note that even vanilla ES6 had this problem, just to a lesser extent. All languages have shit like that... JavaScript itself does (we're just used to "the good parts" after so many years, but it took a long time. The fact TypeScript provides some of those construct doesnt mean we need to use it, but it means less experienced teams will. I'll never join a company that uses TypeScript unless I get to see the code base first.
  - cakoose 10y ago
    > I'll never join a company that uses TypeScript unless I get to see the code base first. That seems reasonable. But wouldn't the same thing apply to Javascript? Terrible Javascript code bases are very common.
    - shados 10y ago
      Generally the terrible JavaScript is stuff you don't have to argue until you're blue in the face to avoid. A lot of people have bad JS code base, but they know they are bad and are trying to do better. That's fine by me. For this particular stuff, if a team is really into the whole OOP/classes things, it's not like a small feature like arrow functions vs not, or semi-colon vs not... it will dictate the entire architecture of the entire code base, and it's easy to detect, so why not?
  - KirinDave 10y ago
    > TypeScript has an okay type system, but it has a very "C#"feel to it. I don't mean from a technical point of view, but the way its advertised, the way its documented, the language used in the terminology, and obviously, the company behind it. It has some very un-C# like features: https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... I am always surprised when people in JS-land say they don't like types when every major framework then goes on to recreate 80% of the framework of types rather than work in a truly prototype-oriented world. > I'll never join a company that uses TypeScript unless I get to see the code base first. Given the way those sorts of things work, you're basically saying you don't want to work with typescript because someone might use a feature you feel uncomfortable with. That's good to get out of the way up front, but it also projects the image you have a huge chip on your shoulder and assume everyone else is an idiot who doesn't understand things as well as you do. Wouldn't you like to work at a place where you discover something new? I am sick to death of being the subject matter expert, myself.
sotojuan 10y ago
It's interesting that TypeScript often gets lumped into "OOP" when a few functional projects like RxJS and Cycle use it. Are their codebases also OOP?
- bsimpson 10y ago
  Actually, yes, TypeScript uses OOP patterns like classes and interfaces: https://github.com/ReactiveX/rxjs/blob/master/src/Observable.ts https://github.com/ReactiveX/rxjs/blob/master/src/Observable... But they also use the pipeline operator (::) to chain together methods in a way that's effectively functional.
  - sotojuan 10y ago
    Interesting! More interesting is that apparently the TS compiler itself uses no classes. I just think jeremiep is conflating static typing with Java-style OOP and "design patterns".
- addicted 10y ago
  I think typescript development is driven more by functional languages, than OOP languages. However, they do provide some syntactic sugar for OOP, which is useful if you have a JS codebase that is using OOP, because if nothing else, it provides a standardized method of creating objects and classes. Unfortunately, because most devs are comfortable only with OOP and since typescript is amongst the easiest ways to do OOP in JS, a lot of Typescript code in the wild tends to be OOP heavy.
- FrancoDiaz 10y ago
  The Typescript compiler (written in Typescript) uses no classes.
- qwertyuiop924 10y ago
  TS has some functional leanings, but there are probably a good many users from enterpriseland who see the "class" keyword, and have their eyes glaze over with the assumption that they already know everything, as the continue to create monstrosities in the name of best practices. A little common sense goes a long way.
KirinDave 10y ago
> The real hard to find bugs come from state and complexity, both of which are completely ignored by static type systems. Instead I see the exact opposite: the new shiny typed abstractions introduce so much state and complexity that any advantage gained by having static types is lost there. That's just not true. If you model your state and its transitions as types, then it's entirely the case that your type system can help you out. It can also force you to write down an explicit & precise guide to said system, which will help readers. > The real hard to find bugs come from state and complexity, No one argues that this is the case, but what's key to understand is that people still make the stupid mistakes. People like you and me. I've got over a decade of experience, I've shipped code in common lisp, javascript, ruby, python... you name it in the who's-who' of dynamic languages and odds are I've shipped code in it. And I can STILL make silly little type errors. I'm tired of this collective fiction that we're all so awesome that we don't make those errors. Removing those is important. It lets me think more about the interesting parts of the code and trust the computer to do the tedious bits for me. That's what automation is all about, isn't it?

TAForObvReasons 10y ago

The computer industry is the only industry that is more fashion-driven than women's fashion. -- Larry Ellison These cycles come and go. Sometimes static typing is hot, sometimes dynamic typing is hot. Best bet for pragmatic people is to figure out what works for you and run with it.

qwertyuiop924 10y ago
Indeed. But I'd quote Kay, not Ellison, myself. Personally, I wouldn't trust Ellison further than I can throw him.

RyanCavanaugh 10y ago

It's important to not conflate static typing with OOP. If you think about static typing only in terms of OOP, of course you're not going to like it - classes are not the right abstraction for many problems. The TypeScript compiler (which is written in TS) itself uses zero classes. There's no need to use classes to get static typing. If you're writing TS the "right way", you write the JavaScript you would have written anyway, and add type annotations to create contracts and descriptions of behavior.

shados 10y ago
TypeScript has an okay type system, but it has a very "C#"feel to it. I don't mean from a technical point of view, but the way its advertised, the way its documented, the language used in the terminology, and obviously, the company behind it. So of course, when you give TypeScript to someone who doesn't have a strong "normal" JavaScript background, they'll jump straight in what they are comfortable with and go full enterprise Java on it. Note that even vanilla ES6 had this problem, just to a lesser extent. All languages have shit like that... JavaScript itself does (we're just used to "the good parts" after so many years, but it took a long time. The fact TypeScript provides some of those construct doesnt mean we need to use it, but it means less experienced teams will. I'll never join a company that uses TypeScript unless I get to see the code base first.
- cakoose 10y ago
  > I'll never join a company that uses TypeScript unless I get to see the code base first. That seems reasonable. But wouldn't the same thing apply to Javascript? Terrible Javascript code bases are very common.
  - shados 10y ago
    Generally the terrible JavaScript is stuff you don't have to argue until you're blue in the face to avoid. A lot of people have bad JS code base, but they know they are bad and are trying to do better. That's fine by me. For this particular stuff, if a team is really into the whole OOP/classes things, it's not like a small feature like arrow functions vs not, or semi-colon vs not... it will dictate the entire architecture of the entire code base, and it's easy to detect, so why not?
- KirinDave 10y ago
  > TypeScript has an okay type system, but it has a very "C#"feel to it. I don't mean from a technical point of view, but the way its advertised, the way its documented, the language used in the terminology, and obviously, the company behind it. It has some very un-C# like features: https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... I am always surprised when people in JS-land say they don't like types when every major framework then goes on to recreate 80% of the framework of types rather than work in a truly prototype-oriented world. > I'll never join a company that uses TypeScript unless I get to see the code base first. Given the way those sorts of things work, you're basically saying you don't want to work with typescript because someone might use a feature you feel uncomfortable with. That's good to get out of the way up front, but it also projects the image you have a huge chip on your shoulder and assume everyone else is an idiot who doesn't understand things as well as you do. Wouldn't you like to work at a place where you discover something new? I am sick to death of being the subject matter expert, myself.

sotojuan 10y ago

It's interesting that TypeScript often gets lumped into "OOP" when a few functional projects like RxJS and Cycle use it. Are their codebases also OOP?

bsimpson 10y ago
Actually, yes, TypeScript uses OOP patterns like classes and interfaces: https://github.com/ReactiveX/rxjs/blob/master/src/Observable.ts https://github.com/ReactiveX/rxjs/blob/master/src/Observable... But they also use the pipeline operator (::) to chain together methods in a way that's effectively functional.
- sotojuan 10y ago
  Interesting! More interesting is that apparently the TS compiler itself uses no classes. I just think jeremiep is conflating static typing with Java-style OOP and "design patterns".
addicted 10y ago
I think typescript development is driven more by functional languages, than OOP languages. However, they do provide some syntactic sugar for OOP, which is useful if you have a JS codebase that is using OOP, because if nothing else, it provides a standardized method of creating objects and classes. Unfortunately, because most devs are comfortable only with OOP and since typescript is amongst the easiest ways to do OOP in JS, a lot of Typescript code in the wild tends to be OOP heavy.
FrancoDiaz 10y ago
The Typescript compiler (written in Typescript) uses no classes.
qwertyuiop924 10y ago
TS has some functional leanings, but there are probably a good many users from enterpriseland who see the "class" keyword, and have their eyes glaze over with the assumption that they already know everything, as the continue to create monstrosities in the name of best practices. A little common sense goes a long way.

KirinDave 10y ago

> The real hard to find bugs come from state and complexity, both of which are completely ignored by static type systems. Instead I see the exact opposite: the new shiny typed abstractions introduce so much state and complexity that any advantage gained by having static types is lost there. That's just not true. If you model your state and its transitions as types, then it's entirely the case that your type system can help you out. It can also force you to write down an explicit & precise guide to said system, which will help readers. > The real hard to find bugs come from state and complexity, No one argues that this is the case, but what's key to understand is that people still make the stupid mistakes. People like you and me. I've got over a decade of experience, I've shipped code in common lisp, javascript, ruby, python... you name it in the who's-who' of dynamic languages and odds are I've shipped code in it. And I can STILL make silly little type errors. I'm tired of this collective fiction that we're all so awesome that we don't make those errors. Removing those is important. It lets me think more about the interesting parts of the code and trust the computer to do the tedious bits for me. That's what automation is all about, isn't it?