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

Unix as IDE (2012)

blog.sanctum.geek.nz

Post reply on HN
Print view View original

11–20 of 72 posts

Re: Unix as IDE (2012)

#11

Post by yjftsjthsd-h »

bitwize wrote: post #3

Unix was probably a great IDE by the standards of 1975, because literally every design decision about Unix was made based on the criterion of convenience for a 1970s programmer. Those decisions haven't aged well: fork() sucks, lack of completion-based async I/O sucks, ill-thought-out file, socket, and process APIs riddled with TOCTOU bugs suck, two-letter YAFIYGI commands suck, untyped pipes suck, and don't get me st…

> Those decisions haven't aged well: fork() sucks, lack of completion-based async I/O sucks, ill-thought-out file, socket, and process APIs riddled with TOCTOU bugs suck, two-letter YAFIYGI commands suck, untyped pipes suck, and don't get me started on C or its standard library.

Of those, only

> two-letter YAFIYGI commands suck, untyped pipes suck

sound like problems with unix as an IDE; most of what the article discusses is unaffected by underlying APIs.

I also feel like I should question whether you're not attacking a strawman; modern unix-likes are continuations of unix, but they're not stuck in the 70s. For example, AIUI everyone agrees that fork() has shortcomings... which is why we have vfork (and I think others?) now.

Re: Unix as IDE (2012)

#12

Post by kragen »

bitwize wrote: post #3

Unix was probably a great IDE by the standards of 1975, because literally every design decision about Unix was made based on the criterion of convenience for a 1970s programmer. Those decisions haven't aged well: fork() sucks, lack of completion-based async I/O sucks, ill-thought-out file, socket, and process APIs riddled with TOCTOU bugs suck, two-letter YAFIYGI commands suck, untyped pipes suck, and don't get me st…

see, that's what i thought in 01998, but you may have noticed that google, facebook, aws, openai, github, android, ios, docker, instagram, slack, whatsapp, fastly, tesla, etc., all run on unix for some reason

so i guess fork and epoll and the racy unix file and socket and process apis are adequate, or anyway in some way not as fatally flawed as windows. a lot of those successful tech things of the last 25 years do involve some java or golang or erlang

stack overflow runs on windows tho

almost everything in my list runs on linux, mostly ubuntu. the exceptions are that ios runs on darwin and whatsapp runs on freebsd

Re: Unix as IDE (2012)

#13

Post by kragen »

yjftsjthsd-h wrote: post #11
bitwize wrote: post #3

Unix was probably a great IDE by the standards of 1975, because literally every design decision about Unix was made based on the criterion of convenience for a 1970s programmer. Those decisions haven't aged well: fork() sucks, lack of completion-based async I/O sucks, ill-thought-out file, socket, and process APIs riddled with TOCTOU bugs suck, two-letter YAFIYGI commands suck, untyped pipes suck, and don't get me st…

> Those decisions haven't aged well: fork() sucks, lack of completion-based async I/O sucks, ill-thought-out file, socket, and process APIs riddled with TOCTOU bugs suck, two-letter YAFIYGI commands suck, untyped pipes suck, and don't get me started on C or its standard library. Of those, only > two-letter YAFIYGI commands suck, untyped pipes suck sound like problems with unix as an IDE; most of what the article disc…

vfork is a lot worse than fork, don't use it

Re: Unix as IDE (2012)

#14

Post by Joker_vD »

pdpi wrote: post #10

Unix is a DE, no I about it. This isn’t a ding against Unix, the integration provided by IDEs is great for some types of work, but it’s also more hindrance than help for other types of work. Also, the toolset that you get from a typical Unix environment is more or less language agnostic, so you have your tool toolset available to you even when you’re working on something obscure with poor dedicated tooling support. T…

Yeah, the article very conveniently ignores the "integrated" part of the IDE acronym. Which was one of the maint selling points of them: you don't have to cobble various small pieces of functionalty together by yourself, it's been figured out and done for you by the IDE developers once, now you can just write your programs.

Re: Unix as IDE (2012)

#15

Post by reissbaker »

IMO tmux + a scriptable terminal editor (Vim, Neovim, Emacs, etc) turns Unix into a very nice IDE — but it's pretty dependent on becoming deeply familiar with those two tools: a multiplexer and an editor.

I wouldn't say Unix is an IDE, really; but you can build a very nice IDE for yourself using Unix tools, as long as you have a sufficiently configurable terminal multiplexer and a sufficiently configurable terminal editor.

