Making Wrong Code Look Wrong (2005)

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.

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

Cromulent made the OED last year: https://public.oed.com/updates/new-words-list-june-2018/

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.

> No compiler can know that a string variable is a "name" or a "password".

In pretty much any language supporting user-defined types and/or type aliases, types can be used for that information (with aliases, providing documentation the same as hungarian notation does; with real types, providing the possibility for enforced protection against accidental misuse.)

But the article doesn't actually use hungarian notation for that kind of thing, it uses it for traits that are not "what it does", but instead metadata analogous to Ruby's "taint". Which, again, is something easily encoded in typing, in a static language, either as a core feature of typing or via user-defined (possibly wrapper, depending on other features of the type system or general language semantics) types; type aliases, even, would work as well as hungarian notation, but using actual types lets you put guarantees in place rather than just providing documentation.

Hungarian notation solves one problem: it makes wrong code look wrong.

Type alias can also do that, but they can do so in a way where correctness can be statically enforced.

As an example, let’s say you have a Write function like in the article, but it only takes an HTMLString, which can’t implicitly be casted from String. Then, you can have Encode return an HTMLString, but take a String. Finally, you can use static analysis to only allow whitelisted functions to construct non-literal HTMLStrings (so anyone could do a literal of HTML, but every other usage would require encoding or whitelisting.)

This is a bit rudimentary of an example, but it is widely used in practice.

Here is a safe type used in Closure:

https://google.github.io/closure-library/api/goog.html.SafeH...

Actually it can, you just have to define types for it.

In Scala you have value class, that get replaced by the underlying type during compilation so there is no overhead.

https://ivanyu.me/blog/2014/12/14/value-classes-in-scala/

It may sounds a hassle but you only have to handle it at the interfaces (for example for a web app in the controller and data layer), in the rest of the code you just manipulate your value like any other type.

But type is a machine-readable way to say what a variable does or is. A compiler can certainly know a name from a password if its type support is versatile enough and you use separate types for them. Or, for example, for things like "unchecked C string", "valid UTF-8 C string", "NKFD-normalized UTF-8 C string", etc. A separate type for password may be a jolly good idea with a logging system you can dump any data to; you certainly wouldn't want it to log passwords.

Using prefixes is a poor man's type system, a loose convention to be enforced by humans, while with types it would be a machine-readable and enforceable requirement.

In Go:

type Password string type Name string

func SayHello(name Name) { fmt.Println("Hello %s",string(name)) }

func Login(password Password) bool { if bcrypt.magicstuff([]byte(password)){ return true } log.Println("error: wrong password: ", string(password)) return false }

Now the type system does know whether it's a name or a password, and will throw a compiler error if you try to use the wrong one in the wrong place.

edit: really HN, no code formatting options? :(

I fully agree that the types offered by the programming language (wrapping the underlying types) are not enough. However, a static type language allows you to define your own types. So (as your sibling comment by brundolf suggests) you can create your own types around the existing types such as HtmlEscapedString and UntrustedUserEnteredString. The syntax is particularly convenient in Rust, but you can do the same in e.g. Java, or any other statically typed language, albeit more verbosely:

    class HtmlSnippet {
        public String html;
        ....
    }

    void setWidgetContents(HtmlSnippet s) { .. }

    void foo() {
        // Compile error
        setWidgetContents(request.getParam("foo"));
    }

You’ll be glad to learn that there is absolutely no overhead in execution time or memory consumed (and a minuscule one in compilation time).

> variants of stuff like "Apps Hungarian" are often a lightweight and practical solution in any language.

Except in an untyped language, the type system usually presents a better solution with no more effort than “Apps Hungarian”, and for many cases even without static typing you can enforce rules rather than do advisory annotations with similar effort (e.g., for the specific unsafe-data case addresses in the article, a Ruby's taint system.)

> Also, if operators overloading is what freaks you out, try writing code heavy on matrix/vector/tensor algorithms without it...

While overloading may be ideal for some subset of that, and tolerable for a larger subset, I think what that really calls for is more custom operator definition as supported I Haskell, Scala, Raku and some others more than overloading.