6 ms·

Unix as IDE (2012)

111 points by pabs3 3y ago

jruohonen 3y ago
Still the best IDE.
- dllthomas 3y ago
  I've joked that I have a disintegrated development environment.
- ryandv 3y ago
  My IDE is a tiling window manager, neovim, and several terminals. There is a browser somewhere for reading documentation.
bitwize 3y ago
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 started on C or its standard library. It turns out, however, that we haven't really strayed far from the "Unix as IDE" approach, as in order to turn Vim or Emacs into an IDE the typical approach is to just use Unix primitives and make the editor into a sort of super-shell that orchestrates pipelines of processes consisting of Unix command line tools. And that's fine. Time has marched on, however, and we have been the lucky recipients of not only better IDEs than Unix, but also things that are better than Unix at what Unix was thought to do well. PowerShell, for instance, is a vast improvement over Unix command-line environments with its ability to operate over typed pipelines of objects. We should be expanding our horizons beyond what 1970s programmers found convenient to implement and embrace new ways of thinking about, writing, testing, and debugging code.
- calvinmorrison 3y ago
  Expanding horizons = introducing longer pipelines of learning. At this point you'll need 10 years just to get the basics down much less be competent across the stack.
  - bitwize 3y ago
    People routinely become immediately productive in Visual Studio Code. Contrast this with the potentially multi-decade journey of becoming proficient in something like vim or Emacs plus command line tools. It is possible to improve on the old ways, from a productivity and ease of learning standpoint as well as from a standpoint of what's possible.
    - calvinmorrison 3y ago
      Oh I don't mean around just IDEs, but really I have a ton of new guys on my team who can understand how apis work but not any futher down. Now, 90% of the time it doesn't matter but, anytime the problem is 1 layer lower it falls apart. There are so many layers when we should be reducing layers and simplifying.
    - paleface 3y ago
      Your argument might hold water, if the standard for productivity was simply churning out code. The Linux/Unix world, already has tools, like nano, for such users. The software world, might be better served, however, if programmers slowed down, and engaged their brains, before bashing keys. I’ve solved most of the difficult problems, in my programming life, in the bath - where I can allow my mind to wander, and come up with the best solution.
- doix 3y ago
  I agree that PowerShell is theoretically better since it can deal with structured data. But in practice, I could never get as efficient with it as I could with "the Unix way" (everything is a string). If I was writing a "production" script, then it's better. But when I'm just trying to quickly do something on the command line, the "everything is a string" approach is good enough.
alberth 3y ago
This is how Mitchell Hashimoto (HashiCorp cofounder) developments. His “IDE” is Nixos + Neovim. https://sourcegraph.com/blog/dev-tool-time-mitchell-hashimoto https://sourcegraph.com/blog/dev-tool-time-mitchell-hashimot...
pdpi 3y ago
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. That is not a replacement for IntelliJ knowing about my DI bindings, though.
- Joker_vD 3y ago
  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.
  - zeroCalories 3y ago
    I was super excited about customizing every little detail about my setup as a kid, but as an adult I'm pretty much using ubuntu lts and vscode because I can't be bothered to read a half assed repo on configuring my lsp.
  - tharne 3y ago
    > Yeah, the article very conveniently ignores the "integrated" part of the IDE acronym. How's that? In unix (mostly) everything is a file, which in turn is just a stream of bytes that you can pass to any unix-y application, the output of which can be passed to any other unix-y application. That may not be your cup of tea or preferred environment, but it's very much integrated.
    - Koshkin 3y ago
      "Easily" integrable perhaps, then.
- deleted 3y ago
  [deleted]
reissbaker 3y ago
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.
- radiator 3y ago
  I don't know about Macbooks, but if the company-provided Laptop runs Windows, tmux + editor is nowadays very easy using WSL2.
  - tharne 3y ago
    Works great on Macbooks. Some would say better since copy/paste on a mac, even to and from a terminal in tmux is much less of a mess than on WSL or Linux.
    - reissbaker 3y ago
      Native copy/paste integration is pretty out-of-the-box these days on WSL as well, FWIW.
dawnofdusk 3y ago
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.
- berkes 3y ago
  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 https://github.com/sharkdp/fd
- madog 3y ago
  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
  - petepete 3y ago
    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.
