Wandering Thoughts archives

I will probably never give my shell dotfiles the major reform they could use

I've been using my current shell for what is now a very long time, and over that time I've always carried forward the core structure of my Unix $HOME, including my shell dotfiles. One of the consequences of this is that my dotfiles have accumulated a great deal of historical cruft. Another is that if I was starting from scratch with a clean slate, I probably wouldn't structure and code my dotfiles the way they currently are; my tastes and views have changed from the long-ago person who first wrote those files and set the basic approach that I've followed since then.

Some people would take a period of vacation or a move to a new system or whatever as a reason to rip everything out and start from scratch (perhaps even with a new shell, one that's more popular, active, and widely available by default). I applaud the energy of these people, but I've come to realize that I no longer have that sort of enthusiasm. These days I'm a pragmatist about any number of things, and one of those things is that I just don't care enough to go in and do anything to perfectly working shell dotfiles.

(I don't even care enough to delete all of the sections for long dead systems and system types. Well, in theory I don't care, but now that I'm writing this entry my fingers have a bit of an itchy urge.)

There is still a bit of me that would like to start all over again from complete scratch, with a bare $HOME and no history. Perhaps someday I will have a completely new system that I want to make my new home and I'll get to do that, but for now that seems unlikely. I do admire the people who run around doing lots of experiments and customizations and so on with their shells, though.

(I theorize that one thing that leads to restarting your $HOME is changing jobs in the commercial world, where in many cases you're not going to export things out of your old job or into your new job. A personal Unix system probably often functions as another 'job' for these purposes. Part of the advantage of being at a university for all of these years, even using different systems, is that I could freely propagate my dotfiles around between different systems, including my home system.)

PS: There are some systems where I don't have my usual shell or dotfiles set up and I just use Bash with an almost stock setup. But these systems are also ones that I don't care about enough or use actively enough to set up what I consider a 'real' environment on. If I did care, I'm not sure I'd create a new Bash based setup or just propagate a variant of my usual shell setup. Propagating over my current environment is certain a fast way to get set up, since everything just drops in in one go.

On programming languages belonging (or not) to their community

On Twitter, I said some things as follow on notes to how Go is Google's language, not ours:

For example, C and especially C++ are community languages and this shows in what gets added to their standards. You can find a lot of people who think that C++'s growth is not a good thing. Go is unlikely to grow that way partly because the Go core team is willing to do nothing.

There are language communities and standards committees that are willing to do nothing, but generally there are lots of voices for doing something and so something gets done. Once you're a community thing, saying 'no, we're not doing anything' is very hard.

C++ is my canonical example of a language that definitely belongs to its community, for better or worse. There are several major implementations, two of which are themselves genuine community projects, and the direction of C++ is set by an open standards committee with a relatively distributed membership. C++ is also a famously complicated language which has had major changes over the years that have apparently significantly affected how you should write C++ code today, and I've read any number of gripes about the directions in which it's moving and whether or not future changes are good ideas (including Bjarne Stroustrup himself, per Remember the Vasa! [PDF] (via)).

Some of this is due to C++'s specific situation, but beyond that I think that communities have structural influences that make it hard for them to avoid heading in this direction. There are always loud people who have ideas and in general it is hard for a community to consistently say 'no, we're not doing anything', especially in a fuzzy situation; for example, often there is social pressure to give sufficient justification for your refusal to take action. In one way, the big advantage that languages with some form of control by a benevolent dictatorship have is that there are people who can say 'no' over and over again and get away with it.

(It helps a great deal if these people have good taste and say no to the right things, of course. But saying 'no' to everything can work too, if the language is in the right shape to start with. You may miss out on useful advances, but at least you won't ruin the good things that the language already has.)

The two obvious problems with a benevolent dictatorship are the other sides of this. A benevolent dictatorship can ram through a change even when it's a bad idea, and they can stop changes that are good ideas. The more that a language genuinely belongs to its community, the more the language will reflect what the community wants and needs (or thinks it does), rather than what some people think the community should have (for its own good). Just ask people about Python 2 and Python 3 for an illustration of that.

(Even when a forced change is theoretically a good thing, it has social and pragmatic effects on the community of people using the language that can be overlooked or waved away by the enthusiasts at the center of their language. You can get rousing debates over whether the pain is 'worth' the end result, but it is undeniable that pain was inflicted.)