301–310 of 400 posts
> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits. I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry. As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can t…
> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits. I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry. As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can t…
This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head: "... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared m…
That's one key advantage of dynamic types, but it's not the only one.
Sophisticated dynamic type systems like Julia's are difficult to model statically. Some idioms would require dependent types if they're even possible at all.
Earlier quoted context omitted.
I use classes a fair amount, but there's still some weird stuff in the language I'd take out if I could. Sparse arrays, all object keys are strings (or symbols), crazy coercion rules, the existence of `null`, weird float vs int rules.
You can use `Map` instead of object which allows keys of any type, or typecheck your objects with `Record ` and let typescript warn you about any weirdness. Typescript can also warn you if you do some weird implicit coercion. You can typeguard against `null` (although I admit it is annoying, I just want to use an optional†). And if you really want to use integer types there is always `BigInt`. --- †: I haven’t checke…
Map goes part of the way to what I want. But I really want to control which objects are considered equivalent keys, rather than being limited to reference equality.
Verily there is little new under the webdev sun...
Earlier quoted context omitted.
> you still need to have good developers writing good code, but TS will make it easier Very true. Typescript is still immensely helpful in the sense that it will complain if you pass a Thing to a function expecting a Foo, regardless of the fact that Thing is meant to be a thing but is actually an error. But IMHO, by sticking to a decision to be lean in terms of transpiled JS, TS suffers greatly from cases like the on…
You can easily write your own "type guard functions" when you think TS is missing an inference from a runtime check you would like. The syntax is simple enough, it's just a slightly different return type from boolean: function isThing(value: unknown): value is Thing { return typeof value === 'object' && typeof value.name === 'string' } The `unknown` type in general is still pretty new, but will be greatly helpful for…
The other benefit is refactoring. That saying which goes along the lines of: "you're going to be reading a lot more code than writing it" is very true. After your project gets to a certain size, and it need not be large, you start making smaller changes and moving code around -- having some guard rails there is a huge productivity boost. Being able to read code and know that it does what it says because you know the…
I don't really buy this argument about readability because the sort of information stored in types very quickly becomes pretty meaningless for humans. I remember working on a Haskell codebase and getting into an argument about this with a developer who was very much in the typed language camp. Then I saw a function that had like 8 parameters, some were just String, or Int, some where synonyms, and I asked him what it…
Earlier quoted context omitted.
This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head: "... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared m…
> This is the key advantage of dynamic types. You can make a computer do useful things without having to invest the large effort required to learn how static types work. That's one key advantage of dynamic types, but it's not the only one. Sophisticated dynamic type systems like Julia's are difficult to model statically. Some idioms would require dependent types if they're even possible at all.
Another case is what Alan Kay calls "extreme late binding" in a messaging-oriented language, as seen in Smalltalk and Erlang.
Earlier quoted context omitted.
I cannot wait to be the type of developer who just never makes typos.
Your IDE should be catching any typos. But it's not about typos, it's about understanding the quirky nature of JS and knowing what things not to do. For instance, an inexperienced developer might try to use .sort() to sort an array of numbers. It wouldn't even occur to an experienced developer to try that since they know from vast past experience that it won't work (or, at least, won't do what the inexperience develo…
Typescript + NodeJS + React + Server Side Rendering yeah... I love my young colleagues, I really do. I enjoy their infectious enthusiasm and only quietly discreetly in the secrecy of my mind recall how we built strongly typed JSP sites that did more or less the same thing 20 years ago. But in those days we got excited by Struts, Tomcat and JMS. Verily there is little new under the webdev sun...
Yeah it is quite interesting how everything goes in cycles.
Earlier quoted context omitted.
That’s a problem with your codebase, not with TS.
That's the crux of this entire debate. The benefit of a type system is that it provides an organizational framework for code bases that need it (i.e. multi year projects involving a rotating set of developers). That's the only argument for a type system that I agree with (I don't believe it reduces bugs or anything like that, and from what I've seen there are zero studies that conclude such nonsense... this is a 40+…
I don't think typescript can ever be too strict, there's lots of other regular javascript files and libraries typescript will need to interact with. True it gives you plenty of escape hatches, but the point is to have less escape hatches than javascript. Your team can discuss what should or shouldn't be allowed, I'm not sure how having strict typescript is really solving the problem of mis-aligned expectations for what is allowed code.
Regarding the non-null behavior I've found that the real problem usually isn't with the variable's type definition but with it being a 'global' or not properly defined with the constructor. One can't define it as non-null because they don't know when it is constructed aka they add a property to a class that they plan on adding later when they should probably either fetch that property first or ensure it is done in the constructor.
To be slightly fair you do get similar stuff in say java where interfaces slowly gained default methods and got closer to abstract classes.