4 ms·

Is that a problem? A simple tool is good if it can solve complex problems, but a simple tool that can't is just an underdeveloped tool. Sometimes you need a c

Is that a problem? A simple tool is good if it can solve complex problems, but a simple tool that can't is just an underdeveloped tool. Sometimes you need a complex tool to solve a complex problem. I think a good mini language bridges the gap between interactive commands and programming. Sometimes you need to spend an hour writing a program to do something complicated. But because of various "extraneous features" built into UNIX commands, you rarely need to spend an hour manually poking at the filesystem. The mini language gets you almost as productive as a full-fledged programming language, without feeling like you're programming. (How do you know you're programming? If you "git init" and start committing stuff, you're probably programming. If your carefully-crafted thing scrolls into .history obscurity, then you're interacting.)

exitb 3y ago
Find is not simple - it's easy, but internally complex. It's fine to solve a complex problem with a complex tool, but it's troublesome when people mostly use it to solve simple problems. And the trouble is that this kind of approach spreads to every single component in the system, which means that we're using insane amount of code and cpu load to solve really simple problems on daily basis. Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.
- SubjectToChange 3y ago
  …we're using insane amount of code and cpu load to solve really simple problems on daily basis. Piping programs together is almost always going to use significantly more resources than one program doing it all. More code doesn’t necessarily imply more resource usage. Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code. I don’t want to be all around negative about plan 9, but I don’t see it as really solving any interesting problems. Indeed it is far easier to write slim, elegant systems when forgoing feature parity and/or competitive performance.
  - exitb 3y ago
    > More code doesn’t necessarily imply more resource usage. That's true! Yet, somehow we found ourselves in a situation where most people use computers, to chat, read news etc, all of which would be possible with much less resources. All done with the use of platforms that we literally can't rewrite, as they're too complex. It's certainly not find's fault, but the complexity creep starts somewhere. Plan 9, as a research OS, is not a useful platform to base your next business on, but it does serve as a baseline we can relate our "real" platforms to.
    - dale_glass 3y ago
      Little conveniences cost a lot. Just having a framebuffer with page flipping for seamlessly redrawing the screen costs 64MB of memory at 4K resolution. People did real work and gaming on computers with a small fraction of that. Early on in the history of computing the framebuffer was discussed as a theoretical construct, like "what could we do with this concept if we had the memory to implement it".
t0suj4 3y ago
After staring down find(1) on an AIX system I regret not going down the du | grep path. At least that way I wouldn't be stuck trying to mash GNU's parameters into completely incompatible version of find.
- ykonstant 3y ago
  If your system supports `man 1p` (loading the posix manual for each supported utility), it is a good idea to reference that instead of the default manpage; it is more likely for your utility to support posix options than GNU extensions in legacy and non-linux systems.
foul 3y ago
>I think a good mini language bridges the gap between interactive commands and programming. find(1) is a bad mini language. Its arguments are in a legacy format and its solution for composability is a hack, and an unstable one.
- rektide 3y ago
  And shell users already have a language they know & should be able to use to compose computing: the shell. Different programs introducing their own specific programmatic layers defeats the holistic small pieces, loosely coupled premise.

exitb 3y ago

Find is not simple - it's easy, but internally complex. It's fine to solve a complex problem with a complex tool, but it's troublesome when people mostly use it to solve simple problems. And the trouble is that this kind of approach spreads to every single component in the system, which means that we're using insane amount of code and cpu load to solve really simple problems on daily basis. Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.

SubjectToChange 3y ago
…we're using insane amount of code and cpu load to solve really simple problems on daily basis. Piping programs together is almost always going to use significantly more resources than one program doing it all. More code doesn’t necessarily imply more resource usage. Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code. I don’t want to be all around negative about plan 9, but I don’t see it as really solving any interesting problems. Indeed it is far easier to write slim, elegant systems when forgoing feature parity and/or competitive performance.
- exitb 3y ago
  > More code doesn’t necessarily imply more resource usage. That's true! Yet, somehow we found ourselves in a situation where most people use computers, to chat, read news etc, all of which would be possible with much less resources. All done with the use of platforms that we literally can't rewrite, as they're too complex. It's certainly not find's fault, but the complexity creep starts somewhere. Plan 9, as a research OS, is not a useful platform to base your next business on, but it does serve as a baseline we can relate our "real" platforms to.
  - dale_glass 3y ago
    Little conveniences cost a lot. Just having a framebuffer with page flipping for seamlessly redrawing the screen costs 64MB of memory at 4K resolution. People did real work and gaming on computers with a small fraction of that. Early on in the history of computing the framebuffer was discussed as a theoretical construct, like "what could we do with this concept if we had the memory to implement it".

t0suj4 3y ago

After staring down find(1) on an AIX system I regret not going down the du | grep path. At least that way I wouldn't be stuck trying to mash GNU's parameters into completely incompatible version of find.

ykonstant 3y ago
If your system supports `man 1p` (loading the posix manual for each supported utility), it is a good idea to reference that instead of the default manpage; it is more likely for your utility to support posix options than GNU extensions in legacy and non-linux systems.

foul 3y ago

>I think a good mini language bridges the gap between interactive commands and programming. find(1) is a bad mini language. Its arguments are in a legacy format and its solution for composability is a hack, and an unstable one.

rektide 3y ago
And shell users already have a language they know & should be able to use to compose computing: the shell. Different programs introducing their own specific programmatic layers defeats the holistic small pieces, loosely coupled premise.