Good list of software sucking. I think this mostly serves to highlight lack of legibility (software is intangible, non-discoverable, opaque). I might write a bit about this sometime.
40 different fruits grafted onto the same trunk. design.
Role models matter. So I made a list of small companies that I admire. Neither giants nor startups - just people making a living writing software on their own terms.
My last post was on Where’s My Flying Car?, which argues that changing US attitudes created a tsunami of reluctance and regulation that killed nuclear power, planes, and ate the future that could have been. This explanation, however, has a problem: if there are many dozens of nations, how can regulation in one nation kill a tech? Why would regulatory choices be so strongly correlated across nations? If nations compete, won’t one nation forgoing a tech advantage make others all the more eager to try it?
Nice demos, great explanation of distance fields used for ray marching
Ray marching’s core idea is this: the distance field tells you how far you are from the closest glyph. You can safely advance along your ray by that distance without skipping over any glyphs.
Hacker News post linking to someone’s comment that he’s a carpenter now gets over 1100 points. Clearly software devs are finding something lacking about today’s tools.
Colin Percival defends his choice to work on Tarsnap rather than “solving millenium problems”. Also see patio11 tweet below.
So why am I not an academic? There are many factors, and starting Tarsnap is certainly one; but most of them can be summarized as “academia is a lousy place to do novel research”.
In many ways, starting my own company has given me the sort of freedom which academics aspire to.
In short, academic institutions systemically promote exactly the sort of short-term optimization of which, ironically, the private sector is often accused. Is entrepreneurship a trap? No; right now, it’s one of the only ways to avoid being trapped.
Hardware, systems and algorithms research communities have historically had different incentive structures and fluctuating motivation to engage with each other explicitly. This historical treatment is odd given that hardware and software have frequently determined which research ideas succeed (and fail). This essay introduces the term hardware lottery to describe when a research idea wins because it is suited to the available software and hardware and not because the idea is superior to alternative research directions. Examples from early computer science history illustrate how hardware lotteries can delay research progress by casting successful ideas as failures. These lessons are particularly salient given the advent of domain specialized hardware which makes it increasingly costly to stray off of the beaten path of research ideas. This essay posits that the gains from progress in computing are likely to become even more uneven, with certain research directions moving into the fast-lane while progress on others is further obstructed.
I’m starting to think I should do this more often.
Jean Gallier’s books are amazing.
See on the use of a life above.