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....
Unix as IDE (2012)
51–60 of 72 posts
Re: Unix as IDE (2012)
#52IMO 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…
Re: Unix as IDE (2012)
#53IMO 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.
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)
#54Tangent: 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....
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)
#55Earlier 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…
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)
#56Earlier 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.
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)
#57Unix 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)
#58IMO 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)
#59Unix 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.
Re: Unix as IDE (2012)
#60https://blog.damnsoft.org/developing-on-a-pocket-chip-with-m...
Looking for new maintainer.