Question: isn’t a rich type system as described here similar to OOP?
No no no, entirely not. OOP need not be statically typed at all; see Smalltalk.
The type system is a programmer's best friend
31–40 of 467 posts
Re: The type system is a programmer's best friend
#32>A string value is not a great type to convey a user's email address or their country of origin. So we have a type for "country of origin". And then some country that you have in the records splits up into 2 countries, what do you do then? Do you keep a list of all countries that ever existed and keep it up to date? This approach works good in some cases, but not always
This problem has already been solved. Use something like https://en.m.wikipedia.org/wiki/ISO_3166-1_alpha-2 and get an authoritative list of countries / territories, including defunct ones like Yugoslavia and USSR. You still have to define the business logic of whether you want to keep a certain country record aligned with historical borders or with current borders, but that problem exists whether you have primitive type to represent countries or not...
Re: The type system is a programmer's best friend
#33Earlier quoted context omitted.
Is the alternative to sweep it under the rug? In a stringly-typed world, what happens - do you just hope for the best? In a typed world, the problem ("the real world has ceased to conform to the model") is at least made plain so that you can decide what to do with it, because the model is actually… modelled.
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.
Re: The type system is a programmer's best friend
#34Earlier 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…
> 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.
Re: The type system is a programmer's best friend
#35I 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…
FWIW that's a pretty basic application called "units of measure". Some languages like F# have that natively.
I wish static typing were as uncontentious as units of measure.
Re: The type system is a programmer's best friend
#36I 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…
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...
Re: The type system is a programmer's best friend
#37There is an important difference between types and objects: types are basic building blocks. An email is not a basic building block nor is money. In the mature ecosystem of Java there are libs and standard libraries that handles these problems some are even in the standard library (timestamp with timezone, url...) It would be nice to have stuff for these in the standard libraries but currencies are a moving target an…
> types are basic building blocks
Yes but they should also be compositional, one should build larger types from smaller types. This is how we scale to solving difficult problems.
> but currencies are a moving target and needs constant update to handle the quirks of the real world.
This is a separate issue orthogonal to types. The problem of modelling the real world and what models might be more generally useful. No model is perfect, all have trade-offs.
> In my book the string is a great way to store a country of origin
As an implementation using a string sounds pragmatic, but that should not be its type! You should still create a currency type and parse into it. Then you won't accidentally pass an arbitrary string to a parameter that is supposed to be a currency.
Re: The type system is a programmer's best friend
#38Earlier quoted context omitted.
FWIW that's a pretty basic application called "units of measure". Some languages like F# have that natively.
I wish static typing were as uncontentious as units of measure.
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.
Re: The type system is a programmer's best friend
#39>A string value is not a great type to convey a user's email address or their country of origin. These values deserve much richer and dedicated types
this is a classic case of not needing more types but needing proper names. Types as concretions, i.e. simply collections of data or functions are a terrible idea because they're static and don't accrete. Data in the real world always does. This becomes very obvious when you go down a paragraph and you see the conundrum:
>For example, let's have a second type called VerifiedEmailAddress. If you wish it can even inherit from an EmailAddress. I don't care, but ensure that there is only one place in the code which can yield a new instance of VerifiedEmailAddress
okay, and for the next email setup let's have a third type, and a fourth type, and a fifth type, and so on. The end result of this is a zoo of types that help nobody to understand anything. It reminds me of an older Rich Hickey talk. When you program a delivery truck you don't make a type for each different truck because of the contents of the truck, you just take your delivery out of the truck and you don't care about the rest.
Re: The type system is a programmer's best friend
#40The most successful languages are typed but weakly so. Just enough type system to avoid the biggest class of bugs, not enough to get in your way all the time. Golang strikes this balance very well. Too little typing, and your Python unit tests get too heavy to run after every commit. Too much, and you have to read a book on category theory before you can figure out how to grab that one field using Lenses in Haskel.
Edit: I should note this is coming from an outside observer as my most favorite languages are dynamically typed like Python and Lisp. But it should also be noted that I like writing in small code bases. Larger ones tend to need typing.