It's an entrenched network effect. There's a lot of existing scripts written targeting POSIX shells, and there's an incentive to have all your distro maintenance scripts written in one language if possible.
If you want to switch your existing distro scripts to fish, you need to rewrite a lot of stuff. If you want to start a new distro, "it's written in fish!" isn't a terribly compelling selling point, since I don't think anyone is actively picking distros based on their tooling language.
For the general devops case, there's a lot of existing example code out there for bash scripts, and far less for fish. "How do I do X in bash?" is probably going to get you a decent example on Stack Overflow. Devops (I feel) cares a bit more about the installed-everywhere thing, and fish isn't a standard part of most distros.
Oil having a goal of being completely sh/bash compatible gives it much greater odds of something like Debian switching to it, since it wouldn't carry huge technical debt along with it.
The fact that there is the POSIX standard and multiple shells that meet that standard is also a big part of it. If you write in a POSIX compatible shell language you know it can run anywhere. Fish, for example, has no standard and only 1 implementation.
Any new shell that hopes to compete in the systems space will have to be POSIX compliant. At least until there is a new widely adopted shell standard.
Gentoo is basically this. I learned Python by writing .ebuilds (their package format is a short Python script that downloads and builds whatever software you're installing).
Ah right you are, thanks - I remember learning Python and switching to Gentoo about the same time, but as David Hume warned us, it's hard to infer causality from proximity.
yeah I can actually imagine that. like using an IDE based on the language it was written in to extend and tweak it more easily, or a window manager etc..
actually now you mentioned it, barring possible performance issues I'd also like a Python distro
Early Smalltalk and Lisp systems were those langs all the way down. Using emacs with Common Lisp or using Pharo Smalltalk can give you a feel for this, but not exactly the same thing as a Symbolics lisp machine or the Xerox Alto. Alan Kay has a presentation where he shows the entire OS, word processor, networking stuff, IDE, paint programs...etc was an insanely small amount of code and everything was user configurable. I really wish that had caught on more. I really enjoy Linux (although it ain't perfect). Using Windows and trying to interactively do anything with the OS is an exercise in pain and frustration. If someone could build a modern machine with an OS that is like that and had a few basic apps (web browser...etc), I would be quite happy.
I don't know if it's just me, but I don't feel like I'm using a computer when using Windows. After using OpenBSD exclusively for weeks (my laptop broke, so I had to repurpose an old netbook with OpenBSD), I felt bored and limited in Windows.
I tried Powershell, but -mostly because I don't know much about it- it didn't give the same feeling.
The thing that is working for me is to explore VB.net . It is really an interesting language with many historical features. I've noticed that all the languages I use (Python, C#, Java, Go, etc.) distracted me from the essence of programming.
When I started programming I immidiately thought about patterns, architecture, unit-tests, integration-test etc.
In VB.net I feel like I'm slowly reexperiencing the joy I've felt in my earlier days of programming.
"In VB.net I feel like I'm slowly reexperiencing the joy I've felt in my earlier days of programming."
Ruby was the first language that I experienced that got out of the way, so I felt like I could think about what I was trying to achieve, rather being distracted by house-keeping. Of the other languages that I've tried, I've only gotten close to the same feeling with JavaScript, Go and Python.
I suspect that a lot of it is to do with your own mind-set at the time: I first learned Python as an applications language, with all of the add-on tools and baggage, and didn't like it much, but recently I wrote a one-file, no-dependency thing to do exactly one job in Python, using just the standard library, and it was a joy.
The difference was, I think, that I did not feel the internal pressure to meet best practices, and could just write the code. For some languages, the stuff that you are supposed to do and the tools that you are supposed to use are a heavy burden.
you can turn windows into an adult computer by using cygwin (maybe mingw), autohotkey and something like window manager.
the illusion is almost real, because sometimes i also run linux in vmware/docker/... and when i am not paying attention i forget easily which os i am on.
the unix subsystem for win is quite boring as you can't mix windows applications with linux ones, for example running visual studio build from bash.
powershell would be probably worth learning, if i'd have to, but i do not. it may be godsend to win sysadmins though, as classic cmd is a 40 year old joke.
True, but it's a hack...not something fluid/elegant/seamless or efficient. I'm not a software engineer. I'm just a traditional engineer that wants an OS written for a power user that allows me to do my job more efficiently. Dealing with a multitude of wrappers is worth it if you're writing production software of course, but not if you write a lot of one off scripts for day to day work.
I've stated on here numerous times that Powershell falls short because pipes aren't text based as in Unix, but are really more like method chaining in .NET. Most of the time I have the output of one command, but can't easily reason about passing it to the next command.
I feel you. This guy is working on an interesting project called the Reform laptop [1]. You might have seen this already. He will eventually have it run his own lisp (called "Interim") all the way down.
I recommend Emacs. Maybe not as a daily driver (it's a matter of preference), but for the experience. I recommend at least a month with it, make sure to write some original Lisp code for your customisations. (You WILL end up customizing it, the defaults are crap.)
> or a window manager
I recommend Awesome. The core is in C, but that's basically the low-level stuff, the actual WM is written in Lua. If you'd start with an empty init file, you'd have a moderately sized side-project on your hands to put something usable together. But if you'd start from the stock rc, there's a world of endless tweaking and customisation waiting for you...
Watch out, both Emacs and Awesome are rabbit holes.
As someone who has recently joined the 1k LOC Emacs configuration file club, I have to disagree. The default settings are a well thought out starting point that needs minimal tweaking to get to exactly where you want. I try out a lot of packages on ELPA, and many that purport to provide alternatives for defaults end up being inferior to using the defaults with some small tweaks. The convenient thing is that you can customize the third-party packages in the same way and just use the parts you like from them.
The other good thing about Emacs is that you don't need a separate window manager[1], and you don't need to use a separate command shell (Emacs comes with eshell), or to use a terminal emulator for SSHing into remote machines (eshell over TRAMP is absolutely amazing), or a file manager (Emacs comes with dired, which works over TRAMP which is amazing), or a...
My favourite Emacs goodie to highlight is magit because it really changed the way I use git. All of a sudden, it's incredibly simple to (un-)stage individual hunks, etc. And of course it works over TRAMP, too :)
org-mode is a good one, too, but I feel like I've barely scratched the surface there.
The hunk feature of magit is great; you can easily stage/unstage not only at the hunk granularity but also arbitrary lines using the selection. Being able to easily do that was something I really missed when I moved from darcs to git.
When it comes to magit and TRAMP, definitely the best part is with-editor[1]. This is one of those ingenious "why didn't I think of this?" hacks to let you use your local Emacs as EDITOR on remote machines without having to do SSH port forwarding for emacsclient.
Any pathname in eshell can be a TRAMP pathname on a remote machine. So you just cd to a remote directory and eshell will run commands on the remote machine. You can redirect remote command output to a local file, local command output to a remote file, cp from remote pathname on machine A to remote pathname on machine B, etc.
At some point I realized that I wasted months in those rabbit holes customizing and tweaking shell configs, window managers and Emacs. Any gain in productivity (which may not even be there as it is rather subjective) was not able to offset it. So I stopped it. These days I just use Gnome Shell with a single extension to fix something that I cannot get used at all, simple bash config to setup environment for development with no customization on shell behavior, and a programming editor that mostly matches my taste. On a new machine I can finish all customization within 5 minutes and forget about it.
I even started to suspect that an easy customization of a tool can be a bad sign. It is almost like developers delegates all usability issues to the end user making the default case really bad.
I've used -- for longer periods of time, of course -- Awesome, Xmonad, i3, and dwm; while some of them are better at some things than StumpWM, StumpWM is the only one that provides an Emacs, live-hackable experience. So these days, I strongly prefer that.
If you want to switch your existing distro scripts to fish, you need to rewrite a lot of stuff. If you want to start a new distro, "it's written in fish!" isn't a terribly compelling selling point, since I don't think anyone is actively picking distros based on their tooling language.
For the general devops case, there's a lot of existing example code out there for bash scripts, and far less for fish. "How do I do X in bash?" is probably going to get you a decent example on Stack Overflow. Devops (I feel) cares a bit more about the installed-everywhere thing, and fish isn't a standard part of most distros.
Oil having a goal of being completely sh/bash compatible gives it much greater odds of something like Debian switching to it, since it wouldn't carry huge technical debt along with it.