Hacker News Reader

Comment by oroul | Hacker News Reader

Isn't UNIX a clear example of people not engaging in architecture "astronaut" behavior? It was designed to be as simple as possible - in stark contrast to Multics.

View on HN

I would say Unix is a system designed to be simple and powerful. It takes a lot of thinking to achieve a system which is both simple AND powerful. Whereas things like XML and Multics are powerful they can do everything but they are not simple. In the end that limits their power because they are hard to learn and things built with them are difficult to understand, because they are not simple. And when something is hard to understand it is also error-prone, and such a system is fragile.

It takes "astronauts" who think hard about the architecture to come up with systems that are simple and powerful at the same time.

>Whereas things like XML and Multics are powerful they can do everything but they are not simple.

the original XML Spec is pretty simple https://www.w3.org/TR/xml/

even if you add in namespaces - still simple https://www.w3.org/TR/xml-names/

The difficulty in XML really came with XML Schemas and the need to wind that in every subsequent spec.

“It was designed” - that’s the key. We all know how hard it is to make things simple. That doesn’t come naturally. Hardest stuff I’ve ever done is to go through complexity to reach what is simple. (Definitely paraphrasing someone else there.)

Right now I have a project of potentially infinite complexity and we need to build really fast. A lot of my focus has been finding the very few pieces of bedrock and fixing on those, allowing the rest to vary as our appetite for complexity grows. Start today with an achievable goal, test hypotheses, don’t paint ourselves into a corner. All team comments are how simple it is. That’s by...design.

Simplicity does not contradict architecture. For some (me included), it is even the essence of it. Leave out the bells and whistles. This is why JSON is so successful, even though we had XML long ago. Technology should be more of that, and I would consider it superior architecture.

"Everything is a file" seems comparable to "everything is a message".

It's the thing with abstractions: changing angle changes the abstraction by seemingly replacement candidates, but only the good ones maps properly onto physical hardware and human cognition.

eg: "everything is a file" maps properly to both physical storage with addressable, streamable content and to the human mind as data reachable by classification (file name). Maybe a revolutionary OS design could better that with "everything is a message", but I think you can understand why one can have doubt on this translation from files.

The difference between a file and a message is that a file does not prescribe format of the file - it's usually application dependent, but is understood to be plain text.

A "message" tends to have formats associated with it (which is what differentiate it from being just a "file" that's transferred via a protocol). These formats, like JSON, or xml, or whatever new fangled formats kids these days use, now requires architectural astronauting; namely, common field names, or standards, so that different programs would parse them similarly. And now you'd want schemas for those formats, and automatic parser generated for those formats, and more and more...

> but is understood to be plain text

It's not. Plenty of Unix tools work with binary files.

> A "message" tends to have formats associated with it

It doesn't. At least, not any more than a "file" tends to have formats associated with it.

There is the whole worse is better thing too

Reply on news.ycombinator.com