massifist 3y ago
Programmer's Workbench (PWB/UNIX) https://en.wikipedia.org/wiki/PWB/UNIX https://en.wikipedia.org/wiki/PWB/UNIX While looking at the old Unix Archives, it's easy to get the impression that Unix really is the ultimate development environment, by and for programmers. At least at it's inception, before it started seeing more general use.
amadeuspagel 3y ago
VS code is most importantly a window manager, actually three window managers - sidebar, panels and editor groups.
G3rn0ti 3y ago
People love their integrated IDEs. And I don’t want to spoil that happy feeling. But perhaps we should actually focus on making programming languages more human friendly so we do not need complicated tooling around them to make us feel productive.
- _a_a_a_ 3y ago
  OK. How?
  - berkes 3y ago
    I'm sure the answers to that will show that what your parent-comment "demands" is impossible to generalize. We've once done a roundtable at our local developer meetup with this question. There were 20 people there. There were 20 different must-haves, requirements and ideas. We concluded that there's hardly a common denominator that isn't already present in most languages. And that all the other trade-offs in existing languages are warranted. Basically "it depends" :)
    - _a_a_a_ 3y ago
      I strongly agree, and the fact that the poster made no suggestions suggested he had none to make, it just being a nebulous wish for 'better things' . Nothing terrible about that but hardly actionable. Then again, if I was wrong I might've learned something useful from him. Very occasionally you do strike gold.
shunyaekam 3y ago
Tangent: I've been programming for many years, and the old VI vs Emacs inside-marker/debate about which one "real" programmers use has been a constant for the entire duration. (Because it is only one of those two. Any other is out of the question.) Anyway, how much of this, quite frankly, non-issue turned important geek status marker is *not* about cargo culting? The programmers back in the day, real or fake, had to use some editor, right? I'm sure they would have been happy to use any editor, as long as it was free. The programming profession is, in my not so humble opinion, a commodity profession by now. What I mean by commodity profession: Exactly what you need to know to be a web dev (to take a prominent example) is well-defined since long. Caring about small things like this just corroborates my point. I think it is time for all status-chasers (?) aged 20-something to stop caring about ridiculous geek markers such as debating terminal IDEs.
- _jal 3y ago
  > I think it is time for all status-chasers You're more or less just telling people they should socialize less. Get back to me once you've convinced people to stop arguing Ford vs. Chevy or Dodgers vs. Giants or Makita vs. Dewalt or....
  - shunyaekam 3y ago
    No, I'm saying that caring about VI vs Emacs is nothing else than high brow gatekeeping/in-group signaling.
    - _jal 3y ago
      You're right that it is in-group signaling[1]. But it is also socializing. Comparative-opinion jawboning passes time and serves as a social learning mechanism as well as an assortive signifier. That sort of thing is also, by volume, a huge fraction of interpersonal communication - much like gossip, it is a double-edged mechanism hard-wired into human behavior. Like I said, let me know when your utopia has eliminated assortive signaling about sports, tools, accents, clothes, art, food, housing, hairstyles, schools, employers, sex, shoes, religion, cars, text-messaging background colors, music, politics... all of which is far more pervasive, and some of which has historically escalated into literal wars. [1] I also personally agree that it is boring. I couldn't care less what editor people use unless they've configured it wrong in a way that messes up a repo I have to use, and even then only to the extent that I probably have to explain to them how to fix it.
jmclnx 3y ago
I agree, UNIX is a great IDE and even more, it is a good documentation system. I believe originally it was used for documentation purposes when it was first designed.
dang 3y ago
Related: Unix as IDE (2012) - https://news.ycombinator.com/item?id=22438730 https://news.ycombinator.com/item?id=22438730 - Feb 2020 (103 comments) Using Unix as an IDE - https://news.ycombinator.com/item?id=22392220 https://news.ycombinator.com/item?id=22392220 - Feb 2020 (2 comments) Using Unix as an IDE (2012) - https://news.ycombinator.com/item?id=17359533 https://news.ycombinator.com/item?id=17359533 - June 2018 (54 comments) Unix as IDE - https://news.ycombinator.com/item?id=12653028 https://news.ycombinator.com/item?id=12653028 - Oct 2016 (209 comments) Using unix as your IDE - https://news.ycombinator.com/item?id=4105768 https://news.ycombinator.com/item?id=4105768 - June 2012 (127 comments) Unix as IDE - https://news.ycombinator.com/item?id=3594098 https://news.ycombinator.com/item?id=3594098 - Feb 2012 (104 comments) Unix as IDE: Files - https://news.ycombinator.com/item?id=3575565 https://news.ycombinator.com/item?id=3575565 - Feb 2012 (1 comment)
alchemist1e9 3y ago
Since the author mentions RHIDE it reminded me of Motor. I haven’t used it but might be interesting for anyone interested in a 90s style TUI IDE on Linux. It’s written in C++ and using classic ncurses. https://blog.damnsoft.org/developing-on-a-pocket-chip-with-motor-a-text-based-ide/ https://blog.damnsoft.org/developing-on-a-pocket-chip-with-m... Looking for new maintainer. https://github.com/rofl0r/motor https://github.com/rofl0r/motor

