10 ms·
It's a default for me now, on every new project. It doesn't slow down development because TypeScript allows you to easily "step down" type constraints as desire
by _bxg1 8y ago
It's a default for me now, on every new project. It doesn't slow down development because TypeScript allows you to easily "step down" type constraints as desired, and writing nontrivial code without any kind of type hints is just unimaginable to me now.
- mixmastamyk 8y ago> unimaginable I imagine adding types gradually as a design solidifies, rather than slow velocity early on. Best not to be dogmatic on these things.
- echelon 8y agoYou'll find that the more you work with types, the less this becomes an issue. You begin to think in types as a first class construct. Types don't slow me down, and I can't imagine working without them.
- mixmastamyk 8y agoYou also have to type, refactor, and test them. I work in multiple languages and the typed are definitely slower at the beginning, but pay off later. The strategy I outlined is the way to get the best out of both.
- Normal_gaussian 8y agoAlso working in both I don't have this issue. I generally find types make refactors faster - I have less bugs from the refactor.
- mixmastamyk 8y agoA mature refactor yes, a change in design often not.
- lopatin 8y ago> types as a first class construct A wild Idris programmer appears
- marcosdumay 8y agoWell, imagine type-first programming, where you design your system first just by writing the types, look how it works, and only when satisfied go bother with implementation. I'm not sure TypeScript is good enough for doing that (I don't know TypeScript that well), but it's simply much better than starting with code.
- _bxg1 8y agoTypeScript works reasonably well for this approach; it's how I tend to do things. It has some gaps when you want to do really advanced stuff, but it gives you tools like typecasting for crossing those gaps. One of the great benefits of JavaScript type systems is that since they're overlaid on a dynamic language, you can just "turn them off" as needed (when the type system fails to understand that what you're doing is safe). You can comment out type checking for a particular line, or even let your whole project successfully build while type errors remain. The type system then becomes purely a tool, and never a roadblock.
- wincy 8y agoI recently had to write a tool to output a Swagger file from a proprietary api testing format, and writing all the interfaces for Swagger based on the Swagger specification was hugely helpful. I’m not sure I would have been capable of completing the project without TypeScript. Also coming from JavaScript development first, TypeScript made learning C# and templates a breeze.
- z3t4 8y agoWhat if the specification changes ? Being static is has both advantages and disadvantages. You can do the checks without running the code, but it doesn't guarantee run-time correctness. I think a better strategy is to type check the actual code via inference, maybe adding some doctype comments to help the static analyzer, then add run-time checks where things are likely to break. And you can make your API easier to use by checking the parameters, throwing helpful and descriptive errors, allowing several different types as input, so the user doesn't have to convert his/her model to your model.
- mattmanser 8y agoIt doesn't as you've already made that decision when adding a property. Almost always you get rid of the property entirely and replace it with a new one (and the type), you extremely rarely change the type. And you will almost always know what type a property needs to be. Name? string. IsActive? boolean. Last modified? Date. Etc. Also typescript just has number, so you're not even faffing around thinking "int, float, long, double, decimal, unsigned, signed" when adding a number. Although this is ultimately a bad thing.
- mixmastamyk 8y agoIt does, I’m talking more about module/system architecture than properties. I might go through three designs on a brand new project and futzing with types and tests while factoring it is an inefficient use of time. Waiting until satisfied with design is my advantage.
- Retozi 8y agoI have never understood why typed languages make you slower at any point in time (early, late etc.). Because you have to hit more keystrokes to write your program? That doesn't compute. typing is the thing you do the least amount of when programming. In all best practices we are taught to not save keystrokes. Name your variables expressively. write small functions. document code. Write tests. All ""excess"" keystrokes nobody questions. But when you have to type " ... : number" it's slow velocity? In my opinion people vastly over-estimate productivity boosts of saving keystrokes. It's the tedious, boring part of the work that you would like to skip entirely, hence excess keystrokes feel way more "slowing you down" than they acutally are. Although it doesn't matter, you actualy save keystrokes: autocomplete, auto-refactors and less low level unit-tests compensate the couple of type annotations easily.
- williamdclt 8y agoI completely agree with you, but the criticism isn't usually with typing number, it's typing complex higher-order functions or this kind of things. Where the time lost isn't in typing out the code, but in understanding what the type should be or (worse) what does this cryptic typing error means
- weberc2 8y agoI don’t tend to write or encounter many complex higher order functions in other languages. Are they common in JS?
- nurettin 8y agoIt is not the typing per se. Anecdotally, I started adding types to my python code and it is somewhat useful. That usefulness is diminished when you are fighting the type system instead of getting things done. Like when you have to make exceptions in typescript by using Any. Like when an interface for a js library is missing and you don't want to do all that work. Or when an API returns a field with a different type in between two calls and you have to make exceptions in the code when parsing with jackson in java.
- 8y ago
- weberc2 8y agoWhy do you imagine types slow velocity? My experience is the opposite. I occasionally prototype in Go and then backport to Python (to integrate with our application) because I can iterate so much more quickly (yes, Python has type annotations, but the ergonomics are poor and the type checker is immature).
- mixmastamyk 8y agoExperience. Again, not talking about a mature project, but a new one in the design phase. Types (like unit tests) are extra work at this point until a good design is discovered. Which takes time to think about.
- bengotow 8y agoYep I feel the same. TypeScript improves my workflow tremendously and I use it for everything now. Going back to regular javascript feels like driving without a seatbelt. Sure you can but why? Type-checking and smarter autocompletion mean I don't make mistakes as often and my productivity is higher. (No longer run the app, see I misspelled a function call, fix and run again, etc.) I also feel unit-level tests are less necessary with TypeScript. I used to write a lot of JavaScript tests that essentially just confirmed that "this sh*t is all tied together correctly". With TypeScript, if a code change or refactor broke something structural, you know immediately!
- connor4312 8y ago> I also feel unit-level tests are less necessary with TypeScript. Especially with strict compiler settings, including strict null checks, and the good type conventions they encourage. To give a small example, if you have a value that can either contain an error or a successful result, you can model it as the union of a success and error state. This prevents you from accessing the value until you check the result is successful (and the compiler will nicely infer the type in subsequent usages once you do.) For me, with rigorous compiler settings and a good proficiency in type modeling, I've reached the point where I rarely have any runtime errors at all once the code compiles. Sure it might take 2% more time to write code and think through my data model, but I spend 95% less time debugging it and the end result is much more maintainable. Even using typed languages like C# and Go now leaves me slightly dissatisfied!
- hahamrfunnyguy 8y agoWith C#, I am pretty sure you can get some of what you mentioned by using stricter compiler settings.
- pvorb 8y agoThis doesn't come as a surprise to me, since Anders Heijlsberg, wo created TypeScript, was the technical lead of the team that developed C#.
- 8y ago
- josteink 8y ago> It doesn't slow down development I don’t know about the rest of the world, but I’ve never once been slowed down by a compiler saying “It won’t work like that. Don’t waste your time”.
- reificator 8y ago> > It doesn't slow down development > I don’t know about the rest of the world, but I’ve never once been slowed down by a compiler saying “It won’t work like that. Don’t waste your time”. I'm right there with you, I really don't understand this train of thought that catching errors faster somehow makes you slower. I like having the compiler there to catch my errors when I make them rather than some number of minutes/hours/days/months later when everything is on fire and I've forgotten the context of what I was doing. Maybe learning a statically typed language (nearly) first damages your brain irreparably, and there's no longer any hope for me.
- kazinator 8y agoYour remarks apply only to cranking out new code. Static typing prohibits making fundamental changes to an existing body of code, like changing a core, widely-used data structure. To make such a change, you have to be extremely sure that you want it and that you're doing it right. Then you can commit to the days and weeks of refactoring at the end of which you once again have a program you can run. Under dynamic typing, you just do a small part of the job, yet the program builds; you can get in there and try things. Decisions about how to proceed can be guided by errors you run into when you step on the things broken by the partial refactoring. Seeing things working right away can be a motivator to get the whole thing done. Or it can help you see that, oops, the change is not worth doing or bad for whatever reason: you dodged a bullet with a small amount of sunk cost (the few changes you made that you can throw away without a whole lot of regret). Static typing helps with small refactoring where the ripple effect is small. The compiler pinpoins things that have to change; they happen to be few in number, and don't have too many ripple effects of their own. If your change breaks everything, then it's moot; the compiler tells you there are breaking changes everywhere. There is another angle: under dynamic typing, changes can be done in ways that things continue to work. You can write modules that have "absolute genericity": they work with objects of any type without being recompiled. Such things are bullet-proof against all conceivable refactoring.
- sideshowb 8y agoWait, type checking is good again? Suits me. Welcome to 1985 folks :-)
- highmastdon 8y agoYes, but not the rigid ways of traditional typing but when using duck-typing.
- vp8989 8y agoAlso apparently SQL is #good now. But only because all the people who just spent the last 6 years doing Node said so.
- h1d 8y agoDon't like pedantic attitude just because some recent paradigm matches that of a while ago. Back then, you don't know dynamic types won't be too welcomed.
- jcolella 8y agoI'm also using it as my default. I also find it great that with every release, they are pushing features that promote immutability; ReadonlyArray, and const assertions, to make developer workflow better and safer.