Hacker News Reader

Comment by kmicklas | Hacker News Reader

The reason this is an implicit principle of the Unix philosophy is because the Unix philosophy is to be as lazy as possible as the tool-creator and push all complexity onto the tool-user. Thus we get things like Go, regular expressions, and null pointers.

People outside this school of thought don't finish their projects because their projects actually try to solve the underlying problems in computing, which are inevitably hard.

View on HN

Examples of underlying computing problems that are unsolvable if one follows the Unix philosophy? Keep in mind that it's often misunderstood what the primary tenets of the Unix philosophy are; your comment demonstrates you, too, have misunderstood.

What have I misunderstood?

What do null pointers have to do with the UNIX philosophy?

It's not on the stated list, but null pointers is a classic expedient unsafe shortcut for those too lazy to design a better type system. C is full of such shortcuts (c.f. Algol 68).

First of all, that has nothing to do with the UNIX philosophy, second of all, it has nothing to do with type theory. Anyone is perfectly capable of implementing a Maybe/Option/whatever type in C, allocating it on the heap (because you wouldn't be able to return it if it were stack-allocated), and then returning a pointer to it, whereupon C's actual type system would happily complain about mismatched types if you tries to use this type without deliberately accessing its internal members, at which point you're doing exactly as much intentional effort as if you used a convenient accessor macro that checks to make sure it's not the nil case. While I agree that C (and its type system) could be much better, fixing the problem is not quite as simple as "just design a better type system".

UNIX is a trademark; It's "the Unix philosophy", not "the UNIX philosophy."

> Anyone is perfectly capable of implementing a Maybe/Option/whatever type in C

C doesn't even have parametric polymorphism, I'm not sure how you're imagining this can be done.

Parametric polymorphism is needed to implement “Maybe” as a generic type that can be applied to another type, but you can implement individual concrete Maybe X types without it.

You could possibly use macro programming to do it “generically” at a level outside the type system.

> Anyone is perfectly capable of implementing a Maybe/Option/whatever type in C

1. No parametric polymorphism, but I'll let you move the goal post with us macro-ing a bunch of monomorphized nullable pointer types. It still sucks because

2. No static checks against nullable values in the non-Maybe case, no ergonomic pattern matching in the maybe-case

Moreover, let's be real. Nobody writes new C in a vacuum, and given that that ecosystem is very mature, there's no changing course now. But safety techniques are only as good as their weakest link---their use must be enforced everywhere. The damage is done and irreparable with C.

This is just wrong, and insulting; the Unix philosophy is not about laziness.

Reply on news.ycombinator.com