Live data from Hacker News

The Rule of Silence (2006)

linfo.org

281–290 of 318 posts

Re: The Rule of Silence (2006)

#281
post #133

Earlier quoted context omitted.

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.

Oracle, for one, has had it for a long time. "Use the COMMENT statement to add a comment about a table, view, materialized view, or column into the data dictionary." https://docs.oracle.com/cd/B19306_01/server.102/b14200/state...

Also PostgreSQL (since 7.0, released in 2000):

https://www.postgresql.org/docs/current/static/sql-comment.h...

Re: The Rule of Silence (2006)

#282

Earlier quoted context omitted.

With generic pretty-printing, your program output becomes generic. Compare the output of "df -h" vs the PowerShell equivalent "gdr -psprovider filesystem", for example. One provides the data in dense (easy to follow) rows, while the other spaces it out across the whole screen, leaving large gaps of empty space around some columns while also cutting off data in others. The difference is especially noticeable of you ha…

You can pretty easily pass it to select and get just the properties you care about, or you could output to a different format with the various out- commands. I find it pretty good as a shell.

Options to select output? Sounds like advice from the Rule of Silence.

But.

- People above were just complaining about having to use sed to tweak output. I don't see why they would prefer a built-in filter to an external one. The external filter is far more flexible, and if that isn't enough, you can replace it.

- I'm generally not a fan of applications that tailor their output to what they think the human wants. Unless there is a deeply compelling reason, I want to see the same output on pts/0 as something down the pipeline. The reason for this is that picking up environmental hints to serve as implicit configuration is hacky, subject to error and and can later be the cause of really difficult-to-find bugs.

Perhaps I'm just irredeemably brainwashed. If you like a typed command line, Redmond has your back. For me, wanting types is a signal that I should start considering whatever little shell hack I'm working on complex enough to take it to a language that wasn't designed for ad hoc interactive use.

And at the same time, I really, very much do not want my command line to look like C#.

I get that a lot of folks these days are mostly GUI users who maybe type a little at git or run test suites from the command line, and not much else. I get why things like Powershell are appealing to such folks[1]. But when the command line is your primary interface, strong typing and OO hoop-jumping is huge waste of cognitive energy.

I do feel that Unix, to a first approximation, got the balance somewhere close to right. Loose coupling with lot of shared commonalities instead of a rigid type system and nonexplicit magic works really well for me, and if tighter coupling is a good idea, then I'll build it.

[1] Why they want to radically change the command line instead of using their favorite language to do systems stuff from the comfort of wherever they spend most of their time, I do not get.

Re: The Rule of Silence (2006)

#283

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 Windows way of working is only "self-evidently" horrible if you're used to the Unix way of doing things. There are real defects that are legacy baggage (running as admin by default is not good, the registry probably shouldn't be a single database or at least should have better segregation between apps) but having a UI and having real objects in the shell isn't one of them. And I hardly think the registry and Powe…

> And I hardly think the registry and PowerShell, which came out nowhere near the same time, were conceived of at the same time.

I believe that the registry, in a way, caused PowerShell.

PowerShell works the way it does because Windows is structured data all the way down. A text-based shell a-la bash would not be very useful for Windows sysadmins. If you want to do Windows automation (e.g. on a cluster of windows servers or whatnot), you need to process and manipulate structured data (server settings, user permissions, AD groups, whatever). Hence, a shell and scripting language for doing just that.

If Microsoft hadn't moved from .ini files to the registry between Windows 3.1 and 95, I don't think PowerShell would've had the same design goals as it does now.

Re: The Rule of Silence (2006)

#284

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…

lol at powershell in 1993

Tell me that somehow writing this comment was worth making a new HN account for.

Re: The Rule of Silence (2006)

#285
post #87

Earlier quoted context omitted.

Surely you can reconcile structured representations and something like the Unix command line. Imagine if the default wasn't bash, but something like Ruby + pipes (or some other terse language). What is the argument for shell scripts not working on typed objects? How much time has been lost, how many bugs have been created because every single interaction between shell scripts has to include its own parser. How many v…

>What is the argument for shell scripts not working on typed objects? Typed objects can make it harder to pipe commands together. How do you grep a tree when tree is an actual data structure and grep expects a list of items as input? You would need to have converters. Either specific converter between tree and list, or a generic one: tree->text->list. >Something Windows does get right is the clipboard. It useful, but…

