Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rule of Silence (2006)

linfo.org

Post reply on HN
Print view View original

131–140 of 318 posts

Re: The Rule of Silence (2006)

#131

Post by TeMPOraL »

qwertyuiop924 wrote: post #112
TeMPOraL wrote: post #101

Earlier quoted context omitted.

That's my primary issue with UNIX culture. It took a huge step backwards by deciding to work with unstructured text. It wasn't a wrong turn , mind you. It was backtracking on known and understood best practices all the way and then picking a wrong turn. And only now people seem to rediscover what was in common use in the era before UNIX - the virtues of structured text. I guess our industry is meant to run in circles…

Structured text is good. Very good, in fact. It might even be idea. structured binary data , less so, at least as a storage format. I want to be able to look at your file format using tools that haven't been specialized to the task. Is that so wrong?

Well, I'm advocating for structured text, not binary. Mostly because I haven't seen a future-proof binary format yet, and editing binary formats indeed would require special tooling. I think - for a data exchange protocol meant to be used between many applications - going structured text instead of binary is a worthwhile tradeoff of little lower efficiency vs. much better accessibility.

EDIT: Some comments here are slowly making me like the idea of a standard structured binary more and more.

Re: The Rule of Silence (2006)

#132

Post by xg15 »

qwertyuiop924 wrote: post #112
TeMPOraL wrote: post #101

Earlier quoted context omitted.

That's my primary issue with UNIX culture. It took a huge step backwards by deciding to work with unstructured text. It wasn't a wrong turn , mind you. It was backtracking on known and understood best practices all the way and then picking a wrong turn. And only now people seem to rediscover what was in common use in the era before UNIX - the virtues of structured text. I guess our industry is meant to run in circles…

Structured text is good. Very good, in fact. It might even be idea. structured binary data , less so, at least as a storage format. I want to be able to look at your file format using tools that haven't been specialized to the task. Is that so wrong?

Yes, because it's: a) inefficient b) invites a lot of wrong assumptions about the storage format, e.g. about the underlying grammar, the maximum length of tokens or the possible characters than could occur in the file. c) requires you to solve the same problems over and over again (how to represent nested lists, graphs, binary blobs, escaped special characters, etc) d) encourages authors to roll their own format and not research if there maybe is an existing format that would solve their case.

I agree with you, the other extreme - treat binary files as sort of opaque black boxes that you can only access with specialized tools beloniging to your application - is even worse. But I don't see why we can't reach some middle ground: have a well-documented, open, binary format that encodes a very generic data structure (maybe a graph or a SQLite-style database) and a simple schema language that lets you annotate that data structure. Then you can develop generic tools to view/edit the binary format even though every application can use it in their own way.

Re: The Rule of Silence (2006)

#133

Post by ygra »

Pxtl wrote: post #120
skrebbel wrote: post #80

Earlier quoted context omitted.

In 1993, someone made exactly your argument a in Redmond board room, and so many people agreed that what you describe could be adequately called "The Windows Philosophy". All settings in a database and not text files (the registry); a command-line that pipes data, not text (PowerShell). Tailored UIs to change settings, not magic invocations and obsure text file syntaxes. I guess most developers on HN are also aware o…

The simple fact that the Registry doesn't have comments is ludicrous.

What database has?

To clarify: The registry is a database for OS or application stuff (caches, settings, etc.). It's not meant to be user-editable and outside arcane trouble-shooting stuff you're unlikely to ever have to venture in there.

Re: The Rule of Silence (2006)

#134

Post by setq »

Pxtl wrote: post #124
Chris2048 wrote: post #89

Earlier quoted context omitted.

The windows registry is not too bad. You can easily store this stuff in a SQLite file though: https://www.sqlite.org/appfileformat.html PowerShell' object-oriented nature is great btw!

Around the office when teaching PowerShell we say it takes about two Googles per line. That's not a compliment.

This is in line with my experiences with powershell (or powershit as we refer to it).

The canonical example of the complete failure and total friction is in the simple case of obtaining a file from a web server and sticking it on disk. This is the steps:

1. Try various built in cmdlets. Eventually find one that works.

2. It's a big file and gets entirely buffered in RAM and takes the machine out. You don't get the privilege of finding this out until you try dragging a 20GiB vhdx image from a build server to plonk on your SCVMM platform. That conks it completely.

3. So you think you'll be clever and just use curl. Oh no there's a curl alias!

4. Every damn machine gets sent a reconfig to remove this stupid alias.

5. Then when you do get there you find that the curl output pipe just pukes multibyte garbage out. 20GiB of it that took a long time to come across the wire.

6. You tell curl to save the file directly. Might as well have used cmd.exe by now!

So 8 Googlings and 3 hours later you got a fucking file. Every time I use powershell that is my life.

Re: The Rule of Silence (2006)

#135

Post by ygra »

Pxtl wrote: post #124
Chris2048 wrote: post #89

Earlier quoted context omitted.

The windows registry is not too bad. You can easily store this stuff in a SQLite file though: https://www.sqlite.org/appfileformat.html PowerShell' object-oriented nature is great btw!

Around the office when teaching PowerShell we say it takes about two Googles per line. That's not a compliment.

How many Googles per line do Unix shell scripts need, assuming equal familiarity with both? As for me, I understand PowerShell fairly well, but hate having to deal with Unix utilities and for me the amount I have to google to get stuff done on a Unix command-line is significantly higher than with PowerShell.

