181–190 of 616 posts
> [shell] It becomes especially bad when we try to develop in it, as it’s not a full-fledged programming language. Who the hell 'develops' in shell? It's a glue language, not a development language. I've never heard anyone say "We're a shell shop".
I spent a year working on ~80k lines of bash. It was an interesting experience.
You must have mastered the bizarreness of bash arrays by the end of that :)
Some of my primary beefs with Unix, stated more concisely than the rambling article: 1) Text is for humans, and is generally incomprehensible to machines. Encodings, arbitrary config file formats, terminals, etc, are all piles of thoughtless one-off hacks. It's a horrible substrate for compositing software functionality, through either pipes or files. 2) Hierarchical directory structures quickly become insufficient.…
Computers are for humans. I like my configurations to be accessible to me, as well as my logs.
Earlier quoted context omitted.
What then are "UNIX things". This could be either a no-true-Scotsman, or a tautology. To solve this, you'd need to specify what UNIX is good at.
"This could be either a no-true-Scotsman, or a tautology." It's even worse ! I am saying that working in terminals, with strings of text and non-binary-format config files ... and all of the tools built around that ... is an end in itself . Every single "broken" example in the OP is something that I find non-remarkable and, in fact, makes perfect sense to me.
Further, there is an immense value in GUI based systems: discoverability. On a GUI, you can learn how to use a program without ever consulting a manual just by inspecting your screen. This addition is what brought the computer to the masses.
Finally, the terminal model of UNIX is just horrible. The hacks-on-top-of-hacks that are needed to turn the equivalent of a line-printer into something like nCurses or tMux are horrible. The current terminal is like this purely because of legacy. If you'd design a system for "working in terminals, with strings of text and non-binary-format config files" from the bottom up, it would look totally different. Sadly, getting it to work with existing software would be a total nightmare.
All that being said, UNIX still has the better terminal (though I hear good things about powershell). Certainly, it is the best system for "working in terminals, with strings of text and non-binary-format config files". Though competition is sparse (windows, and maybe mac, depending on whether you consider it to still be unix or not).
Earlier quoted context omitted.
Windows 10 already sorted out the filename limitations. A few more releases and in around 10 years, Win32 will be drinking beers with Carbon. Mono and Qt don't change the architecture of UNIX and their adoption across UNIX variants isn't a game changer.
> Windows 10 already sorted out the filename limitations. Only for new applications. These written for the old ABIs still trip over after the 240th character, even though the FileSystem supports much more. To put in another words: I belive the inherent unix limitations (process model for terminals, process signalling, lack of structure) are still less limiting than DOS assumptions about the consumer hardware and appl…
Unix applications written using old assumptions (e.g. ?14? characters max for symbol names in libraries, ?16? bit address space, assuming the C library knows of gets) can have problems on modern systems, too.
This is the OS equivalent of a Call of Duty teenage online player on XBox live.
Earlier quoted context omitted.
I did not know about this! http://web.mit.edu/~simsong/www/ugh.pdf It even has an anti-foreword by Dennis Ritchie which kinda reminds me of the Metropolitan Police spokesman's blurb on the back of Banksy's book. BTW, it starts off with an anonymous quote that I've never heard, Two of the most famous products of Berkeley are LSD and Unix. Unix is of course from Bell Labs. And anyone who knew anything would have said i…
The whole document is great but the anti-forward is so good I'm going to risk downvotes by reproducing it in its (short) entirety here, emphasis mine: From: dmr@plan9.research.att.com Date: Tue, 15 Mar 1994 00:38:07 EST Subject: anti-foreword To the contributers to this book: I have succumbed to the temptation you offered in your preface: I do write you off as envious malcontents and romantic keepers of memories. The…
This whole article is a bunch of strawman arguments. It points out historical mistakes by unix developers, but those mistakes aren't inherent to or a result of the Unix Philosophy: (1) Write programs that do one thing and do it well. (2) Write programs to work together. (3) Write programs to handle text streams, because that is a universal interface.
Passing text streams around is a horrible idea because now each program has to have its own, half-assed shotgun parser and generator, and you have to glue programs together with your own, user-provided, half-assed shotgun parsers, i.e. calls to awk, sed, etc.
Think of it this way: if, per Unix Philosophy (points (1) and (2) of your summary), programs are kind of like function calls, and your OS is kind of like the running image, then (3) makes you programming with a dynamic, completely untyped language which forces each function to accept and return a single parameter that's just a string blob. No other data structures allowed.
I kind of understand how it is people got used to it and don't see a problem anymore (Stockholm syndrome). What shocked me was learning that back before UNIX they already knew how to do it better, but UNIX just ignored it.
Note that this philosophy covers many concepts. These discussions often mention the modularity and composition rules, but the other parts of the philosophy are also important.
See "The Art Of Unix Programming" for a full explanation of the philosophy.
This article was written hastily, and I don’t want to further improve it. You’re lucky I wrote it. I feel so privileged to read this random guy's blog, and it's terrific that he eschews inflating his ego so well.
it's a joke. Last sentence of the article is > The provocative tone has been used just to attract your attention.
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.
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 couple chapters of SICP.