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

Bringing the Unix philosophy to the 21st century (2019)

blog.kellybrazil.com

Post reply on HN
Print view View original

121–130 of 151 posts

Re: Bringing the Unix philosophy to the 21st century (2019)

#121

Post by johnlorentzson »

pjmlp wrote: post #49
eadmund wrote: post #23

Why not go all the way and use a format capable of expressing code and data? I refer, of course, to S-expressions. They also have the benefit of properly handling numbers. Some might look at the absence of maps as a negative, but I think alists are preferable anyway due to their constant ordering.

Specially because it keeps being forgotten that Lisp Machines and Interlisp-D workstations shells were basically a graphical based REPL. To put it in 2021 terms, Jupiter Netbooks in 1980's instead of PDP-11 green phosphor terminals.

Even the best Unix shells are a mere toys in comparison to what Lisp machines were doing in the 80s. I don't wanna say that using a Lisp machine was "life changing" or anything but let's just say I don't like Linux anymore.

Re: Bringing the Unix philosophy to the 21st century (2019)

#122

Post by iainmerrick »

lfnoise wrote: post #94
iainmerrick wrote: post #76

Earlier quoted context omitted.

You could do any of those things, but you have to pick a convention and other people have to agree on it. JSON is nice in that it has just enough structure to do a good number of tasks in one obvious way. The biggest omission is probably some kind of time and/or date type (but ISO8601 in a string is the obvious solution there). It’s not a coincidence that JSON was reverse-engineered from a language with convenient li…

You parse the s-exprs and execute them in the context of a namespace of data constructors. Then you can have whatever data structures in memory that are defined by the constructors. This is NOT equivalent to having one data structure to cover both as Lua does. It is having one text format that can construct any kind of data structure in memory for which you have constructors defined.

Okay, but we’re talking about a lingua franca for exchanging plain old data between different programs. You would have to pick your data constructors in advance.

I’m saying that arrays and maps give good bang for the buck, so you don’t really need to define anything beyond those. And if you accept that, having special syntax for arrays and maps is more convenient and readable than S-exprs.

Re: Bringing the Unix philosophy to the 21st century (2019)

#123

Post by pjmlp »

johnlorentzson wrote: post #121
pjmlp wrote: post #49

Earlier quoted context omitted.

Specially because it keeps being forgotten that Lisp Machines and Interlisp-D workstations shells were basically a graphical based REPL. To put it in 2021 terms, Jupiter Netbooks in 1980's instead of PDP-11 green phosphor terminals.

Even the best Unix shells are a mere toys in comparison to what Lisp machines were doing in the 80s. I don't wanna say that using a Lisp machine was "life changing" or anything but let's just say I don't like Linux anymore.

I may look like very anti-UNIX, ironically I was big into UNIX, my first experience was with Xenix.

However my university library had a very good section on all kinds of OSes and programming languages since the dawn of computing, thus I could see how the future might have been and there was definitely a much better path, specially when coupled with my own experience across Amiga, Windows and Mac OS.

It is like the bulb paradox, just applied to OSes.

Re: Bringing the Unix philosophy to the 21st century (2019)

#124

Post by laumars »

lambdaba wrote: post #106
laumars wrote: post #86

Earlier quoted context omitted.

No seriously, there really are. I appreciate it requires learning a new tool but rather than downvoting me how about those unconvinced ask me questions instead? I’m happy to answer. While there will always be a need to keep Bash around for comparability, there are a plethora of other tools out there that solve many of the shortcomings of POSIX.

Are you using one of these exclusively? Which one have you chosen and why?

I use murex exclusively. It’s still beta quality so not totally bug free but the bugs are rarely showstoppers and it’s still in active development so fixes are usually just one GitHub issue away.

I don’t use it on servers, I stick with Bash for that. But I do use it as my primary local shell.

As for why murex, that’s a combination of personal preference and simply not being aware of other shells until after I’d already started using murex.

What I like about it is it’s typed and does a lot of the boring stuff automatically in the pipeline based off what type is (JSON, YAML, CSVs etc are all “types”). So working with a JSON file is as natural as working with a flat text file. But also it’s trivial to bypass the clever stuff and use it like a dumb bash shell too. Which is where Powershell and its ilk fall down.

Re: Bringing the Unix philosophy to the 21st century (2019)

#125

Post by johnlorentzson »

quasarj wrote: post #48
eadmund wrote: post #23

Why not go all the way and use a format capable of expressing code and data? I refer, of course, to S-expressions. They also have the benefit of properly handling numbers. Some might look at the absence of maps as a negative, but I think alists are preferable anyway due to their constant ordering.

Mostly because S-expressions are terribly hard for humans to read... and everyone is already familiar with javascript syntax.

S-expressions aren't inherently more difficult to read than JSON, it's just a matter of getting used to it.

Re: Bringing the Unix philosophy to the 21st century (2019)

#126

Post by pjmlp »

coliveira wrote: post #73
c0l0 wrote: post #19

