One thing that is rarely mentioned, but usually practiced: Unix tools rarely modify its own state. The only way to modify the behaviour of a program is to pass parameters, set an environment variable, or modify a configuration file. This lends a great degree of predictability to how programs will behave. If you pipe something into grep, sed, awk, etc. you know how it will behave. It sounds like the article's author is not just ignoring that aspect of the Unix philosophy, but contradicting it.
I'm not exactly sure what the author is arguing for. Perhaps they have a vision, and perhaps it is a vision that has utility. That said, I do not see how their words fit into a modernized version of the Unix philosophy.
nalaginrut · 18h ago
You mean functionality as in functional programming?
I wonder if it aligns with Unix philosophy. But that's an interesting insight.
II2II · 12h ago
If true, I'll leave credit to that insight to you since I was not thinking in terms of functional programming. I don't know enough about functional programming to assess whether it is true, but piping data through the classic Unix utilities does seem to meet at least one criteria of functional programming (e.g. the utilities act as pure functions).
travisgriggs · 20h ago
Im a big fan of the Unix philosophy. But this article is not resonating with me. It reads like good engineering (Unix) mixed with meta physics bordering on some sort of new age spiritualism.
If anything, I see the dawn of LLMs as upending the “internet as we knew it” and also as having a step effect on the value of human literacy.
dale_glass · 20h ago
It's terrible, but the Unix philosophy leaves much to be desired. Like the example:
cat file | grep "foo" | awk '{print $2}'
That's terrible in this day and age. Text streams are terrible to work with in modern times. We've long moved past /etc/passwd-like formats, and even with those such tooling has been extremely subpar. What if you put a colon in a file with colon separated fields?
There's no end to the nonsense you have to deal with that just shouldn't even be a problem in 2025.
PeterWhittaker · 14h ago
Perhaps because it is a dumb example.
awk '/foo {print $2}' file
does the same thing, without a pipeline.
If one wanted robust rich pipelines, one could use PowerShell (which I used as my UNIX and Linux shell for a while when I was programming in it everyday as part of dayJob).
II2II · 12h ago
Text streams have their advantages and disadvantages. Advantages include being easy to create, modify, view without special tooling. Given the nature of the Unix shell, you can apply that equally to both data and code. Of course, the disadvantage includes the potential of poorly defined streams, or of steams being difficult to interpret due to them being human readable. But that was as true when Unix was created as it is today.
lcnielsen · 15h ago
This is literally the best thing about Unix tools. You can write a compact little Awk script and pipe that with a few coreutils to parse mountains of text into sensible data. I use this kind of thing every day.
CyMonk · 15h ago
> What if you put a colon in a file with colon separated fields?
Okay, what's the actual problem? The only material complaint I see in your comment is that you have to not use control characters as data. And I guess that's true, but I really don't think it's that big of a deal.
dale_glass · 14h ago
That it's kind of terrible and decades out of date.
Yeah, most problems are solvable somehow, but you still have to solve them instead of getting things done, and the results are often fragile. Like awk -F: /etc/passwd works nicely, until there's an \: in there that awk completely fails to understand.
aaravchen · 5h ago
So the alternative is opaque types?
Powershell tried adding structured types for the output, and it has some benefits, but now your pipeline composition options are severely limited. Only the tools that understand the output structure of the prior step are options. What if you have a new structure output type? You now need all new tools to do anything with it.
I don't say text is an ideal format by any means, but it's a _universal_ format. That unviversality is necessary to be useful long term. Unix just picked text since it was easy for a human to look at and reason about.
Or are you suggesting monolithic tools instead of composable ones? Tomorrow I have a need you haven't thought of. Now your tool is useless to me and I have no way to do what I need. Modular composition isn't just a Unix philosophy, it's a basic development principle because it puts the power in the hands of the user to create almost anything they can think of, rather than restricting it to only what the creator thought of and implemented.
I'm not really sure what you're arguing is "terrible" about the solution. If you don't like the hazards and difficulty of dealing with something like your colon separator being in the data too, let me introduce you to data handling 101. It doesn't matter what format you put data in, the same problem exists. Even raw binary needs a delineator between elements, and eventually that delineator is going to need to be in the data itself somewhere. Unless you suggest we shouldn't be able to represent all data? It's the reason virtually every language supports escaping special characters (E.g. JSON's backslash escaping of quotes).
chubot · 20h ago
This feels like both a non-sequitur and troll
If you want to make an "AI dev philosophy", sure go ahead
But it has nothing to do with the Unix philosophy
dave333 · 12h ago
Just using prompts like Unix commands in pipelines takes you a long way at least conceptually. Can have AI choose the best data format from stage to stage although all formats can be represented as text. Not sure if there's much difference between another pipeline stage and another paragraph in the prompt. Maybe have AI decide when a particular prompt is nearing the token limit of its model and split the task into multiple stages. AI can also design the pipeline - decide what each stage should do.
olemindgv · 19h ago
Reading the comments letting me re-live my early years of being an engineer, in a hardcore Unix kernel company. For every line of code, there are more neys than yes, but we still have finish the code and push forward. Next time we shall bring beers and chips.
inftech · 19h ago
I can been wrong, but I think this AI trend is becoming something like a cult.
I'm not exactly sure what the author is arguing for. Perhaps they have a vision, and perhaps it is a vision that has utility. That said, I do not see how their words fit into a modernized version of the Unix philosophy.
If anything, I see the dawn of LLMs as upending the “internet as we knew it” and also as having a step effect on the value of human literacy.
There's no end to the nonsense you have to deal with that just shouldn't even be a problem in 2025.
If one wanted robust rich pipelines, one could use PowerShell (which I used as my UNIX and Linux shell for a while when I was programming in it everyday as part of dayJob).
This problem has been solved for thirty years.
https://en.wikipedia.org/wiki/Escape_character
Yeah, most problems are solvable somehow, but you still have to solve them instead of getting things done, and the results are often fragile. Like awk -F: /etc/passwd works nicely, until there's an \: in there that awk completely fails to understand.
Or are you suggesting monolithic tools instead of composable ones? Tomorrow I have a need you haven't thought of. Now your tool is useless to me and I have no way to do what I need. Modular composition isn't just a Unix philosophy, it's a basic development principle because it puts the power in the hands of the user to create almost anything they can think of, rather than restricting it to only what the creator thought of and implemented.
I'm not really sure what you're arguing is "terrible" about the solution. If you don't like the hazards and difficulty of dealing with something like your colon separator being in the data too, let me introduce you to data handling 101. It doesn't matter what format you put data in, the same problem exists. Even raw binary needs a delineator between elements, and eventually that delineator is going to need to be in the data itself somewhere. Unless you suggest we shouldn't be able to represent all data? It's the reason virtually every language supports escaping special characters (E.g. JSON's backslash escaping of quotes).
If you want to make an "AI dev philosophy", sure go ahead
But it has nothing to do with the Unix philosophy
No comments yet