5 ms·
Are there any people that have switched to TypeScript that still think dynamically typed languages have advantages over statically typed ones? Even for small pr
by seanwilson 8y ago
Are there any people that have switched to TypeScript that still think dynamically typed languages have advantages over statically typed ones? Even for small projects with only me working on them, I find static typing saves me a ton of time and dynamic features are very rarely required or useful. The vast majority of bugs in my TypeScript programs collect around the places they interface with untyped JavaScript code.
- draw_down 8y agoI use Flow at work, and have plenty of experience with both statically-typed and dynamically-typed languages. I think it's a simple tradeoff- more certainty for more toil. It can be a real chore convincing Flow that working code works, and this can force you to use less-readable idioms to make the typechecker happy. It also lards up your code with extra dollar signs, angle brackets, and other crud, making it less readable. These can be acceptable costs depending on your project, particularly the size of it (in lines of code, components, number of engineers, however you care to count).
- Roboprog 8y agoSmall population that would expend the effort for something expected to be of little benefit at best. Some people can’t seem to function without static (global?) types though, and this works for them.
- Jach 8y agoDoes TypeScript let you build a program interactively as a living thing? Example of what dynamic languages for the browser (ClojureScript) have been doing for 5 years now: https://www.youtube.com/watch?v=KZjFVdU8VLI https://www.youtube.com/watch?v=KZjFVdU8VLI Given that frontend work is so often an endless series of tweaks I don't know how people stand doing anything big for a long duration the classic way of edit -> compile (refresh) -> rebuild runtime state to look at what changed/play around/test -> repeat.
- WorldMaker 8y agoTypescript can be indeed run directly inside the browser, though that's often not recommended, and none of the currently recommended "Hot Module Reloading" tools that I know of take that approach. Most of the HMR tools out there support Typescript in some way directly or indirectly (Typescript plugins for webpack, etc). `tsc --watch` is quite handy and useful in those situations where an HMR tool doesn't support Typescript or you aren't using an HMR tool at all. (For instance, on one project recently I've been just using npm package `lite-server` which implements "BrowserSync" automatic reload and `tsc --watch`, because I currently don't need a full bundler like webpack, though I expect that to change soon.)
- basil-rash 8y agoTo me that example doesn't look all that different from typical hot-reload provided by webpack or similar. Can you tell me what I'm missing here?
- Jach 8y agoI'm not familiar with webpack but in general hot reloading isn't quite the same as dynamic redefinition, but can be close enough for many purposes. If you can set up something approaching Java's hotswap (made even better by JRebel) then perhaps the advantage is lessened.
- porsager 8y agoYou get dynamic redefinition with Wright[1][2] and chrome, and you can plug in Typescript pretty easily. In v2 currently under way, you can use es modules which gives you a much better experience since you can reload a single file instead of an entire bundle (always sub 100ms update times). [1] https://github.com/porsager/wright https://github.com/porsager/wright [2] http://porsager.com/wright/example.mov http://porsager.com/wright/example.mov
- austincheney 8y agoOver the past year I converted 50k loc language beautifier to Typescript. The Typescript compile time is about 5 seconds give or take half a second, which is about 99% of my total build time. I have a tool I developed that is a combination of a web server and web sockets that automatically rebuild and refresh the browser when a code file is saved.
- vga805 8y agoI bounce back and forth between TypeScript and Clojure. I've been keeping a close eye on Clojure's upcoming spec as it seems to be a nice opt-in, run-time type-checking solution. I like the flexibility and quickness with which dynamic languages let me iterate, but I want the safety. I want at least some of the benefits of both. So yes, they (dynamically typed languages) have some advantages. Sometimes when I'm iterating quickly, especially on new projects, I don't want to fight with the compiler. BUT, I vastly prefer TypeScript to JavaScript because JS has a lot of foot-guns. I think when we get the existential operator, it will have less foot-guns, but I will probably never again write a new project for work in JS from scratch. I really love the ideas Rich Hickey put forth in his most recent Clojure conj talk: https://www.youtube.com/watch?v=YR5WdGrpoug https://www.youtube.com/watch?v=YR5WdGrpoug The ability to spec out the shape of an object, and then in the different contexts in which you need some of that data, specify what you need, is an awesome solution to optionality (Watch the talk!). I absolutely love how much thought RH has put into the design of Clojure, and I think the final release of spec will be a close to perfect balance of dynamism and opt-in safety. Of course, TS is a superset of JS, so adopting it little by little sorta gets me that balance I want.
- wvenable 8y ago> I don't want to fight with the compiler. The only time you're ever fighting the compiler in a modern statically typed languages with type inference is when you've made a mistake.
- rtpg 8y agothe problem with most static typed languages is that the type systems are just not very flexible. Typescript union types are 10x more useful than Haskell's `Either` type, and you can build extremely complex type signatures that let you build clean APIs just from that. Static typing is nice when the tools given actually let you build nice APIs
- h1d 8y agoGood thing about TS is that it's currently an evolving language and if you have problems with the typing system, there's a good chance it will be improved instead of other languages where it might not pick the improvement up quickly which makes you feel like the language is at a dead end.
- emmanueloga_ 8y agoRegarding Typescript specifically, I'm a bit torn. I used to be excited about it but after a while of using it I see it more like a tool to migrate existing JS code or to interface with existing libraries written in JS, and not like an ideal tool to write code from scratch. The reason is, the type system is actually incredibly complicated (to accommodate to all sorts of silly and messy things you can actually do in JavaScript). I'd prefer using a more principled language for brand new projects. Which language is that? I'm not sure yet, but dynamic vs typed doesn't seem as important to me. I think ClojureScript is a better language than TS. Kotlin/JS also looks good, for a less "alien" language that is still better typed than JS/TS. But I don't have experience working on medium/big projects with these yet. OTOH, for browser apps, the main plus for TypeScript is that if you pick a subset, ala C++, you get an OK language that never gets too far away from what you actually get when you convert the app to JS, so easier to debug and sometimes reason about. So there you have it... I'm torn :-)
- ttty 8y ago> The reason is, the type system is actually incredibly complicated (to accommodate to all sorts of silly and messy things you can actually do in JavaScript). Can you give some examples? I have a feeling if you need that, you are writing some complicated magic code, but I might be wrong.
- acemarke 8y agoHere's a couple specific examples I just saw within the last couple days. `immer` is an immutable update library based on ES6 proxies. In addition to safely applying "mutative" code immutably, it also freezes the output to keep you from accidentally mutating it elsewhere. An Immer maintainer just added some kind of a `DeepReadOnly` tag to its typings in a patch release, which broke things for a bunch of people: https://github.com/mweststrate/immer/issues/289 https://github.com/mweststrate/immer/issues/289 This specifically broke our PR to convert `redux-starter-kit` to TS, with this lovely error message: https://github.com/reduxjs/redux-starter-kit/pull/73#issuecomment-453887310 https://github.com/reduxjs/redux-starter-kit/pull/73#issueco... I'm not saying every use of TS is that complex, but I do absolutely think that TS types can get ridiculously complex (and that people can get sucked into spending _way_ too much time trying to model dynamic JS behavior in static types).