Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The type system is a programmer's best friend

dusted.codes

Post reply on HN
Print view View original

151–160 of 467 posts

Re: The type system is a programmer's best friend

#151

Post by noveltyaccount »

highwaylights wrote: post #145
gary17the wrote: post #104

This is, IMvHO, such old news that it feels... weird to still read about it in a year with the prefix of 20. Every programmer who has ever single-handedly written a 100,000+ LOC software system will tell you the same thing: shift as much responsibility on the compiler as you can and have the compiler check the code you write to any extent technologically possible. Getting rid of bugs by experiencing, diagnosing and f…

I’d take this further. I was listening to the John Carmack episode of Lex Fridman from the summer, and he makes a comment about being frustrated that in the Valley there’s an almost religious opposition to IDEs, debuggers, and static analysis. Some of those tools have only become more powerful over time and I’m perplexed as to the mindset that would make a person averse to automating the drudgiest parts of their job…

When I graduated college in the '00s I thought Vim was the most amazing thing I'd ever learned. Then a colleague at my first job showed me what happend when you typed . after a variable name in Visual Studio. Code completion, inline documentation...my mind was blown, and I never looked back. When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code competition...well, there are no bonus points for doing things the hard way.

Re: The type system is a programmer's best friend

#152

Post by persimmonster »

tel wrote: post #82
cardanome wrote: post #52

Oh god, please just use primitive types. Don't make assumptions about things. Everyone thinks they are so smart validating emails, phone numbers, zip codes and all until their great design goes live and they discover that users in the real world do not follow their assumptions. I have seen that happen again and again. No, if your idea of validating an email is more complicated than "should have an @ symbol", I guaran…

There's a sharp distinction between validation and typing. I can cast a string into a domain-specific Email type without validating the string. I can also reject a string due to a validation rule without changing its type. Opaque type aliases are great because they impose semantics. Even if I don't know how to validate an email, it's nice, at times, to distinguish a string which I suspect to be an email from all othe…

No post body was provided.

Re: The type system is a programmer's best friend

#153

Post by marcosdumay »

suzzer99 wrote: post #128
c54 wrote: post #110

Earlier quoted context omitted.

I agree with this, yet look at some of the extremely salty comments in this thread. People are upset that something might be useful and that they might benefit from learning it or changing their ways.

It's weird to me how scanning the comments all seem to refer to systems with 100k-ish LoC and dozens of contributors. A big chunk of my job is writing node microservices in AWS Lambda. I do everything I can to avoid shared library code, since past experience tells me there be lots of dragons (mainly in when and how to push or pull lib updates to components). I have a very tiny shared lib that I try to never touch and…

> Unit tests are a breeze since I never have to cast objects or worry about generics

Generics reduce the amount of things you must care about on your tests.

And you shouldn't cast objects in almost no code ever. Most 100k LoC programs won't need it even once, your microservices should need it proportionally less.

That's the thing. The gains grow superlineraly with the amount of code. They make it just a bit easier to write some trivial 100's LoC programs, and they make it possible at all to have a working 100k LoC system. But if you don't learn them, you won't know where the break-even point is for you.

Re: The type system is a programmer's best friend

#154

Post by emodendroket »

gary17the wrote: post #104

This is, IMvHO, such old news that it feels... weird to still read about it in a year with the prefix of 20. Every programmer who has ever single-handedly written a 100,000+ LOC software system will tell you the same thing: shift as much responsibility on the compiler as you can and have the compiler check the code you write to any extent technologically possible. Getting rid of bugs by experiencing, diagnosing and f…

I don’t disagree that it makes things much more pleasant, but I started doing this around 2013, which, while old, was still a year beginning with 20, and consensus was trending the opposite way and people were bullish about stuff like Ruby. The pendulum has really swung in the other direction.

Re: The type system is a programmer's best friend

#155

Post by Jach »

quechimba wrote: post #139

Started a Ruby project using Sorbet and I'm refactoring with confidence now. It's such a huge help. The project is about 9000 lines of Ruby by now and I don't think I would have been able to get this far without static type checking

The second edition of the book Refactoring was written to use JavaScript instead of Java in part to dispel the myth that you can't confidently refactor without static types.

Re: The type system is a programmer's best friend

#156

Post by hither_shores »

capableweb wrote: post #122
howenterprisey wrote: post #112

Earlier quoted context omitted.

I don't know what to tell you. The downsides are apparent. There is no logic theorem that says the upsides and downsides need to be equally as apparent. The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff. Nobody's talking about the downsides of type systems except to the extent that they're worth talking about: see the comments here every time someone compares the type s…

