Hacker News Reader

Comment by jrockway | Hacker News Reader

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.)

View on HN

>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.

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.

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.

…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.

> 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.

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".

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.

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.

Reply on news.ycombinator.com