3 ms·
I'm happy it's working for you well. The map changes were more in the line of changing core maps and then having to update every place they were used. IDEs are
by grayrest 5y ago
I'm happy it's working for you well. The map changes were more in the line of changing core maps and then having to update every place they were used. IDEs are amenable to this as long as they can figure out the references. Cursive helped some but most of the work was still manual.
My point of reference between typed and untyped code is primarily with Typescript and Javascript since that's 99% of what separates the two. For what it's worth, I do have 21 years of experience and have been lead on my projects for a number of years. As the lead, I get enough benefit from the type annotations that I've told co-workers to just any type anything they can't get working immediately and I'll fix it in code review. It's enough of an overall team velocity increase and easier code reviews that it's a win.
I'm not trying to argue with your experience. Dynamic languages work fine for building products and Clojure is my favorite dynamic language by a significant margin. I'm sure I'll write more Clojure in the future. I'm just trying to explain the benefits since I had the same mindset 15 years ago and now prefer static types. I'll mention that don't particularly like C# or Java and their type systems are not expressive enough for me to prefer over dynamic language.
- adregan 5y agoI agree that at large scale, types are one of the few things that keeps a project from completely falling apart (and I love lisp, but I would have a really hard time convincing my colleagues to adopt a dynamic language), but this seems counter to that: > I've told co-workers to just any type anything they can't get working immediately and I'll fix it in code review If you’re co-workers aren’t able to work with the types, how can they receive any benefits? Not everyone is at a hyper growth place, but those that are would have zero luck with this pattern.
- grayrest 5y ago> If you’re co-workers aren’t able to work with the types, how can they receive any benefits? There's plenty of distance between unable to work with types at all and knowing the full breadth of the TS type system. I've worked with plenty of people who weren't enthusiastic about types and this is my way of handling those objections. Even someone who doesn't know/care about types gets the IDE features from the types. I have yet to have someone persist in sending me lots of any types past two weeks because having your work constantly corrected is embarrassing. I don't expect everybody to care about the type system past generics so if someone wants to write a basic index type instead of the more correct keyof or opts for any over figuring out a conditional intersection type, I'll take care of it in code review. I'd rather have them writing code than reading TS documentation to wrangle advanced types and people do look at the commits when they go in and learn the tricks over time.