The type system is a programmer's best friend • Hacker News Board

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

#141

Post by 323 » Sat, Nov 05, 2022, 4:53 PM UTC

Smaug123 wrote: post #11

henrydark wrote: post #4

> ... to prevent silly mistakes like multiplying $100 with £20 Honest question, what should multiplying $100 with $20 give?

2000 square dollars? If I'm choosing between ways to spend capital so as to improve the efficiency of a process, and that process currently produces five widgets per dollar, then the quantity I'm comparing to choose between my courses of action can be measured in widgets per square dollar. Hiring a better engineer for more money may create an efficiency improvement of 1 widget per dollar, with an outlay of $1k extra…

2275 square dollars would be more correct, since GBP/USD is 1.1372 right now.

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

#142

Post by david422 » Sat, Nov 05, 2022, 4:54 PM UTC

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…

> shift as much responsibility on the compiler as you can and have the compiler check the code you write to any extent technologically possible.

I think that people first starting out or people who have never worked on large/new code bases with a diverse range of authors don't seem to appreciate this concept.

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

#143

Post by pyjarrett » Sat, Nov 05, 2022, 4:57 PM UTC

runeks wrote: post #131

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 '='…

That's definitely cool, but for everyday programming I'd consider this a waste of time.

I agree that it sounds really stupid up front, but it's done when you're just you modeling the constraints of the problem. I've found that it saves a lot of time in debugging and silly mistakes later.

For types with invariants, you just add the `Invariant` aspect and then the type invariant gets checked automatically when passed as a parameter. Combined with built-in pre/post conditions, I've found that these sort of automatically inserted checks give me a lot of confidence, and allow significant embedding of conceptual and domain knowledge during development.

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

#144

Post by kodah » Sat, Nov 05, 2022, 4:59 PM UTC

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…

My hypothesis is that it's so old to you because that discovery and the spreading revelation was first order to you. To people learning programming today, they end up having to somewhat rewind the timeline and learn everything new at 2x speed.

That's to say, having old conversations with new engineers is a really refreshing exercise and I'd encourage the world to continue doing it.

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

#145

Post by highwaylights » Sat, Nov 05, 2022, 5:01 PM UTC

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 in a career that is almost entirely based around automating things.

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

#146

Post by indymike » Sat, Nov 05, 2022, 5:03 PM UTC

hansvm wrote: post #62

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…

That sounds like an argument against excess validation rather than against types (maybe because of blog-driven development showing minimal examples of the power of types?). Picking on one of those points, suppose emails are just strings. What then prevents them from getting used as names, identifiers, and other unrelated data? Just your continued vigilance as a programmer and hoping that nobody ever carelessly names…

> That sounds like an argument against excess validation rather than against types (maybe because of blog-driven development showing minimal examples of the power of types?).

A lot of developers confuse types and validation.

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

#147

Post by majjgepolja » Sat, Nov 05, 2022, 5:07 PM UTC

recursivedoubts wrote: post #47

> grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug > danger abstraction too high, big brain type system code become astral projection of platonic generic turing model of computation into code base. grug confused and agree some level very elegant but also ver…

I am grug. More benefit type when there's red line in editor. More benefit type system when F2 rename everywhere.

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

#148

Post by hither_shores » Sat, Nov 05, 2022, 5:08 PM UTC

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…

> since the shared libs have generics and I'm always casting things.

This indicates to me that you're trying to write code that isn't correct (not doesn't work, but rather only works because of implicit couplings between components) and/or doing exotic lisp-style metaprogramming.

In the latter case, yeah, C#'s type system isn't powerful enough. Others are (to an extent: arbitrary code execution at compile time is never going to be completely safe).

In the former case ... that should be difficult. Forcing you to be explicit is half the point of a type system.

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

#149

Post by bluGill » Sat, Nov 05, 2022, 5:10 PM UTC

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…

I'm adverse to debuggers as i've more than once caught myself following a rabbit hole of steping through code instead of thinking.

IDEs have some use, and static analysis has proven to catch the same mistake over and over, but only as the authors of those tools have discovered that false positives cannot be allowed ever, once there is a false positive the tools is worthless.

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

#150

Post by deltasevennine » Sat, Nov 05, 2022, 5:15 PM UTC

Types got a bad wrap because of C++. There was a strange dichotomy between languages like python/javascript and C++. If type systems were so good why was it easier to program with javascript and python then with C++? People got confused and promoted dynamically typed languages as better.

What many people didn't realize was that C++ was hard DESPITE the type system, not because of it. This was soon rectified with type script which eventually caused a complete flip of opinion in the industry once javascript developers realized how much better it is.

The other question to this equation is why was python so easy to program for DESPITE not having a type checker (it has external type checks now, but I'm saying before this)?

The answer is deterministic errors and easy traceability. If you have an error that happens either at runtime or at compile time you want to easily know what the error is, where it came from, and why it occurred. Python makes it VERY easy to do this. Not all type checkers make this easy (see C++).

In actuality type checking is sort of sugar on top of it all imo. Rust is great. But really the key factor to make programming more productive is traceability. Type checking, while good is not the key factor here.

Think about it. Whether the error occurs at runtime or compile time is besides the point. Compile time adds a bit of additional safety, but really if an error exists, it will usually trigger at some point anyways.

The thing that is important is that when this error occurs whether compile time or runtime you need as much information about it as possible. That is the key differentiator.

That is why typeless python and typed rust, despite being opposites, are relatively easy to write complex code for when compared to something like C++.