One pretty major difference between "Unix is an IDE" vs "you can build an IDE around Unix" is that, well, the terminal editor is actually pretty close to an IDE — you can have language server based autocomplete, refactoring, linting; UI for git; etc. So, it's not really that Unix is your IDE; your editor is. But the nice thing about running it in a multiplexer in a terminal, though, is you have instant and easy access to just about any other command-line tool just a keyboard shortcut away, and it can be organized visually wherever you like — a pane on the side, beneath, zoomed in temporarily to encompass the screen, hidden in a tab, etc.

(Sufficiently advanced terminal emulators could also fill in for tmux here.)

I think you get many of the same benefits using a tiling window manager... But well, the best ones require running Linux (or one of the OSS BSDs); the options for your company-provided Macbook are fewer and less good. Tmux + terminal editor is pretty nice as something that works in any Unix environment.

Re: Unix as IDE (2012)

#16

Post by [deleted] »

pdpi wrote: post #10

Unix is a DE, no I about it. This isn’t a ding against Unix, the integration provided by IDEs is great for some types of work, but it’s also more hindrance than help for other types of work. Also, the toolset that you get from a typical Unix environment is more or less language agnostic, so you have your tool toolset available to you even when you’re working on something obscure with poor dedicated tooling support. T…

[deleted]

Re: Unix as IDE (2012)

#17

Post by dawnofdusk »

Unix shell utilities as an idea/philosophy are a really good IDE, but in practice a lot of them need major UX overhauls. `find` is awful, for example, if only because it uses single hyphens followed by full words for it's flags (different from almost all other conventions...)

Doing anything which involves more than one pipe or xargs is just painful. Bash as a language is not ergonomic at all.

I don't know if there's a nice alternative that keeps the same spirit. My feeling is something like emacs + eshell (a shell which can execute elisp expressions)? Elisp is not a very ergonomic language either, of course... but something like this.

VSCode was a revolution in giving an IDE with a good UI, every feature one could want, and fairly good performance. In 2023, I feel like everyone's on containerized/distributable work flows so there is a big need to actually return to "UNIX as IDE" type work, and now would be a great time for some new CLI tools that improve on the past.

Re: Unix as IDE (2012)

#18

Post by berkes »

dawnofdusk wrote: post #17

Unix shell utilities as an idea/philosophy are a really good IDE, but in practice a lot of them need major UX overhauls. `find` is awful, for example, if only because it uses single hyphens followed by full words for it's flags (different from almost all other conventions...) Doing anything which involves more than one pipe or xargs is just painful. Bash as a language is not ergonomic at all. I don't know if there's…

Many (most?) of them have been overhauled with success. For find there is fd[1]. There's batcat, exa (ls), ripgrep, fzf, atuin (history), delta (diff) and many more.

Most are both backwards compatible and fresh and friendly. Your hardwon muscle memory still of good use. But there's sane flags and defaults too. It's faster, more colorful (if you wish), better integration with another (e.g. exa/eza or aware of git modifications). And, in my case, often features I never knew I needed (atuin sync!, ripgrep using gitignore).

1 https://github.com/sharkdp/fd

Re: Unix as IDE (2012)

#19

Post by madog »

dawnofdusk wrote: post #17

Unix shell utilities as an idea/philosophy are a really good IDE, but in practice a lot of them need major UX overhauls. `find` is awful, for example, if only because it uses single hyphens followed by full words for it's flags (different from almost all other conventions...) Doing anything which involves more than one pipe or xargs is just painful. Bash as a language is not ergonomic at all. I don't know if there's…

There are modern alternatives to many of the classic utils e.g. `fd` for find, with better CLI args and other improvements

ripgrep for grep also comes to mind

Re: Unix as IDE (2012)

#20

Post by petepete »

madog wrote: post #19
dawnofdusk wrote: post #17

Unix shell utilities as an idea/philosophy are a really good IDE, but in practice a lot of them need major UX overhauls. `find` is awful, for example, if only because it uses single hyphens followed by full words for it's flags (different from almost all other conventions...) Doing anything which involves more than one pipe or xargs is just painful. Bash as a language is not ergonomic at all. I don't know if there's…

There are modern alternatives to many of the classic utils e.g. `fd` for find, with better CLI args and other improvements ripgrep for grep also comes to mind

I've totally switched to the newer, dev-orientated variants for my work.

fd, sd, ag/rg, fzf, bat, xh/httpie all work how I'd expect them to and I don't need any archaic knowledge. Plus, fish's autocomplete does fill in blanks when I need it.

I'd kind of consider tmux to be my ide rather than Unix. That's where I combine everything above (along with nvim), and it's as integrated as I need it to be.

Post reply on HN