5 ms·

Most modern typed languages support encoding this information in the type of the variable, so that the compiler catches it, instead of in the variable name. Ale

Most modern typed languages support encoding this information in the type of the variable, so that the compiler catches it, instead of in the variable name. Alexis King wrote a blog post about it that reached the front page a few days ago. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

pwdisswordfish2 7y ago
SMALL BRAIN: Hungarian notation is stupid and just duplicates the work of the type system NORMAL BRAIN: Systems Hungarian may be silly, but Apps Hungarian has some merit GALAXY BRAIN: Apps Hungarian is stupid and just duplicates the work of the type system
- imagin8or 7y ago
  Yes, though the notation approach is worth following if you cannot use the type system (lang doesn't support it, or incurs unacceptable performance or complexity overhead). But yeah, zero cost compiler magic is the reason Rust is so good.
  - partyboat1586 7y ago
    I'll be using it in my JavaScript extensively. Very useful in languages with useless type systems.
    - gautam1168 7y ago
      Are you sure you cannot handle this using conditional types in typescript?
  - marcus_holmes 7y ago
    Any typed language can do this, not just Rust ;)
- devicetray0 7y ago
  > GALAXY BRAIN: Apps Hungarian is stupid and just duplicates the work of the type system Is this correct? From the article, Apps Hungarian represents your intent for the var (the kind), not the type. Systems Hungarian represents the type (duplicative).
  - dmitshur 7y ago
    He meant that the intent (kind) can be factored into the type system too. Instead of using type string for both “unsafe string” kind and “safe string” kind, you’d use two different types. So the type system aka compiler can catch a mistake, in addition to your eyes. For example, see https://talks.golang.org/2012/goforc.slide#43 https://talks.golang.org/2012/goforc.slide#43.
    - devicetray0 7y ago
      Oh I see. Thank you!
j1elo 7y ago
Very interesting, thanks for the link. Also, another instance of the word "cromulent" cropping up! Springfield teachers would be proud of their feat. https://www.merriam-webster.com/words-at-play/what-does-cromulent-mean https://www.merriam-webster.com/words-at-play/what-does-crom... (Edit: Add link)
- dzdt 7y ago
  Cromulent made the OED last year: https://public.oed.com/updates/new-words-list-june-2018/ https://public.oed.com/updates/new-words-list-june-2018/
  - j1elo 7y ago
    Amazing. I'm not a native speaker so I didn't follow the language's changelog... thanks for the info!
BoiledCabbage 7y ago
Also this: Making illegal states unrepresentable https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/ https://fsharpforfunandprofit.com/posts/designing-with-types...
jimbo1qaz 7y ago
I currently use a mix of thin typedefs (using ClockT = uint32_t, the compiler doesn't catch mixups) and putting units in variable names. I've used this approach in Python, Rust, and C++, and in over 1 year have had zero bugs that could've been caught via compiler-enforced units. (I don't know if this approach will work for others though.) I've tried using a unit system library in Rust, for audio programming. It was not worth it for me. I had to define types for clock cycles, audio sample durations, and amplitudes. Then cycles per second and samples per second were expressed as ratios. Then you need (cycle / second) to have type (cycles per second). The typenum-based error messages were dreadful. And also you sometimes need to use different base numeric types used to store these dimensioned quantities. And also write extra typecasts to box and unbox between unit-wrapped quantities and plain integers.
hota_mazi 7y ago
Did you read the article? The correct way of doing Hungarian Notation, as demonstrated in this article, is to encode in the name of the variable what it does, not its type. No compiler can know that a string variable is a "name" or a "password".
- lifthrasiir 7y ago
  It still might be possible to have types like `UserId` or `UserCredential`, which get parsed at the request time and never roll back to plain strings. It is evident that they are indeed different subtypes of strings: user identifiers can't have a space for example. That said, I generally agree that conventional type systems are not (yet) capable of encoding all those informations to a type. I prefer a mix of actual types and coding conventions for the practical matter.
  - usrusr 7y ago
    As a thought experiment, I like to assume that there is a hypothetical language where everything is encoded in types, to the point where you don't have or need variable names anymore. Every typed language (and programming style) we use is some point in the spectrum of practical compromises between that hypothetical language where all pre-runtime information is in formal types and scripting languages where all pre-runtime information is in informal names. Java for example has to leave quite a lot of that information in names because there are no type aliases and final types exist.
  - touisteur 7y ago
    I'm curious what type of capabilities are lacking in the Ada or the F# type system to handle this. You can create 'new' (hear incompatible) types instead of subtypes and they won't be affectable to each other. So type User_Id_Type is new String; type User_Credential_Type is new String; Then in your request deserializer convert once from String to the correct type, and at the use site only allow taking the correct type? You can also add static predicates to ensure User_Id_Type doesn't contain spaces. You can also make the type 'opaque' and it won't be possible to convert to a String without a bespoke interface. I'm not sure what's missing. I almost feel like it would be a great challenge :-)