So I've been writing shell scripts for about two decades, about 75% of that time professionally. Parsing the unstructured, text-based output of utilities is not the problem for anyone who's had maybe a few weeks of training. Most `... | grep ... | cut ... | sed ... | awk ...`-abominations the post laments can be replaced by a single informed call to `awk`, making everything a lot more elegant and concise. Having JSON…

You mentioned one pain point of shell scripting, variability among platforms. The other pain point is that different tools have different methods to treat errors and warnings. This makes debugging shell scripts a nightmare, compare to scripting languages like python. If you need to debug your work, you need to check several levels of script vs. commands, and use different ways to check for errors depending on what is…

Tcl is also a full scale language, the startup I was on during the com wave was shipping products written in Tcl + C, just like Python.

Re: Bringing the Unix philosophy to the 21st century (2019)

#127

Post by pjmlp »

kaliszad wrote: post #66
c0l0 wrote: post #19

So I've been writing shell scripts for about two decades, about 75% of that time professionally. Parsing the unstructured, text-based output of utilities is not the problem for anyone who's had maybe a few weeks of training. Most `... | grep ... | cut ... | sed ... | awk ...`-abominations the post laments can be replaced by a single informed call to `awk`, making everything a lot more elegant and concise. Having JSON…

I can see the potential in Babashka and other Clojure-based systems from the approach point of view. There needs to be a simple integrated editor or much better readline implementation though that needs to work out of the box. That should improve the interactivity in a major way. We also need to have a set of very simple tools to work with files, network connections (e.g. traffic dumps, netcat) and other typical shel…

So basically a Lisp Machines REPL.

Re: Bringing the Unix philosophy to the 21st century (2019)

#128

Post by emodendroket »

shatteredspace wrote: post #116
emodendroket wrote: post #80

Earlier quoted context omitted.

PowerShell is just so much nicer to use than anything where text munging is the only way to do things, and it’s just as “pluggable” as Unix shell commands. And it can output text (or JSON or XML or YAML) or whatever you want easily by piping into relevant commands (or just not piping anywhere if you wanted text). I don’t imagine those are going anywhere anytime soon but I think it is wrong to say the system cannot be…

I would disagree and say that while PowerShell is well...powerful, it's not as pluggable as the Unix shell. Purely due to objects vs plaintext. PowerShell works off of .NET objects thus if I want to take output from one command and send it to another I have to verify that the receiving command can in fact receive the object type I'm sending. This is where the Unix shell to me is more 'pluggable' but it makes it more…

You can always transform the output by selecting particular properties, so the commands don’t have to expect exactly the shape of your first command’s output. This is similar to what you’d do in Unix to massage text output anyway.

Re: Bringing the Unix philosophy to the 21st century (2019)

#129

Post by pjmlp »

shatteredspace wrote: post #116
emodendroket wrote: post #80

Earlier quoted context omitted.

PowerShell is just so much nicer to use than anything where text munging is the only way to do things, and it’s just as “pluggable” as Unix shell commands. And it can output text (or JSON or XML or YAML) or whatever you want easily by piping into relevant commands (or just not piping anywhere if you wanted text). I don’t imagine those are going anywhere anytime soon but I think it is wrong to say the system cannot be…

I would disagree and say that while PowerShell is well...powerful, it's not as pluggable as the Unix shell. Purely due to objects vs plaintext. PowerShell works off of .NET objects thus if I want to take output from one command and send it to another I have to verify that the receiving command can in fact receive the object type I'm sending. This is where the Unix shell to me is more 'pluggable' but it makes it more…

Powershell is much more than that, you are only seeing the basic stuff.

It is the only shell that ships by default on modern OSes that builds up on Xerox PARC ideas.

It is not only .NET, rather anything on the OS.

It also handles COM, DLLs, OLE Automation, WMI, pluggable filesystems.

With Powershell you can easily automate something like use the currently selected cell on an Excel document, and use it as input for something else, including another active application.

Something like that would be possible on UNIX shells with DBus like protocols, and ability to load shared objects into the shell, but on typical UNIX fashion everyone does their own thing and thus the whole experience remains fossilized.

Re: Bringing the Unix philosophy to the 21st century (2019)

#130

Post by pjmlp »

zozbot234 wrote: post #15
dan-robertson wrote: post #8

Earlier quoted context omitted.

Emacs is in many ways anti-Unix-philosophy and I think the way it’s software tends to be structured is no exception. Functions can get ad-hoc extensions or modifications all over the place with advice and hooks and dynamic scoping[1]. The only similarity is that in Unix most things are files and in Emacs most things are buffers. [1] Unix has weird ad-hoc mechanisms too like environment variables or your PATH containi…

The Unix philosophy includes the use of software libraries in one's programs, albeit only resorted to when truly necessary. That often involves resorting to many of these tricks, usually for the sake of greater software reuse.

A philosophy that is cargo cult, as it was hardly ever followed on commercial UNIX systems.
Post reply on HN