Hacker News Reader

Comment by mpweiher | Hacker News Reader

With all due respects to Stanley Elkin:

No, annoying is not good. Annoying is annoying.

Computer languages are there for me to get things done, not to get in my way. Attempts to force good behavior invariably fail. Burn some more midnight oil to figure out how the language/library can deal with it.

I once saw someone write that the 1st and foremost goal of a language was to disallow mistakes. That's nonsense. If it were, all we'd have to do is make a non-functional programming language that can't do anything. So I guess sort of the next step in functional programming?

View on HN

> Attempts to force good behavior invariably fail.

Except this isn't forcing good behavior, it is forcing being explicit. Go ahead and use `!` it will work like you are used to.

> No, annoying is not good. Annoying is annoying.

Different strokes for different folks. I for one think avoiding ambiguity is good given the ratio of code written to code read that most developers experience in their day to day lives.

> I once saw someone write that the 1st and foremost goal of a language was to disallow mistakes.

You are misinterpreting that requirement. What you are doing is you are forcing the choice to be made when you write the code. More flexible compilers make the choice when designing the language.

Many people believe that you know best when writing the code so stopping you there to correct it makes you avoid problems in the future, that is what "disallow mistakes" means.

As I said it is perfectly valid to instead say "I think the writers of the compiler have good enough defaults for these situations" but I for one don't trust them that much.

>Except this isn't forcing good behavior, it is forcing being explicit. Go ahead and use `!` it will work like you are used to.

That's not correct. `!` will crash without recourse where ObjC simply ignores the message and Java raises a catchable NPE.

If you actually do a null check all of the languages work the same. Since in all but the prototype cases you will be doing a null check does it really matter?

> ObjC simply ignores the message

Don't quote this like a benefit please, it is a horrendous design.

> Java raises a catchable NPE

Only difference between this and a crash is in theory you can log. In the majority of cases a NPE is bringing you down anyway.

>> ObjC simply ignores the message >Don't quote this like a benefit please, it is a horrendous design.

Hmm..so the ? operator for optionals should removed from Swift?

If your NULL exception results in a 5am wake up call to debug... has that computer language now got in your way?

Does that happen to you? Hasn't happened to me.

Yes, it has happened to me that type errors (both NPE and ClassCastExceptions) caused problems in production that should have been prevented by a better type system.

The last back-end system I built[1] had 3 failures in a year. First was a JVM misconfiguration (JVM neophytes) so we ran out of memory. Second was a temporary network outage that caused us to get behind our feed without the network bandwidth to catch up. Third was user interface code that wasn't tested.

Considering the system it replaced had more like 3 failures a day, the reliability was seen as "pretty good", so much that our relationship with ops was essentially we drop a jar, they tell us nothing happened.

TDD for the win. Not sure how/where a better type system would have helped.

[1] http://link.springer.com/chapter/10.1007%2F978-1-4614-9299-3...

A better type system is a complement to unit testing/TDD/other techniques. It simply allows you to focus on other, more meaningful kinds of tests.

You can think of a better static type system as unit tests that the compiler writes for you. When you think of it, automating things is what computers are all about. Of course this won't cover all cases, but neither will the tests you write by hand.

Anyway, you asked if that sort of errors happens. I answered it does.

edit: the problem with arguments like "well, I write software with few bugs and I don't need a better type system" is that it's essentially "just don't write buggy software" in disguise, which is a discredited line of thought in software engineering. People doing TDD (and every other technique/tool you can think of, including strong static type systems) still write buggy software. It follows that you should be using every available tool that can help minimize bugs and enforce correctness. Relative to the criticality of the software you write, of course -- sometimes you just don't care if the software has bugs.

> A better type system is a complement to unit testing/TDD/other techniques.

I agree that it could be such a complement. I haven't seen it in practice.

>It simply allows you to focus on other, more meaningful kinds of tests.

Again, I have seen this claim made many times, and it seems plausible at first, but I don't think it actually holds and have seen no real evidence for it. I don't think I've ever written a test for a specific type. I write tests for values. This automatically tests for types as a side effect, because values tend to have types. So these less meaningful tests that the type system would render unnecessary don't exist in the first place, and checking for the types separately adds no value (well, epsilon) in terms of safety. (Yes, I know it does a proof over all possible values, but this doesn't seem to make a difference AFAICT)

Note that TFA is about Swift, and many things that are actually benign in Objective-C will crash Swift...with no recourse as there is no exception handling. So I am not getting how being strict adds to safety.

> Anyway, you asked if that sort of errors happens.

Actually, I asked whether that sort of error happens to you (the person I was responding to). My answer would be: write better code, TDD allows you to that in such a fashion that you have no NPEs at 5am in production (without redundant tests for types). Of course, in Objective-C, nils get ignored when messaged, so you actually have to actively cause a NPE. Sadly, some of Apple's APIs do so. In fact, CFRelease() even throws a SIGTRAP.

Reply on news.ycombinator.com