> Typed objects can make it harder to pipe commands together. How do you grep a tree when tree is an actual data structure and grep expects a list of items as input? You would need to have converters. Either specific converter between tree and list, or a generic one: tree->text->list.

To be fair, untyped objects also require converters, but at every boundary. That is, instead of having some pipes of the form `program -> mutually agreeable data structure -> program` and some pipes of the form `program -> unacceptable data structure -> parser -> program` (as happens with a typed language), you are guaranteed by a text-based interface always to have pipes of the form `program -> deparser -> text -> parser -> program`.

Re: The Rule of Silence (2006)

#286
post #256

Earlier quoted context omitted.

I'd say regedit is not really the preferred method for anyone to interact with the registry though.

I'd say that regedit is integral to day-to-day use of Windows.

Well I don't know what in the world you're doing but I almost never use it.

Re: The Rule of Silence (2006)

#287
post #282

Earlier quoted context omitted.

You can pretty easily pass it to select and get just the properties you care about, or you could output to a different format with the various out- commands. I find it pretty good as a shell.

Options to select output? Sounds like advice from the Rule of Silence. But. - People above were just complaining about having to use sed to tweak output. I don't see why they would prefer a built-in filter to an external one. The external filter is far more flexible, and if that isn't enough, you can replace it. - I'm generally not a fan of applications that tailor their output to what they think the human wants. Unl…

Yeah, wow, all I have to do is write a bunch of regular expressions tailored to the unique output of this command instead of passing in a list of property names. It's so easy.

Re: The Rule of Silence (2006)

#288

Earlier quoted context omitted.

What programs are you thinking of? Maybe this is my sysadmin bias but about 90% of my UNIX tools usage is on config files...

ls, ps, du, df, ... pretty much all CLI tools. The kind you use in scripts.

All four of which users are enjoined, over and over again, not to try to parse the output of (particularly ls). That is, those are the tools specifically not meant to be connected by pipelines, but merely used for operator convenience.

Re: The Rule of Silence (2006)

#289
post #26
post #5

Note that the "rule of silence" (combined with the habit of writing documentation like longform essays) is also one factor that makes unix-like systems newbie-unfriendly. (Famous example: trying to exit vi) I think the rule makes sense within the specific constraints *nix programs are usually expected to work in (two output channels with no structure except the one informally defined by the program and the convention…

> Famous example: trying to exit vi To be fair, this has been fixed a long time ago. At least Vim (which is the Vi installed on most systems) shows the following message on startup: ~ VIM - Vi IMproved ~ ~ version 7.4.1829 ~ by Bram Moolenaar et al. ~ [...] ~ Vim is open source and freely distributable ~ ~ Help poor children in Uganda! ~ type :help iccf for information ~ ~ type :q to exit ~ type :help or for on-line…

I consider myself a major vim beginner, only using it for commit messages, very light file creations, and checking out config settings files when sshed into a server. I have never seen this screen.

Re: The Rule of Silence (2006)

#290
post #252

Earlier quoted context omitted.

> Yes I get it, you like your SSH session and Emacs/Vim blah blah but that's short-sighted. How so? I'm one of those people that like my SSH session, and in my case vim and "blah blah blah". I've contributed to countless open source software packages that you likely use with this method, and so have tons of other developers. Nothing is broken here, things are working great for everyone who reads the manual and follow…

> How so? As I mentioned in another comment in my view the problem is that something like the configuration is shared both by the humans and the computers. Because of this we settle on something that is not optimal for either group. We end up with something that is hostile to both the humans and the computers, just in different ways. In fact the argument of people like you for ASCII config files exactly demonstrates…

A lot of config files are already trivial for the computer to parse (by design). Most config files even follow a loose standard of some sort (e.g. INI, which is a sort of key-value system).

Would it not be easier to keep this format, and then add some integration into your favorite text editor that prevents you from accidentally editing the INI keys, or warns if you create a syntax error, etc? You could even make a generic INI gui editor that replaces appropriate values with checkboxes, sliders, etc.

I guess I don't see much wrong with the formats for most config files, but if you insist that there is a problem, and the problems you've outlined are caused only when editing them, then why not change the editor and preserve the format?

(That cron problem does sound bad though)

Post reply on HN