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

131–140 of 467 posts

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

#131

Post by runeks »

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.

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

#132

Post by Chinjut »

throwawaymaths wrote: post #69
mdm12 wrote: post #36

Earlier quoted context omitted.

Unit of measures are a great example of what a type system can do, and something not enough languages support. F#[1] and Scala[2] are two that I know of that do support UOMs. Like you, I haven't had the need to use them in the domains I work in, but I imagine that they would be invaluable in certain contexts. [1] https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... [2] https://github.com/typelevel/squants

It's also something that some languages seriously screw up. Consider multiplying a time (which is typed in go) with a numerical value... suppose what I want is a user to input number of time intervals to wait. So the user wants 5, and the interval is 2500 milliseconds. The way you get 12500 milliseconds out of that made me want to throw my computer out the window.

I don't understand. What should you get instead?

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

#133

Post by hgomersall »

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…

The point is not about validation, it's about conveying semantic information through types. It's perfectly valid to have an email type that is just a wrapper around a string. The advantage is now you and all your functions unambiguously know that the type represents an email (whatever that means) and not a frobinator.

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

#134

Post by pyjarrett »

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

Not just that, but it also often does so efficiently and doesn't incur a runtime penalty (for new type and static predicates) and will reuse previous function definitions as well.

These are the sorts of cases with function parameters in various languages other language I've dealt with, in which this would have helped:

- "dt": delta time of what? Seconds, milliseconds, microseconds, nanoseconds, ticks? Usually, I'd expect seconds if it was a float, though I've seen counter-examples, and I usually have to trace back the flow to know for use if it's a 64-bit (u)int.

- "ip_addr" and "port": What's the type of port? If you guessed "int", you'd be right in part of the system. If you guessed "string" you'd be right in a different part of the system.

- "path": Does it matter if this is a relative or absolute path? It often isn't apparent this matters and then you find out this path is passed to a different system in which it does matter.

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

#135

Post by jolux »

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’s not inherent in static types.

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

#136

Post by Ygg2 »

mhaberl wrote: post #26
Ygg2 wrote: post #10

Earlier quoted context omitted.

That's an unrelated problem, that's outside the scope of model presented. Remember the physicists adage: All models are wrong, some are useful. You can have your name change as well, or your calendar can change, or etc. Does that mean we stringly type everything? No. You model changes either via a separate field(s) or some kind of change table.

> You can have your name change as well, or your calendar can change What do you mean by that? Having a type for "country of origin" would mean that the type gives you limits on what values it can hold (any country known to ever exist) so you can not say something like: Country c = "Foo" because Foo is not a country. I can't imagine having a type for a persons name that holds checks anything but perhaps a strings len…

> What do you mean by that?

I assumed the point was old name wasn't tracked and should be.

> Having a type for "country of origin" would mean that the type gives you limits on what values it can hold

No one said your type has to be completely set in stone and contain every valid value in advance.

Have a trusted store of country name and valid until date. So defunct country can't be added.

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

#137

Post by jolux »

c7b wrote: post #118
hardwaregeek wrote: post #95

Earlier quoted context omitted.

Sure there are tradeoffs, but I disagree that it’s always so balanced. When people moved from assembly to high level languages presumably there were tradeoffs but in retrospect it’s a pretty clear cut choice. I’m not saying typed languages are as big of a shift as high level languages but it’s possible they are the unequivocal right choice.

Does that also hold for people doing data science in Jupyter notebooks? They're also programmers, arguably. At this point in the trajectory of software engineering, it's fair to assume that most of the low-hanging fruits have been picked, and solutions that are unequivocally better would have to bring something fundamentally new to the table (which types are not at all). Most solutions will be picking a particular po…

> Does that also hold for people doing data science in Jupyter notebooks? They're also programmers, arguably.

Yeah they’re definitely programmers, but anyone who’s had to maintain and deploy what a data scientist came up with in a notebook will question whether they should really be using types.

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

#138

Post by hgomersall »

mikewarot wrote: post #3

I once attended a meeting where a Professor from a University somewhere in Chicago gave a brilliant demonstration of using a similar type system for dealing with values in Electrical Engineering. It made quite sure you couldn't do things like add volts and amps. [Edit] it also handled things like parallel resistances, etc. It was in C++ if I recall correctly. This is a great idea, that I've haven't had cause to use y…

It's possible to go even further than just protecting against the wrong unit in the wrong place. You can generalise units: https://docs.rs/dimensioned/latest/dimensioned/

(Edit, that's not possible in c++)

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

#140

Post by pipeline_peak »

Type systems cause programmers to write 300 classes no one references and many duplicates of each other.

Dynamic typing allows you to focus on what really matters, not trivial business logic OOP hierarchies that get inevitably ignored.

I feel like in app development, there’s something honest about dynamic typing. You’re focusing on the instance rather than the unnecessary model definition that again, nobody uses and redefined elsewhere anyway.

Tbh, I’ve never used a language like JS professionally. I’m sure a lot of code bases are copied and pasted messes with state dependencies and things that make it so you HAVE to focus on the type. It’s an app language, you’re just not gonna find elegance lol.

I’ve been a C# dev for a while now. I’ve just found that outside of libraries/frameworks/etc how rarely object model code actually gets reused. And I appreciate the cut to the chase aspect of that.

Insert quote about gorilla with banana in forest.

Post reply on HN