pwdisswordfish2 7y ago

SMALL BRAIN: Hungarian notation is stupid and just duplicates the work of the type system NORMAL BRAIN: Systems Hungarian may be silly, but Apps Hungarian has some merit GALAXY BRAIN: Apps Hungarian is stupid and just duplicates the work of the type system

imagin8or 7y ago
Yes, though the notation approach is worth following if you cannot use the type system (lang doesn't support it, or incurs unacceptable performance or complexity overhead). But yeah, zero cost compiler magic is the reason Rust is so good.
- partyboat1586 7y ago
  I'll be using it in my JavaScript extensively. Very useful in languages with useless type systems.
  - gautam1168 7y ago
    Are you sure you cannot handle this using conditional types in typescript?
- marcus_holmes 7y ago
  Any typed language can do this, not just Rust ;)
devicetray0 7y ago
> GALAXY BRAIN: Apps Hungarian is stupid and just duplicates the work of the type system Is this correct? From the article, Apps Hungarian represents your intent for the var (the kind), not the type. Systems Hungarian represents the type (duplicative).
- dmitshur 7y ago
  He meant that the intent (kind) can be factored into the type system too. Instead of using type string for both “unsafe string” kind and “safe string” kind, you’d use two different types. So the type system aka compiler can catch a mistake, in addition to your eyes. For example, see https://talks.golang.org/2012/goforc.slide#43 https://talks.golang.org/2012/goforc.slide#43.
  - devicetray0 7y ago
    Oh I see. Thank you!

j1elo 7y ago

Very interesting, thanks for the link. Also, another instance of the word "cromulent" cropping up! Springfield teachers would be proud of their feat. https://www.merriam-webster.com/words-at-play/what-does-cromulent-mean https://www.merriam-webster.com/words-at-play/what-does-crom... (Edit: Add link)

dzdt 7y ago
Cromulent made the OED last year: https://public.oed.com/updates/new-words-list-june-2018/ https://public.oed.com/updates/new-words-list-june-2018/
- j1elo 7y ago
  Amazing. I'm not a native speaker so I didn't follow the language's changelog... thanks for the info!

BoiledCabbage 7y ago

Also this: Making illegal states unrepresentable https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/ https://fsharpforfunandprofit.com/posts/designing-with-types...

jimbo1qaz 7y ago

I currently use a mix of thin typedefs (using ClockT = uint32_t, the compiler doesn't catch mixups) and putting units in variable names. I've used this approach in Python, Rust, and C++, and in over 1 year have had zero bugs that could've been caught via compiler-enforced units. (I don't know if this approach will work for others though.) I've tried using a unit system library in Rust, for audio programming. It was not worth it for me. I had to define types for clock cycles, audio sample durations, and amplitudes. Then cycles per second and samples per second were expressed as ratios. Then you need (cycle / second) to have type (cycles per second). The typenum-based error messages were dreadful. And also you sometimes need to use different base numeric types used to store these dimensioned quantities. And also write extra typecasts to box and unbox between unit-wrapped quantities and plain integers.

hota_mazi 7y ago

Did you read the article? The correct way of doing Hungarian Notation, as demonstrated in this article, is to encode in the name of the variable what it does, not its type. No compiler can know that a string variable is a "name" or a "password".

lifthrasiir 7y ago
It still might be possible to have types like `UserId` or `UserCredential`, which get parsed at the request time and never roll back to plain strings. It is evident that they are indeed different subtypes of strings: user identifiers can't have a space for example. That said, I generally agree that conventional type systems are not (yet) capable of encoding all those informations to a type. I prefer a mix of actual types and coding conventions for the practical matter.
- usrusr 7y ago
  As a thought experiment, I like to assume that there is a hypothetical language where everything is encoded in types, to the point where you don't have or need variable names anymore. Every typed language (and programming style) we use is some point in the spectrum of practical compromises between that hypothetical language where all pre-runtime information is in formal types and scripting languages where all pre-runtime information is in informal names. Java for example has to leave quite a lot of that information in names because there are no type aliases and final types exist.
- touisteur 7y ago
  I'm curious what type of capabilities are lacking in the Ada or the F# type system to handle this. You can create 'new' (hear incompatible) types instead of subtypes and they won't be affectable to each other. So type User_Id_Type is new String; type User_Credential_Type is new String; Then in your request deserializer convert once from String to the correct type, and at the use site only allow taking the correct type? You can also add static predicates to ensure User_Id_Type doesn't contain spaces. You can also make the type 'opaque' and it won't be possible to convert to a String without a bespoke interface. I'm not sure what's missing. I almost feel like it would be a great challenge :-)