Live data from Hacker News

Unix as IDE (2012)

blog.sanctum.geek.nz

51–60 of 72 posts

Re: Unix as IDE (2012)

#51
post #45

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…

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

No, I'm saying that caring about VI vs Emacs is nothing else than high brow gatekeeping/in-group signaling.

Re: Unix as IDE (2012)

#52

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

Agreed, though i prefer in-built multiplexing like in Wezterm to tmux on macos for performance reasons.

Re: Unix as IDE (2012)

#53

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

Agreed, though i prefer in-built multiplexing like in Wezterm to tmux on macos for performance reasons.

The nice thing about tmux/screen is that they're more widely available by being separate from the terminal emulator itself. I can use them on any *nix system and with one modification (I use a different prefix than default with tmux and screen, I'm too used to emacs keybindings to let them have C-b and C-a) have the same experience on all of them.

Another positive is that they survive if, for some reason, you close your terminal. I can completely kill the terminal emulator and my tmux session (or screen, but I haven't used it much in years) will still be around and can be reattached.

Re: Unix as IDE (2012)

#54
post #45

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…

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

> You're more or less just telling people they should socialize less.

Which is in my opinion not a bad idea ;-) , but for many people getting rid of the habit of socializing is similarly hard as stopping smoking or stopping being an alcoholic.

Re: Unix as IDE (2012)

#55
post #26
post #5

Earlier quoted context omitted.

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.

The thing that we'd ideally want to happen, but will probably never will unless a mad person does it, would be to have something that wraps around a POSIX shell, and extends it in a sort of non-compatible way. Let's call this new tool $NEWSH. Larry Wall basically tried to do this with Perl but I guess his vision was too lax for such a pursuit, Perl tried to be everything, all at once. What I mean by this new approach…

(author here) Yeah you just repeated what https://oilshell.org/ is

You'd want to be able to go $NEWSH my-bash-script.sh and it should just work. $NEWSH my-newsh-script.nsh should also work, obviously.

    osh my-bash-script.sh  # works, it's the most bash-compatible shell by a mile
   
    ysh my-new-script.ysh  # works
YSH looks like this - https://www.oilshell.org/release/latest/doc/ysh-tour.html (everything in this doc works, you can try it now)

And then you do

    shopt -s ysh:upgrade
to opt into new behavior.

https://www.oilshell.org/release/0.19.0/doc/upgrade-breakage...

YSH isn't done yet, but it's coming along nicely -- see the latest status update - https://www.oilshell.org/blog/2023/11/status-update.html

---

The project isn't a solo project anymore! There have been 6 people funded by two NLNet grants, and we just got a third one, mentioned in the post.

If you want it to succeed, then you should try it and report bugs.

One way to view it is that Oils has a 7 year head start on any other project that wants upgrade shell. Like you say, it's a huge amount of work, and it's the ONLY project that's compatible with bash (which BTW is a much bigger job than being compatible with POSIX sh).

Shell became the #6 fastest growing language on Github in 2020, so all those shell scripts people have written in the last few years make the Oils project more valuable. That is, people are writing scripts compatible with OSH at a greater rate than any other new shell (e.g. new shells == ones with precise error messages)

The new command line tools like fd and bat are ALSO compatible with OSH and YSH because they use the Unix process interface :) There have been several shells that want to bundle everything into the shell, but I disagree with that philosophy, because it limits growth to being "inside" the project.

(although YSH has a lot more functionality than bash built-in, like JSON support)

---

People who have contributed are acknowledged in the release announcements.

Testing is a good contribution. Writing weird HN comments isn't a good contribution :-P

There has been some misunderstanding of the project, but very little "hate" ... Mostly encouragement!

Re: Unix as IDE (2012)

#56
post #45

Earlier quoted context omitted.

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

No, I'm saying that caring about VI vs Emacs is nothing else than high brow gatekeeping/in-group signaling.

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.

Re: Unix as IDE (2012)

#57
Related:

Unix as IDE (2012) - https://news.ycombinator.com/item?id=22438730 - Feb 2020 (103 comments)

Using Unix as an IDE - https://news.ycombinator.com/item?id=22392220 - Feb 2020 (2 comments)

Using Unix as an IDE (2012) - https://news.ycombinator.com/item?id=17359533 - June 2018 (54 comments)

Unix as IDE - https://news.ycombinator.com/item?id=12653028 - Oct 2016 (209 comments)

Using unix as your IDE - https://news.ycombinator.com/item?id=4105768 - June 2012 (127 comments)

Unix as IDE - https://news.ycombinator.com/item?id=3594098 - Feb 2012 (104 comments)

Unix as IDE: Files - https://news.ycombinator.com/item?id=3575565 - Feb 2012 (1 comment)

Re: Unix as IDE (2012)

#58

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

Agreed, though i prefer in-built multiplexing like in Wezterm to tmux on macos for performance reasons.

I've used tmux and vim/nvim on macOS and never experienced performance issues but I'm really curious about your experience, could you share more details?

Re: Unix as IDE (2012)

#59
post #5
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…

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.

It's a very interesting topic, since the amount of brittle sed/grep/awk done by everybody using *nix on earth probably requires 128bits numbers, yet structured interactions does slow you down due to idiosyncracies. That said I wonder how quick things like powershell reward you. It's a bit like having a unit standard.

Re: Unix as IDE (2012)

#60
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-m...

Looking for new maintainer.

https://github.com/rofl0r/motor

Post reply on HN