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

181–190 of 318 posts

Re: The Rule of Silence (2006)

#181

Post by emodendroket »

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.

Well, sure, if you don't know PowerShell or use it often you'll need a lot of help. That just sounds like an argument for slavish adherence to existing conventions till the end of time -- in which case why bother with a new language?

Re: The Rule of Silence (2006)

#182

Post by emodendroket »

yason wrote: post #149
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…

> If structured data was embraced we would have developed appropriate tooling to interact with it in the way that we prefer. What kind of tooling might work with ad-hoc structured data and still getting all the tools to talk with each other like in Unix? How would it work without having to write input parsing rules, data processing rules, and output formatting/filtering/composing rules for each tool? I suspect that t…

But the programs don't really just "understand" text; it has to be munged into exactly the format they expect.

Re: The Rule of Silence (2006)

#183

Post by fulafel »

rtpg wrote: post #87
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…

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…

Image processing works pretty well in shell pipelines because image formats are generally self-identifying.

Re: The Rule of Silence (2006)

#184

Post by jslabovitz »

stevedonovan wrote: post #110
Vogtinator wrote: post #97

Earlier quoted context omitted.

You can just develop alternative tools and pipe JSON. Text and data in one. Pipes can transfer arbitrary data, so it's just the tools that you don't like, not the underlying mechanism.

Modern tools should offer the option to write out JSON (with a proper spec, please). I can definitely see the value of a 'ls' variant that can do this, and I remember people discussing JSON-based shells. But not either/or! For example, the Rust compiler can now be persuaded to write out error messages in JSON.

Modern tools are offering the option to write out JSON. Grepping /usr/share/man and /usr/local/share/man on my macOS system reveals a good dozen or so commands that take JSON as input or generate it as output. (Their man pages generally document the schema, too.) Most of the tools I've written myself also have JSON I/O.

Re: The Rule of Silence (2006)

#185

Post by palunon »

013 wrote: post #68
ygra wrote: post #34

Earlier quoted context omitted.

Someone unfamiliar might just be dumped into vi because some other program thought it'd be great to open a text editor, e.g. for a commit message. You're unlikely to run vi intentionally unless you also know you want to run vi and how to exit, I guess.

Programs that put you into Vi, /should/ be calling $EDITOR, if $EDITOR is to to Vi(m), you should know how to use it. Also, if you ^C in Vi, you get the message: Type :quit to exit Vim

And what if $EDITOR is not set ? Vi is the standard POSIX editor, calling it makes sense.

Re: The Rule of Silence (2006)

#186

Post by brusch64 »

skrebbel wrote: post #80
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…

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…

Adding to that my favourite pet peeve - translated UIs for server processes.

Every time I come around a German installation of IIS or SQL Server I'm cringing. Googling the right solution and then trying to figure out how they've translated this option is something I can't stand.

Re: The Rule of Silence (2006)

#187

Post by jslabovitz »

yason wrote: post #163
tim333 wrote: post #155

Earlier quoted context omitted.

>it's not very popular to pass around structured data There's an awful lot of JSON that gets passed around. That seems a reasonable compromise between readable text and some sort of structure.

So, how do you parse, read, and process JSON without additional instructions of how to interpret the data and what to look for? All right, maybe you do have a common tool that implements a query language so that you can filter out certain paths and objects from the JSON data into a thinner data set with known formatting expected by the next command in the pipeline. Then you need to write that command and you need mor…

I've started using jq (https://stedolan.github.io/jq/) in pipelines to parse/transform JSON output from commands that support it. It has some XPath-like notations for specifying elements within the JSON data tree. It's not perfect, but it's a good start and useful right now.

Re: The Rule of Silence (2006)

#188

Post by michaelcampbell »

emodendroket wrote: post #173
chei0iaV wrote: post #121

Earlier quoted context omitted.

The problem is that now simply providing user-friendly output is not enough. For every program or script you throw together you need to provide the text output for the user, and then the type object stream for piping. And then, the user would need to read documentation to see how to access each piece of data, what data type it is, what data type the other command takes, and maybe consider how to convert one to the ot…

> The problem is that now simply providing user-friendly output is not enough. For every program or script you throw together you need to provide the text output for the user, and then the type object stream for piping. In PowerShell if the result of a command is just an object the object is pretty-printed to the console in practice ends up looking pretty much like what a Unix command would have given you.

> in practice ends up looking pretty much like what a Unix command would have given you.

So... no real improvement, then?

Re: The Rule of Silence (2006)

#189

Post by numbsafari »

emodendroket wrote: post #170
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 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…

S/PowerShell/Windows Scripting Host/ ... which was later than the registry, but not much.

Re: The Rule of Silence (2006)

#190

Post by xenophonf »

ygra wrote: post #142
setq wrote: post #134

Earlier quoted context omitted.

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…

man iwr Oh, there's an OutFile parameter. Let's see what it does man iwr -param outfile How nice, it writes the response directly to a file instead of to the pipeline. The curl alias actually points to the very same cmdlet. Not to excuse bad examples on the internet (there are lots of people who fail to grasp PowerShell and still try to write articles and how-tos), but PowerShell having built-in documentation for com…

To be fair there are many, many examples of downloading files using System.Net.WebClient. In fact that is how the first several search results for `powershell download file` tell you to do it despite Invoke-WebRequest being included in PowerShell since 2012. `get-help download` doesn't return anything useful. Contrast that with `apropos download`, which at least on FreeBSD includes wget in the search results.
Post reply on HN