Unix as IDE (2012)

111 points by pabs3 3y ago

jruohonen 3y ago

Still the best IDE.

dllthomas 3y ago
I've joked that I have a disintegrated development environment.
ryandv 3y ago
My IDE is a tiling window manager, neovim, and several terminals. There is a browser somewhere for reading documentation.

bitwize 3y ago

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 started on C or its standard library. It turns out, however, that we haven't really strayed far from the "Unix as IDE" approach, as in order to turn Vim or Emacs into an IDE the typical approach is to just use Unix primitives and make the editor into a sort of super-shell that orchestrates pipelines of processes consisting of Unix command line tools. And that's fine. Time has marched on, however, and we have been the lucky recipients of not only better IDEs than Unix, but also things that are better than Unix at what Unix was thought to do well. PowerShell, for instance, is a vast improvement over Unix command-line environments with its ability to operate over typed pipelines of objects. We should be expanding our horizons beyond what 1970s programmers found convenient to implement and embrace new ways of thinking about, writing, testing, and debugging code.

calvinmorrison 3y ago
Expanding horizons = introducing longer pipelines of learning. At this point you'll need 10 years just to get the basics down much less be competent across the stack.
- bitwize 3y ago
  People routinely become immediately productive in Visual Studio Code. Contrast this with the potentially multi-decade journey of becoming proficient in something like vim or Emacs plus command line tools. It is possible to improve on the old ways, from a productivity and ease of learning standpoint as well as from a standpoint of what's possible.
  - calvinmorrison 3y ago
    Oh I don't mean around just IDEs, but really I have a ton of new guys on my team who can understand how apis work but not any futher down. Now, 90% of the time it doesn't matter but, anytime the problem is 1 layer lower it falls apart. There are so many layers when we should be reducing layers and simplifying.
  - paleface 3y ago
    Your argument might hold water, if the standard for productivity was simply churning out code. The Linux/Unix world, already has tools, like nano, for such users. The software world, might be better served, however, if programmers slowed down, and engaged their brains, before bashing keys. I’ve solved most of the difficult problems, in my programming life, in the bath - where I can allow my mind to wander, and come up with the best solution.
doix 3y ago
I agree that PowerShell is theoretically better since it can deal with structured data. But in practice, I could never get as efficient with it as I could with "the Unix way" (everything is a string). If I was writing a "production" script, then it's better. But when I'm just trying to quickly do something on the command line, the "everything is a string" approach is good enough.

alberth 3y ago

This is how Mitchell Hashimoto (HashiCorp cofounder) developments. His “IDE” is Nixos + Neovim. https://sourcegraph.com/blog/dev-tool-time-mitchell-hashimoto https://sourcegraph.com/blog/dev-tool-time-mitchell-hashimot...

pdpi 3y ago

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. That is not a replacement for IntelliJ knowing about my DI bindings, though.

Joker_vD 3y ago
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.
- zeroCalories 3y ago
  I was super excited about customizing every little detail about my setup as a kid, but as an adult I'm pretty much using ubuntu lts and vscode because I can't be bothered to read a half assed repo on configuring my lsp.
- tharne 3y ago
  > Yeah, the article very conveniently ignores the "integrated" part of the IDE acronym. How's that? In unix (mostly) everything is a file, which in turn is just a stream of bytes that you can pass to any unix-y application, the output of which can be passed to any other unix-y application. That may not be your cup of tea or preferred environment, but it's very much integrated.
  - Koshkin 3y ago
    "Easily" integrable perhaps, then.
deleted 3y ago
[deleted]

reissbaker 3y ago

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.

radiator 3y ago
I don't know about Macbooks, but if the company-provided Laptop runs Windows, tmux + editor is nowadays very easy using WSL2.
- tharne 3y ago
  Works great on Macbooks. Some would say better since copy/paste on a mac, even to and from a terminal in tmux is much less of a mess than on WSL or Linux.
  - reissbaker 3y ago
    Native copy/paste integration is pretty out-of-the-box these days on WSL as well, FWIW.

dawnofdusk 3y ago

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.

berkes 3y ago
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 https://github.com/sharkdp/fd
madog 3y ago
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
- petepete 3y ago
  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.

massifist 3y ago

Programmer's Workbench (PWB/UNIX) https://en.wikipedia.org/wiki/PWB/UNIX https://en.wikipedia.org/wiki/PWB/UNIX While looking at the old Unix Archives, it's easy to get the impression that Unix really is the ultimate development environment, by and for programmers. At least at it's inception, before it started seeing more general use.

amadeuspagel 3y ago

VS code is most importantly a window manager, actually three window managers - sidebar, panels and editor groups.

