🚀 go-pugleaf

On 8 Jan 1996, Joachim Durchholz wrote:

> I think HN is inappropriate for languages where you can change the  
> representation of a type behind the scenes, simply because it's impossible  
> to invent an abbreviation for every type that shows up in a project.

In a way, you almost have it exactly right here, but it isn't the language 
that is the deciding factor--it is the environment of the language.  When 
you run your programs in an environment where you must pass information 
from one program to another, type checking is not applicable so a 
notation is necessary to remind programmers (especially when they are 
doing low-level stuff as is often necessary when moving data between two 
programs) what type they should be using.  When I call the Windows API, 
it is nice to see that the variable name is lpsz.... when the type is a 
generic POINTER that could point to anything.  When I save data in a file 
that could be read by an Intel based implementation of Modula II or 
Pascal, a MIPS version of C, or an embedded system running code developed 
in Ada, it is nice to know that they all expect an i16... (or however the 
notation says int16 should be prefixed).  However, when I don't have to 
do this, I let the compiler clue me in.

> In my experience, such languages actually don't need HN; the compiler will  
> catch all errors that HN is supposed to help avoid. This is because in  
> these languages, the type of a variable or value precisely defines what  
> operations are admitted for it. If you had a type zero-terminated-string  
> in such a language, the compiler won't allow you to pass this to a routine  
> that expects a string with a length descriptor.