The other reason that shells should be programmable
I gave several sensible low-level reasons why Unix shells should beprogrammable in WhyShellLanguages . But the higher level reason whyis simpler: shells should be programmable because it helps peoplegrow their expertise.
If doing sophisticated Unix glue things is donewith a separate language, there is a huge barrier to entry; you haveto learn an entirely new language before you can start doing evenrelatively small things. Many ordinary users are simply not goingto have either the interest or the time to invest (especially whenit may not
Fault hierarchies and problem reports
Here is something that I have come to feel strongly about: things thatreport problems (as opposed to just log them) should have some ideaof root causes and a fault hierarchy. Then when you report thingsyou should report the root cause you've found and only mention theconsequences as a side note, instead of screaming about everyconsequence.
(As a not entirely hypothetical example , it does no good to spam me withnotices about lots of ZFS pools being unavailable when the real problemis that the system
Virtual desktops versus multiple monitors
A commentator here asked:
With respect to tabs vs. windows (vs. virtual desktops vs. extramonitors vs. separate computers), I always wonder what combination ofthe above will lead to the greatest productivity.
Having used both, my personal opinion is that virtual desktops areinferior to multiple monitors for the same reason that tabs are inferiorto windows, namely that you can't see two virtual desktops at once.This makes virtual desktops good for grouping and a good place to shoveexcess windows but not a
More on standard interfaces
In my biased opinion, one important consequence of who standardinterfaces help is that if you are designing asystem that people will be using a lot, one that they will regularlyspend a lot of time with, please use a good interface for it no matterhow non-standard it has to be. The drawbacks of a non-standard interfaceare more than made up by the benefits of a good one for the frequentusers.
(I'm biased in this because some of the best programs I've
Why I am not really fond of docstrings in Python
I wrote some nice things before about how Idon't really use docstrings, but in thinking about it more I've realizedthat I was shading the truth. The real truth is that I don't really likeusing docstrings, and I've recently figured out why: docstrings don'tstand out enough.
(I have to say here that I have nothing against documenting my code;I just want it to look right.)
Unless you use an editor and display environment that set docstringsoff
More thinking about Python's inheritance model
Here's something I've been pondering lately: why doesn't Python havean inheritance model more like C++, where (forexample) your superclass's __init__ is automatically called?
There's a number of reasons, but I think that one of them is that Pythonlacks any concept of private class attributes and methods. When youlimit what a subclass can do to a superclass, when you have privateinternal state that has to be maintained correctly, it's
The implicit versus the explicit
In a lot of computer things (such as programming languages, or systemenvironments) we have the choice between being concise and leavingthings implicit, and being verbose but making things explicit. Hereis the thing about this choice:
Computers are fine with implicit things because they never forget ;they effectively have perfect memories for this sort of thing. Buthumans have limited memories (especially short term memories) that haveto be periodically reinforced, so we necessarily forget some of theimplicit stuff every so often. Which periodically causes
A bug reporting paradox: don't put in too much detail
Here's a paradox about bug reporting: while details are good, too muchdetail is bad (and by this I don't just mean too much verbosity).
Specifically, you should not go into too much detail about what is goingon unless you are certain that you know what you're talking about andyou're sure you're correct about it. By what is going on I don't meansymptoms (those are relatively easy, although tedious, to get right) butwhat
Accidental bittorrent on our networks
Several times now we've had cases of 'accidental BitTorrent' on ournetworks (and generally gotten email from the campus network peopleabout it); people running BitTorrent clients on our networks withoutintending to. It turns out that this is an amusing (to me) consequenceof the pervasiveness of laptops and laptop hibernation these days.
(You might reasonably ask why we 'allow' BitTorrent at all. There's atleast two reasons; first, without deep packet inspection (and maybeeven then ) we
A thought about filesystem snapshots
Here is an aphorism:
Filesystem snapshots preserve mistakes, and so public snapshots preserve mistakes publicly.
This isn't an issue unique to snapshots; it's common to any backupsystem that offers public or 'self serve' restores. In theory a systemthat only let you see or restore files that you owned would avoid theproblem, but the simple version would make certain files inaccessible(files you owned inside directories that other people owned, unless thesystem made an exception for that). Plus it only really