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

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

#181

Post by noduerme » Sat, Nov 05, 2022, 5:44 PM UTC

hither_shores wrote: post #148

suzzer99 wrote: post #128

Earlier quoted context omitted.

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 ne…

Casting is often necessary for parsing inbound data from certain mysql libraries or CSV or JSON depending on how it's written. I would guess that might be what the parent is talking about. That said, if you don't cast or parseFloat or whatever in JS you're going to have a lot of trouble. And if you're doing that, why not do it in Typescript where you'll know that the data you're accessing has been safely cast based on its type.

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

#182

Post by kaashif » Sat, Nov 05, 2022, 5:45 PM UTC

deltasevennine wrote: post #150

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…

> 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.

Well, if the error is at compile time, there's no chance that code makes it to production and affects customers.

If the error is at runtime, you need to have tested that edge case and if you haven't, there could be customer impact.

I mean, once you see a few TypeErrors in Python code with no type annotations, or a few NullPointerExceptions in Java where there's no compile time null checking by default, I think it becomes very clear that catching things at compile time is much better...

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

#183

Post by blep_ » Sat, Nov 05, 2022, 5:46 PM UTC

323 wrote: post #141

Smaug123 wrote: post #11

Earlier quoted context omitted.

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.

Look closer at the signs. The person above agreed USD * GBP was weird and wrong, but disputed that USD * USD was any better.

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

#184

Post by tsimionescu » Sat, Nov 05, 2022, 5:46 PM UTC

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…

Note that most such solutions break (or become much much much more complex) if you want anything more than simple arithmetic from them. For example, matrix multiplication with typed values (where each element of the matrix can have a different type/unit of measure) is extremely ugly code, and basically no such library supports it - even for matrices of fixed size (say, code that could multiply 3x3 matrices with 9 type parameters - which is not unrealistic in physical simulations).

This is a fundamental limitation of types - they tend to scale poorly to very complex non-uniform structures. That's not to say that they shouldn't be used when they do scale nicely, though!

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

#185

Post by skybrian » Sat, Nov 05, 2022, 5:46 PM UTC

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…

Unless you're really going to use textareas with scrollbars for every string and store everything in unlimited length database fields, you probably do want to distinguish between single-line and multiline strings and have some limit on their lengths.

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

#186

Post by dividedbyzero » Sat, Nov 05, 2022, 5:47 PM UTC

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…

> No, if your idea of validating an email is more complicated than "should have an @ symbol", I guarantee you, there is counter example that will mess you pretty system up.

Requiring b2b users to use their @company.com email is common and some b2b customers actually expect to be able to configure that. Another simple case is stripping out any "+whatever" from gmail addresses and to flag that sort of thing for other eomains so support can verify it's not a case of someone creating 72 trial accounts. Yes, rejecting users due to naive and incorrect validation is bad, but treating emails as entirely opaque strings isn't always an option either.

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

#187

Post by tsimionescu » Sat, Nov 05, 2022, 5:50 PM UTC

mrkeen wrote: post #48

masklinn wrote: post #38

Earlier quoted context omitted.

I wouldn't say that UOM are uncontentious, things can get dicey around reference units and precision for instance, or the combinatorial explosion of composite units.

Right, but if you told your professor you sometimes represent distance in Volts (to make your calculations simpler) you'd get some funny looks. You could even double-down on it: "Have there been any studies that prove that using units of measure helps you get the right answer?"

Funnily enough, there are some applications for converting mechanics problems to analogous electricity problems to leverage circuit simulation software such as PSPICE to help solve things like transcendental equations.

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

#188

Post by blep_ » Sat, Nov 05, 2022, 5:50 PM UTC

masklinn wrote: post #34

mhaberl wrote: post #26

Earlier quoted context omitted.

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

> I can't imagine having a type for a persons name that holds checks anything but perhaps a strings length, certainly not a list of all possible names. As always, that is very domain-specific: there are lots of countries with naming laws, some of which do have lists of legal names.

Legitimate question: what do they do about immigration into those countries from countries without such laws?

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

#189

Post by draw_down » Sat, Nov 05, 2022, 5:52 PM UTC

AnimalMuppet wrote: post #176

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…

Ahem. Not all email addresses have an @ in them. If you're sending an email to another user on the same machine, just their username is enough (at least for some mail implementations). Note that this makes your overall point stronger, not weaker.

No post body was provided.

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

#190

Post by dustedcodes » Sat, Nov 05, 2022, 5:52 PM UTC

Hey author here! Sorry I didn't respond to any feedback yet. I've literally posted this before leaving my house and didn't think it would get many upvotes as it didn't get any votes the other day either.

Sorry that the general sentiment is "everything old gets new again". I didn't try to rehash some old news again. I basically blog about things that come up in my daily work life and this topic was something that I felt quite passionately about. From my own experience I felt that type systems, especially in modern languages, are not nearly as well utilised as they could be. Of course there is always a balance to strike, especially with over engineering and needless optimisations, but that is a topic for another blog post another day.