G3rn0ti 3y ago

People love their integrated IDEs. And I don’t want to spoil that happy feeling. But perhaps we should actually focus on making programming languages more human friendly so we do not need complicated tooling around them to make us feel productive.

_a_a_a_ 3y ago
OK. How?
- berkes 3y ago
  I'm sure the answers to that will show that what your parent-comment "demands" is impossible to generalize. We've once done a roundtable at our local developer meetup with this question. There were 20 people there. There were 20 different must-haves, requirements and ideas. We concluded that there's hardly a common denominator that isn't already present in most languages. And that all the other trade-offs in existing languages are warranted. Basically "it depends" :)
  - _a_a_a_ 3y ago
    I strongly agree, and the fact that the poster made no suggestions suggested he had none to make, it just being a nebulous wish for 'better things' . Nothing terrible about that but hardly actionable. Then again, if I was wrong I might've learned something useful from him. Very occasionally you do strike gold.

shunyaekam 3y ago

Tangent: I've been programming for many years, and the old VI vs Emacs inside-marker/debate about which one "real" programmers use has been a constant for the entire duration. (Because it is only one of those two. Any other is out of the question.) Anyway, how much of this, quite frankly, non-issue turned important geek status marker is *not* about cargo culting? The programmers back in the day, real or fake, had to use some editor, right? I'm sure they would have been happy to use any editor, as long as it was free. The programming profession is, in my not so humble opinion, a commodity profession by now. What I mean by commodity profession: Exactly what you need to know to be a web dev (to take a prominent example) is well-defined since long. Caring about small things like this just corroborates my point. I think it is time for all status-chasers (?) aged 20-something to stop caring about ridiculous geek markers such as debating terminal IDEs.

_jal 3y ago
> I think it is time for all status-chasers You're more or less just telling people they should socialize less. Get back to me once you've convinced people to stop arguing Ford vs. Chevy or Dodgers vs. Giants or Makita vs. Dewalt or....
- shunyaekam 3y ago
  No, I'm saying that caring about VI vs Emacs is nothing else than high brow gatekeeping/in-group signaling.
  - _jal 3y ago
    You're right that it is in-group signaling[1]. But it is also socializing. Comparative-opinion jawboning passes time and serves as a social learning mechanism as well as an assortive signifier. That sort of thing is also, by volume, a huge fraction of interpersonal communication - much like gossip, it is a double-edged mechanism hard-wired into human behavior. Like I said, let me know when your utopia has eliminated assortive signaling about sports, tools, accents, clothes, art, food, housing, hairstyles, schools, employers, sex, shoes, religion, cars, text-messaging background colors, music, politics... all of which is far more pervasive, and some of which has historically escalated into literal wars. [1] I also personally agree that it is boring. I couldn't care less what editor people use unless they've configured it wrong in a way that messes up a repo I have to use, and even then only to the extent that I probably have to explain to them how to fix it.

jmclnx 3y ago

I agree, UNIX is a great IDE and even more, it is a good documentation system. I believe originally it was used for documentation purposes when it was first designed.

dang 3y ago

Related: Unix as IDE (2012) - https://news.ycombinator.com/item?id=22438730 https://news.ycombinator.com/item?id=22438730 - Feb 2020 (103 comments) Using Unix as an IDE - https://news.ycombinator.com/item?id=22392220 https://news.ycombinator.com/item?id=22392220 - Feb 2020 (2 comments) Using Unix as an IDE (2012) - https://news.ycombinator.com/item?id=17359533 https://news.ycombinator.com/item?id=17359533 - June 2018 (54 comments) Unix as IDE - https://news.ycombinator.com/item?id=12653028 https://news.ycombinator.com/item?id=12653028 - Oct 2016 (209 comments) Using unix as your IDE - https://news.ycombinator.com/item?id=4105768 https://news.ycombinator.com/item?id=4105768 - June 2012 (127 comments) Unix as IDE - https://news.ycombinator.com/item?id=3594098 https://news.ycombinator.com/item?id=3594098 - Feb 2012 (104 comments) Unix as IDE: Files - https://news.ycombinator.com/item?id=3575565 https://news.ycombinator.com/item?id=3575565 - Feb 2012 (1 comment)

alchemist1e9 3y ago

Since the author mentions RHIDE it reminded me of Motor. I haven’t used it but might be interesting for anyone interested in a 90s style TUI IDE on Linux. It’s written in C++ and using classic ncurses. https://blog.damnsoft.org/developing-on-a-pocket-chip-with-motor-a-text-based-ide/ https://blog.damnsoft.org/developing-on-a-pocket-chip-with-m... Looking for new maintainer. https://github.com/rofl0r/motor https://github.com/rofl0r/motor