Hacker News Reader

Comment by mechanical_fish | Hacker News Reader

The convention you refer to is "Hungarian Notation", and Spolsky's essay on the subject is required reading before you get too vehement about it's stupidity. Basically, it started out as a relatively useful convention, then got misunderstood and misapplied and morphed into a ridiculous version of itself.

I wonder sometimes if the same thing has happened to type safety. I'm not convinced it is a bad idea, actually. I am convinced that it's not well-served by having Java as it's poster child. If my mental picture of a type-safe language is something that reads like this, no wonder I'm inclined to think it's overrated.

View on HN

The ideas behind hungarian are sound, but one of the reasons the name 'hungarian' stuck was that the names were unpronounceable.

Modern IDEs make that whole thing moot anyway, but the notation is still being used afaik.

There is nothing wrong with type-safety per se, it's just that when it gets to the point where it is literally 'in the way of progress' that things have been taken too far.

Ideally its something that's there when you need it, and override-able when you specifically don't need it.

That way you can do your type checking at compile time for the 70% or so of the code where that makes good sense, and where you're happy to have those guardrails to save you some time catching stupid bugs.

The other 30% of your code you can be as free as you want to be knowing full well that the price of failure would be a very angry end user.

That's because I think there are multiple 'modes' of programming, if you're writing a one-off data import script then type safety is just a real pain, as soon as you want to do that every day at a few thousand locations you'd better have it bullet proof.

Now you need two languages for those two situations.

This isn't Java, this is C#. (In Java this would be more verbose).

I'm aware of that. I chose to pick on Java because I assume, perhaps too generously, that the C# designers are constrained by the need to market their language to Java developers, such that when Java heads over a cliff the C# folks are obliged to follow, though perhaps with a more elegant series of aerial stunts on the way down.

The risk is that I unfairly maligned Java, a language which I do not know well anymore, since I abandoned it about when it started to look like this. But according to you I'm being too generous to them as well. :)

>the C# designers are constrained by the need to market their language to Java developers

that was true only up to about C# 2.0; Java is way, way behind nowadays.

> C# designers are constrained by the need to market their language to Java developers

No, because C# had generics before Java.

Oops. My ire is misplaced, then.

Well, the C# 2.0 specification was written in 2002, but the compiler was only released in 2005, a year after Sun released J2SE 5.0. So from a implementation perspective, Java had generics before C#.

I'm not sure if C#/Java's type-safety has morphed into a ridiculous version of itself. I suspect that there has been too little, rather than too much development in this regard. Type-inference and typedefs would go a long way of solving the excesses of type-safety, certainly in this case.

Java has no type safety, since every object can be null, and methods can't be called on null. This means your program can blow up at runtime due to type errors.

Reply on news.ycombinator.com