> The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff This is why engineering/software articles in general (this one included) needs to bring up tradeoffs more often. No, "learning more stuff" is not a downside or a tradeoff, it's just a fact of learning anything. That you introduce more coupling is a tradeoff. That the program (sometimes) gets harder to change is a trade…

> That you introduce more coupling is a tradeoff. That the program (sometimes) gets harder to change is a tradeoff.

You don't introduce more coupling, you document the coupling that already exists. If your program is hard to change with types, it would be hard to change without types - but easier to change incorrectly.

> That is becomes easier to write large, messy programs because programmers feel more safe in the future to refactor, is a tradeoff

Sure, I guess this is true in principle - but you could say the same about IDEs, or version control, or grep. The effect size is small.

Re: The type system is a programmer's best friend

#157

Post by kaashif »

howenterprisey wrote: post #112
PainfullyNormal wrote: post #102

Earlier quoted context omitted.

> What's more, for a programmer who doesn't get the value of types, the major downsides are already apparent, at least at a basic level. How could the downsides possibly be apparent if the upsides are so mysterious they need an article to spell them out? > It's an article design to help certain programmers learn a particular thing Have they actually learned that particular thing if they don't know the tradeoffs they'…

I don't know what to tell you. The downsides are apparent. There is no logic theorem that says the upsides and downsides need to be equally as apparent. The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff. Nobody's talking about the downsides of type systems except to the extent that they're worth talking about: see the comments here every time someone compares the type s…

> The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff.

You still do need to know that stuff if you have no types in your language, but the compiler won't help you.

Re: The type system is a programmer's best friend

#158

Post by gilbert_vanova »

Smaug123 wrote: post #33
musingsole wrote: post #28

Earlier quoted context omitted.

In a stringly-typed world, you still end up with a purpose-tuned model of what an email is, how it's used, and what error cases are -- these just aren't implemented as qualities on a type. There's a dozen approaches for it, many from the functional programming paradigm. But an example of one approach would be that your consumer functions become responsible for interrogating the data they'll act on -- through assertio…

I guess I'm only opinionated about it because I'm 100% not smart enough to get it right unless something stops me getting it wrong. ("It" can be pretty much anything here.) It's why I'm such a terrible Python programmer. The foundry analogy is spot on - there's nothing to stop me throwing my grandma in, so at some point you can bet I accidentally will.

> I'm 100% not smart enough to get it right unless something stops me getting it wrong

IMO, type systems are harsher on modeling mistakes than something like Python is. Sure, you'll get it wrong the first time (sorry Grandma!). And in Python, you can mutate your system rapidly into a new state that can accommodate the old model's mistaken assumption. If your program starts getting complex enough that the mutation speed is dropping -- deconstruct it into smaller, manageable problems.

Humans are 100% not smart enough to build systems the way a lot of corporate shops keep trying to.

Re: The type system is a programmer's best friend

#159

Post by czx4f4bd »

noveltyaccount wrote: post #151
highwaylights wrote: post #145

Earlier quoted context omitted.

I’d take this further. I was listening to the John Carmack episode of Lex Fridman from the summer, and he makes a comment about being frustrated that in the Valley there’s an almost religious opposition to IDEs, debuggers, and static analysis. Some of those tools have only become more powerful over time and I’m perplexed as to the mindset that would make a person averse to automating the drudgiest parts of their job…

When I graduated college in the '00s I thought Vim was the most amazing thing I'd ever learned. Then a colleague at my first job showed me what happend when you typed . after a variable name in Visual Studio. Code completion, inline documentation...my mind was blown, and I never looked back. When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code…

Both Vim and Emacs have plugins for intelligent code completion and viewing inline documentation. I personally prefer to use VS Code or Jetbrains IDEs with Vim emulation, but I've seen setups for both Vim and Emacs that basically made them into full-fledged IDEs.

Re: The type system is a programmer's best friend

#160

Post by allisdust »

docandrew wrote: post #70

I have to plug Ada's rich type system for explicitly encouraging this kind of design. With things like type predicates [1], you can do run-time enforcement or even prove at compile-time (to optimize away the runtime checks) that type constraints are met. As an example of this, in a piece of code I'm working on there's a Base64_String type, where only RFC 4648 characters are permitted to be part of the string, the '='…

How does this get enforced for string content changed at runtime? Or does this apply for only to strings initialised in code.
Post reply on HN