Hacker News Reader

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.

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.

> 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.

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?

> 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....

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.

I specifically said that I didn't mean from a technical point of view. I know full well about typescript's features :) I generally try to avoid talking about things I haven't tried extensively.

And for your second point, I love to learn something new! But that is specifically something I've had to deal with far too many times already (not just with TypeScript), so it wouldn't be new. And it is quite common these days for companies to show you their code when they get near offer time, or to discuss their architecture and coding philosophy, so I very rarely have surprises on that front anymore. Doesn't mean I don't learn new things. I don't avoid things that haven't burnt me yet. Heck, even if they did, it might be because I didn't do it right. But there's only so many times I can get burnt before I start avoiding certain things :)

> I generally try to avoid talking about things I haven't tried extensively.

I don't mean to press this point too hard, but you feel comfortable offering a dissuasive opinion on something but not "talking about it"? I don't know how to interpret that.

> But that is specifically something I've had to deal with far too many times already (not just with TypeScript), so it wouldn't be new.

I don't know what you mean by this either, I'm sorry.

> And it is quite common these days for companies to show you their code when they get near offer time, or to discuss their architecture and coding philosophy, so I very rarely have surprises on that front anymore.

I certainly think the second half of this is true. I think it's quite rare for companies to actually share real production code in any significant volume, unless of course it's already in the open.

> But there's only so many times I can get burnt before I start avoiding certain things :)

Again... what do you mean? Are you implying that Javascript has burnt you? Or Typescript? Or you won't use technology funded by Microsoft?

I'm sorry, I read your post several times trying to understand your intent, but I ended up with more questions than I started with. That's probably on me.

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?

Actually, yes, TypeScript uses OOP patterns like classes and interfaces:

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.

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".

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.

The Typescript compiler (written in Typescript) uses no classes.

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.

> 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?

    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.

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