Live data from Hacker News

The Collapse of the Unix Philosophy

kukuruku.co

521–530 of 616 posts

Re: The Collapse of the Unix Philosophy

#521

Earlier quoted context omitted.

"Each tool does just one thing well" doesn't mean "just one tool does one thing". In fact, ETDJOTW means that interoperable alternative tools -- loose coupling -- is more readily supported. So that, say, you can transparently migrate from unsecured rsh to secured ssh. Actually: you can even gain capabilities, since rsh is (misfeature) limited to the 512 low-numbered ports, and hence, a maximum of 512 outbound connect…

That's one interpretation, but it's not really what people mean when they refer to "one tool". The progenitor of the expression is Doug McIlroy: This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. Interoperability is part of DOTADIW idea, but it flows from the "one thing": If each t…

I didn't say that interoperability was the goal, but that it's the effect.

See Steve McConnell, Code Complete, for a treatment of modular design in software and the flexibility it provides.

(The same logic applies well outside software.)

Re: The Collapse of the Unix Philosophy

#522

Earlier quoted context omitted.

Not that I've ever used one, but I wouldn't expect someone to indent any code on a punch card. I just felt the comment was suiting since it must have been about when they were still used that you couldn't automate indentation.

In FORTRAN 77, it'a syntax error to put a statement before column 7

Interesting! Can you explain why that is the case? Were the first 6 characters reserved for the line number or goto marks?

Re: The Collapse of the Unix Philosophy

#523

Earlier quoted context omitted.

> Try using tabs to indent e.g. arguments to function one under another, and weep. Where the terms are distinguished in a programming context, that's alignment, not indentation; tabs for indentation, spaces for alignment is a common suggestion.

Sure, as long as you don't mix them on one line (i.e. first indent, then align), because then differences between tab widths will still break alignment.

First indent and then align will retain alignment with different tab widths, because you only align things that are at the same indent level, so different tab widths in a tab indent / space align combination just move the whole aligned block left or right without affecting alignment.

Re: The Collapse of the Unix Philosophy

#524
post #474

Earlier quoted context omitted.

>True enough, but as a younger programmer, I find it pretty reasonable to look back at computer systems of the 70s and wonder if we can do better today. I feel a little bit gross every time I have to write a bash shell script (or edit config files that aren't JSON/XML/YAML, for that matter), and I don't think that's a bad impulse. That something so inelegant and unsafe is still in widespread use in 2017 really ought…

> what the fuck are programmers thinking when writing today's programs The difference is in the old days, you adapted to computer. Now, computer must adapt to you. Take a look at MS's latest text-editor program's release notes ( https://code.visualstudio.com/updates/v1_10 ). They have to build a program that accommodates so many different existing must-have features (from a potential users POV), and for each feature,…

As a contrast, I use sublime. It has (almost) everything I desire. And it saves everything i write, even in the case of a power outage.

Another example would be Acme[0].

>The point is that user preferences are more fragmented and expectations are higher for features, and willingness to learn details and gotchas of a program are lower, which has created the bloated program for the simple things like text editors.

I agree. People are people and people will always be subjective. But there should be a distinction between feature bloat and node.js bloat. Still, ofc, to each his own. (I measure how good it is for me by how much hair i pull out by using it, be it by lack of features, bugs, performance, or anything)

[0]https://www.youtube.com/watch?v=dP1xVpMPn8M and https://www.usenix.org/legacy/publications/library/proceedin...

Re: The Collapse of the Unix Philosophy

#525
post #153

Earlier quoted context omitted.

>Windows 10 already sorted out the filename limitations. No, it hasn't. Filenames are still case-insensitive (and in a terrible way, where it seems to remember how they were first typed but that can never be changed), backslashes are still used for path separators instead of escaping characters, and the worst of all is that drive letters are still in use, which is an utterly archaic concept from the days of systems w…

Windows NT (the core OS) suffers none of those problems. The Windows (Win32) environment suffers those limitations. It also suffers 20+ years of strong binary compatibility, broad hardware support, and consistent reliability that systems of similar class (e.g. Linux desktops) can't match. If it makes you feel any better, drive letters are a convenient illusion made possible by the Win32 subsystem; NT has no such conc…

Is there a possibility to use the NT system without the flaws (?) of Win32? I hardly know anything about Windows programming, and I'm a bit curious now, having read your comment.

Re: The Collapse of the Unix Philosophy

#526

Earlier quoted context omitted.

> wonder if we can do better today Cough... systems... cough... We can do better. Plan 9 existed. Apple's Newton has a unique take on data files. AS/400's map all storage to memory addresses giving a single address space for everything. With Smalltalk, applications would just be new classes you import into your system. The key to Unix's success seems to be not doing better, but doing as little as possible while still…

Plan 9 is not "better enough". The other ones had fundamental non-technical problems that hurt their adoption (Plan 9 had those at the beginning too). Back to Plan 9, you can expect something that is just slightly better than your current options, and that keeps being this way to steadily gain adoption until it's popular. But that requires it being no worse than the current on any popular use case. Plan 9 may have a…

Plan 9 had fundamental technical problems too. Like most of the systems of that time it was designed with small single-building kind of networks in mind and didn't offer any value once large planet scale networks came to life. Also everything could have being implemented on top of any unix system, but wasn't that interesting for anyone to bother.

Re: The Collapse of the Unix Philosophy

#527
post #364

Earlier quoted context omitted.

Powershell did one thing wrong, in that its tools emit objects , not data . In other words, they emit data with behavior (methods). This, in turn, imposes the CLR object and memory model on the whole thing, and makes the pipeline impossible to use between distinct processes. The right way to do this is to pick some reasonable text-based structured interchange format - s-exprs, JSON, whatever. Actually, it wouldn't be…

The problem here is that most unix tools (ls being the exception) do double duty, they both emit output for other programs and output for the user. Which one you get and how the user output is presented being controlled by flags. If you want them to only emit data in a standardized format you are implicitly cutting out the user. Since direct use by a human is arguably the main use case, output formatting needs to be…

You just need to output formating instructions, not code.

Read that imagining "formating instructions" as data that will be consumed by a default visualizer that the shell automatically pipes at the end of your command in interactive sessions.

I'm sure there's a general architecture for such thing. If no better choice is available, it can be done with plugins.

Re: The Collapse of the Unix Philosophy

#528

I wish Symbolics had a better run. The Windows registry/powershell approach has the niceness of passing pieces of data instead of one big blob of text that has to be re-parsed at every step, but with the drawback of verbosity and fussy static typing. Being able to directly pass s-expressions between between programs without the format/parse/typing hokey-pokey of Unix and Windows would be nice.

Symbolics Genera doesn't pass S-expressions (i.e. text) between processes, it passed objects. Everything runs in a single address space so this is cheap and accurate. Also, ZetaLisp and Common Lisp have way more types than those supported by S-expressions. For example, they have real vectors/arrays, structures, and full objects. Don't assume all of the Lisp world uses just the subset of Scheme used in the first coupl…

Well if at the end in your programmes you got to manipulate structured data (represented by sexps which whatever extensions), then the guts are irrelevant.

Re: The Collapse of the Unix Philosophy

#530

Earlier quoted context omitted.

Tab are actually more eco-friendly than space. Just think of the energy lost sending 4 characters instead of 1 in every uncompressed json/xml actually moving around because lazy people don't mind suppress them before sending it over the network...

and imagine how annoying it gets when you are punching a punchcard.

We would punch up a program card to put on the drum in our IBM 029 card punches to set the tab stops, and let the tab key do its job.
Post reply on HN