Features are faults redux | Hacker News Reader

Features are faults redux

tedunangst.com

47 pointsvog11 comments

Not directly tied, but another old simplifying call. And is considered by some as extremist. http://archive.is/YLh6I

This is a description of his method (by Jeff) http://www.ultratechnology.com/method.htm

Another look at his way (contemplating problems with patients until reaching a simpler solution - simple, not easy and rarely done nowadays) http://www.ultratechnology.com/mmeta.html

Also from Jeff about reducing layering http://www.ultratechnology.com/levels.htm

Note: All are Forth (the philosophy) oriented.

In my experience this post is right on - there are so many bugs in so many layers (especially where they intersect), that the logical conclusion is to reduce and simplify.

These ideas are also emerging in the form of Go (simple) / Clojure (immutable) where simplicity is the primary feature. My only wish is that OpenBSD had additional vendor support for open source drivers (ie Intel / AMD / NVidia) so that it's impact isn't so limited to servers, but desktops / client devices as well.

All these faults seem to me to be the result of inadequate use of types. So Go/Clojure are precisely the wrong response; the way forward is decent type systems (i.e. ML-family languages) and replacing stringly-typed unix pipes with something more structured.

> All these faults seem to me to be the result of inadequate use of types.

This was my first thought, too. The examples he showed were not particularily complex, but mostly badly designed interfaces between components.

A function that takes a string argument with special behaviour if the string starts with "|"? WTF? If course you have at least two parameters for that, or a sum type ("union" on stereoids). But if it is a pain to transport structured data throughout your program, the language encourages you to employ all these anti-patterns that will of course bite you, because this special behaviour is not obvious from the function signature.

I would love to see an implementation of `ls`, `grep`, and `pwd`, with said pipes, in such a typed system of tools. `grep` is likely the most complex b/c it must do string comparison and I'm unsure how you would do this with types. I'm looking forward to seeing how such a system could be built.

Hopefully you'd replace grep with using the actual structure of what you're looking for. I mean there are type-safe pipeline libraries (I use fs2 a fair bit), it's just a question of modelling the things you want from a filesystem (or similar structure). If you're giving up unix compatibility then there's not so much value gained from having the unix filesystem model. So a better point of comparison is to take a business problem that you would solve with grep/ls/what-have-you, and solve it with fs2/conduit/... instead.

I tend to agree on the importance of better type systems for achieving safety.

But Golang IMHO _is_ a step forward, albeit an unsatisfyingly weak one. It's displacing C and dynamic languages like Python, and it's at least safer than those.

What an interesting read. I also enjoy how the URLs display on hover. Stylin'.

> I also enjoy how the URLs display on hover. Stylin'.

Isn't this something browsers do by default anyway (except in smaller print)?

Sure, but I like the larger print. Maybe I'm just getting old. :)

For those wondering how he did that (like me), this is the relevant CSS part (formatted for better readability):

    a:hover::before {
      content: attr(href);
      position: fixed;
      bottom: 0px;
      left: 0px;
      ...
    }

Reply on news.ycombinator.com