6 ms·
Depends on the context. When you're programming a transactional banking system? Heck yeah I want static types. When you're programming a form on a web page? It
by jaredcwhite 4y ago
Depends on the context. When you're programming a transactional banking system? Heck yeah I want static types.
When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix.
- simplify 4y agoI would LOVE static typing when programming a form on a web page. However, it's the fault of HTML that this is bad, not static typing itself. Although, in theory, one could write a parser to inject what form elements are available into the type system... :)
- deleted 4y ago[deleted]
- heurisko 4y ago> When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix. If you don't mean just HTML but some server side processing, yes, I would. This is still PHP's bread and butter and being able to bind a form to static types is really convenient.
- choeger 4y ago> It's way-ay-ay more effort Just because you tend to ignore the many complexities that are actually involved in a form on a web page. It's exactly this bias that stems from untyped languages and that needs to die. Http is a complex beast and we should either replace it with something more simple and robust or at least acknowledge the complexity in our programming. Generally speaking, if doing something with a proof of type-safety feels complex, you probably ignored many corner cases before.
- deleted 4y ago[deleted]
- bcrosby95 4y agoIt's not complexity. It's pointless bookkeeping. If you don't cut corners on your static typing, you're looking at 2-4 single use classes per API endpoint: 1-2 for the web layer, and 1-2 when going into the domain logic layer. Many people skimp and just re-use the core domain class for everything, which is the worst of both worlds. I'll take a map, spec, and select-keys over this all day long.
- rictic 4y agoThat's if you write it in Java. With a type system like TypeScript's you can write largely the same code as before, with a few annotations to clarify what you mean, and you get the exact same runtime only you also will get compile errors if a change elsewhere in your program violates the assumptions of that code.
- samatman 4y agoI don't view Typescripts as a good argument against dynamic languages. I view it as a good case for a well-designed gradual type system for dynamic languages. All valid Javascript is Typescript, in a profound rather than trivial way.
- xigoi 4y agoStatically typed ≠ class-oriented
- wizofaus 4y ago2-4 single use type definitions per endpoint sounds pretty atypical to me, but I agree choice of language helps here, e.g. TypeScript has pretty powerful typing facilities (Pick/Partial etc) that make type reuse far more practical. It's bookkeeping yes, but definitely not pointless.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- duped 4y agoIt's actually less effort since you save time writing unit tests. Show me an untyped program and I'll show you a program missing tests and containing bugs. Static typing saves time and money.
- wvenable 4y ago> It's way-ay-ay more effort No, it's not. Initially it's not any more effort and in the long term it's significantly less effort. Having spent equal amounts of decades in static and dynamic typing (and strong/weak) I would absolutely take the former any day for both ease of development and correctness.
- preordained 4y ago> Having spent equal amounts of decades in static and dynamic typing I hear this, as well as "eliminates whole classes of run time errors" (as if Ruby and other such codebases are just ablaze everywhere on account of this...), but I wonder if people dabbled in this and think they have it all figured out, or if they've used a modern dynamic language like Clojure that has default immutability or been in a modern Ruby codebase that wasn't cowboy-coded.
- wvenable 4y agoSome of this is just personal taste -- programmers are not all cookie-cutter intellectuals that approach all problems the same way. We're also not all working on the same problems. For me, the idea of dynamically modifying code at runtime is like the first circle of hell. But I've programmed in enough languages to understand the appeal even if it doesn't fit with the way I like to work. But I will take issue with blanket statements that static typing is more effort than dynamic typing with all things being equal. In my own personal experience, that is just not the case. But I wonder if many people have been so damaged by Java that anything seems better by comparison.
- preseinger 4y ago> as if Ruby and other such codebases are just ablaze everywhere on account of this.. They literally are, I think? Ruby is a notoriously unreliable language, in large part due to its dynamic type system... (also all of the unsafe idioms it promotes, a separate discussion)
- tasuki 4y ago> way-ay-ay more effort for dubious gains How is it way more effort? In any of the nicer languages, there's type inference. Dubious gains? Strong static typing makes entire classes of runtime bugs impossible (null pointer exceptions, for example).
- wizofaus 4y agoNew downsides such as? And if having to add a few type definitions to your codebase is "way-ay-ay" more effort, I can only assume you really hate typing, as the mental effort is typically very low (compared to figuring out how to efficiently translate business logic into code, and how to organize code to make it easy for a team to work with over many years as requirements change etc.). There even tools that will generate type definitions for you based on sample data.
- mst 4y agoThis is a wild-ass guess but ... I don't use IDEs. In fact I use original Bill Joy vi. I suspect for most of the people we're talking to 'I<tab>' will say Int and 'S<tab>' will sat String and that's going to make our experiences very different.