The first FORTRAN versions encoded the type of a variable or function in the initial letter of its name: I, J, K, L M and N for integer, other letters for floating-point numbers.
The first BASIC versions encoded the type of a variable or function in its suffix, no suffix for floating-point and $ for strings. Some later BASIC variants used the suffix % for integers.
The Hungarian notation was just an extension of the methods used decades earlier in languages like FORTRAN and BASIC.
Even if I started writing computer programs with FORTRAN, COBOL and BASIC, I still do not like the Hungarian notation or any other method of explicitly encoding the type of a variable in its name.
In order to use correctly a variable you need to know more than its type. If your only mistake is to use it where its type is not suitable, that will be caught immediately by the compiler. Nowadays, with any decent text editor intended for programming, clicking or hovering over an identifier will provide information about its type and possibly more than that, e.g. showing its complete definition (which might include a useful comment about its purpose).
The only naming restriction that I find reasonable is that used in many C/C++ programs, where variable names and function names use lower case, constant names and macro names use upper case and type names or class names use mixed case.
With multidimensional arrays a.k.a. tensors, it is frequently possible to describe computations with generic formulae that do not depend on the number of dimensions or on the limits for each dimension, as demonstrated by APL and languages inspired by it.
Specializing the description of a computation to work only for certain tensor shapes is a regression going back towards poor languages like Pascal, where it was impossible to write generic linear algebra functions that operated on arrays of different sizes.
The ugly and excessively complex syntax of templates in C++, which is caused by the requirement of backwards compatibility with a language not designed for generic programming, has caused some negative bias in many programmers against generic programming.
Nonetheless, generic functions and procedures, i.e. writing a single program from which the compiler will generate multiple instances specialized for various data types, are an essential tool for enhancing programming productivity. This remains as valid today as ever, even for the programmers who delegate the writing of the non-essential parts of a program to an LLM.
A decent programming language must provide simple means for writing generic functions. Ada (which supported generic packages and generic subprograms long before C++) is a better model for this than C++. Using the Hungarian notation goes in the opposite direction, as it is a blocker for writing generic functions.
An invented C notation: for an array item Fubar, I had iFubar as the index, rFubar for the array itself, nFubar as its length, pFubar as a pointer to any Fubar, aFubar as a Fubar passed in as an argument. "Works for me."
I think that rules like this, for generating systematically a set of related identifiers, are fine, unlike the Hungarian notation, where there is no connection between identifiers that have a common prefix, except for sharing a data type.
We've reinvented hungarian notation from first principles https://en.wikipedia.org/wiki/Hungarian_notation
The first FORTRAN versions encoded the type of a variable or function in the initial letter of its name: I, J, K, L M and N for integer, other letters for floating-point numbers.
The first BASIC versions encoded the type of a variable or function in its suffix, no suffix for floating-point and $ for strings. Some later BASIC variants used the suffix % for integers.
The Hungarian notation was just an extension of the methods used decades earlier in languages like FORTRAN and BASIC.
Even if I started writing computer programs with FORTRAN, COBOL and BASIC, I still do not like the Hungarian notation or any other method of explicitly encoding the type of a variable in its name.
In order to use correctly a variable you need to know more than its type. If your only mistake is to use it where its type is not suitable, that will be caught immediately by the compiler. Nowadays, with any decent text editor intended for programming, clicking or hovering over an identifier will provide information about its type and possibly more than that, e.g. showing its complete definition (which might include a useful comment about its purpose).
The only naming restriction that I find reasonable is that used in many C/C++ programs, where variable names and function names use lower case, constant names and macro names use upper case and type names or class names use mixed case.
With multidimensional arrays a.k.a. tensors, it is frequently possible to describe computations with generic formulae that do not depend on the number of dimensions or on the limits for each dimension, as demonstrated by APL and languages inspired by it.
Specializing the description of a computation to work only for certain tensor shapes is a regression going back towards poor languages like Pascal, where it was impossible to write generic linear algebra functions that operated on arrays of different sizes.
The ugly and excessively complex syntax of templates in C++, which is caused by the requirement of backwards compatibility with a language not designed for generic programming, has caused some negative bias in many programmers against generic programming.
Nonetheless, generic functions and procedures, i.e. writing a single program from which the compiler will generate multiple instances specialized for various data types, are an essential tool for enhancing programming productivity. This remains as valid today as ever, even for the programmers who delegate the writing of the non-essential parts of a program to an LLM.
A decent programming language must provide simple means for writing generic functions. Ada (which supported generic packages and generic subprograms long before C++) is a better model for this than C++. Using the Hungarian notation goes in the opposite direction, as it is a blocker for writing generic functions.
An invented C notation: for an array item Fubar, I had iFubar as the index, rFubar for the array itself, nFubar as its length, pFubar as a pointer to any Fubar, aFubar as a Fubar passed in as an argument. "Works for me."
I think that rules like this, for generating systematically a set of related identifiers, are fine, unlike the Hungarian notation, where there is no connection between identifiers that have a common prefix, except for sharing a data type.
Point taken. Although perhaps a lot of the dislike of Hungarian notation is all those odd prefixed alpha-bits.
Reminds me of the "Named Tensor" experiment in PyTorch from a while ago. https://docs.pytorch.org/docs/2.12/named_tensor.html