It's just that once you learn how to use a tool you don't have to think about how to approach a problem anymore, you just do it. And then, when learning a completely different tool you have to learn again. Surprise.

Re: The Rule of Silence (2006)

#136

Post by TeMPOraL »

taneq wrote: post #130
TeMPOraL wrote: post #101

Earlier quoted context omitted.

That's my primary issue with UNIX culture. It took a huge step backwards by deciding to work with unstructured text. It wasn't a wrong turn , mind you. It was backtracking on known and understood best practices all the way and then picking a wrong turn. And only now people seem to rediscover what was in common use in the era before UNIX - the virtues of structured text. I guess our industry is meant to run in circles…

It's not like unstructured piped text is the only possible way to work. It's widely used precisely because it's so expedient. If you use structured data, then every program in the sequence has to understand the structure. If you just smash everything flat into a stream of text, you can then massage it into whatever form you need. It's not always the best way to approach a problem, but it's not meant to be. It's duct…

If you use structured data in a standard format, you can have a single system-wide implementation of a parser and then have each program process the data it needs, already structured in a semantically-meaningful way.

In current, unstructured text reality, each program has to have its own (usually buggy, half-assed) shotgun parser, and it has to introduce semantic meaning back to the data all by itself. And then it destroys all that meaning by outputting its own data in unstructured text.

It works somewhat ok until some updated tool changes its output, or you try and move your script to a different *nix system.

Re: The Rule of Silence (2006)

#137

Post by borplk »

qwertyuiop924 wrote: post #112
TeMPOraL wrote: post #101

Earlier quoted context omitted.

That's my primary issue with UNIX culture. It took a huge step backwards by deciding to work with unstructured text. It wasn't a wrong turn , mind you. It was backtracking on known and understood best practices all the way and then picking a wrong turn. And only now people seem to rediscover what was in common use in the era before UNIX - the virtues of structured text. I guess our industry is meant to run in circles…

Structured text is good. Very good, in fact. It might even be idea. structured binary data , less so, at least as a storage format. I want to be able to look at your file format using tools that haven't been specialized to the task. Is that so wrong?

It's only "specialized" because we haven't been doing it so it's considered special.

At some point you have to admit that what's meant for the computer is not always byte by byte the same as what's meant for the human.

We try to shove these two together and we screw up both of them.

Empower the computer to be the best that it can be by taking the human out.

Empower and respect the human by giving him/her their own representation.

The "I just want to read the bytes that are on disk" philosophy is inherently limiting and broken when the audience are two very different things (humans vs computers).

My argument is that instead of fighting that we must embrace it.

Re: The Rule of Silence (2006)

#138

Post by TeMPOraL »

setq wrote: post #134
Pxtl wrote: post #124

Earlier quoted context omitted.

Around the office when teaching PowerShell we say it takes about two Googles per line. That's not a compliment.

This is in line with my experiences with powershell (or powershit as we refer to it). The canonical example of the complete failure and total friction is in the simple case of obtaining a file from a web server and sticking it on disk. This is the steps: 1. Try various built in cmdlets. Eventually find one that works. 2. It's a big file and gets entirely buffered in RAM and takes the machine out. You don't get the pr…

Well, for many years I had that experience every time I tried to use UNIX command line. I think it's just the issue of familiarity.

Re: The Rule of Silence (2006)

#139

Post by ptero »

borplk wrote: post #74

To play devil's advocate, part of the reason things like The Rule of Silence are talked about is because of the messy unix philosophy of treating everything like plain text. If structured data was embraced we would have developed appropriate tooling to interact with it in the way that we prefer. This runs very deep in unix and a lot of people are too "brainwashed" to think of other ways. Instead they develop other ex…

Your complaints are, IMO, orthogonal to the UNIX philosophy (which, IMO, is also pretty orthogonal to the rule of science; now I have upset both sides :) ).

UNIX philosophy is, as written in the article, is based on programs that do one thing well and work with other programs. The second part, "work with other programs" is the one that encourages (but not requires) simple, text based I/O.

If A, B and C write programs and independently design some custom, structured, binary I/O the chance of them being compatible is nil. If they output text, the UNIX glue of pipes and text conversions makes them cooperate quickly and efficiently. Not elegant? Sure. But working well in no time.

Re: The Rule of Silence (2006)

#140

Post by tsukikage »

bjourne wrote: post #24

It's often a stupid rule. If you have a process that is stuck, you type "kill " to kill it. But kill doesn't tell you if the process was killed or not, so you have to double-check with "ps " to see if it is still alive. If it is, you try again with "kill -9 ". I suspect the reason is that for most signals, kill can't determine if the signal was acted upon or not. But for KILL and TERM it could wait a few milliseconds…

> "those who are saying that I can write a wrapper script is missing the point"

No, it is exactly the point.

Unix gives you Lego pieces to build things from.

A bunch of small Lego pieces you can join however you like is way more useful than a giant chunk of Lego that someone has glued together into whatever lump they happened to need that day.

When you ask why your Lego bucket didn't ship with pieces preglued into exactly the combination you want today, people absolutely will reply saying you have all the pieces you need and you can just join them yourself.

Because that is the entire point of Lego.

If that wasn't what you wanted, perhaps consider a different kind of toy?

Post reply on HN