Excerpt:<p><i>We have always been store-poor. We've been mill-poor, too: our processors have been slow, running at hundreds, then a few thousands, of cycles per second. We haven't been able to afford the cycles to do any sophisticated munging of our data. What we stored - in the most store intensive format we had - was what we got, and what we delivered to our users. It was a compromise, but a compromise forced on us by the inadequacy of our machines. ...<p>The compromises of poverty are built into these operating systems, into our programming languages, into our brains as programmers; so deeply ingrained that we've forgotten that they are compromises, we've forgotten why we chose them. Like misers counting grains on the granary floor while outside the new crop is falling from the stalks for want of harvesting, we sit in the middle of great riches and behave as though we were destitute. ...<p>Every mistake, every compromise to poverty ingrained in Java is there in C# for all the world to see.<p>It's time to stop this. Of course we're not as wealthy as Turing. Of course our machines still do not have infinite store. But we now have so much store - and so many processor cycles - that we should stop treating them as finite. ...<p>Historically, when storage was expensive we stored textual values in fields of fixed width to economise on storage; we still do so largely because that's what we've always done rather than because there's any longer any rational reason to. ...<p>But it is no longer necessary, nor is it desirable, and good computer languages such as LISP transparently ignores the difference between the storage format of different numbers. ...<p>Interestingly, Paul Graham, in his essay 'The Hundred Year Language', suggests doing away with stings altogether, and representing them as lists of characters. This is powerful because strings become S-expressions and can be handled as S-expressions; but strings are inherently one-dimensional and S-expressions are not. So unless you have some definite collating sequence for a branching 'string' it's meaning may be ambiguous. Nevertheless, in principle and depending on the internal representation of a CONS cell, a list of characters can be of indefinite extent, and, while it isn't efficient of storage, it is efficient of allocation and deallocation; to store a list of N characters does not require us to have a contiguous lump of N bytes available on the heap; nor does it require us to shuffle the heap to make a contiguous lump of that size available. ...<p>Welcome, then, to post scarcity computing. It may not look much like what you're used to, but if it doesn't it's because you've grown up with scarcity, and even since we left scarcity behind you've been living with software designed by people who grew up with scarcity, who still hoard when there's no need, who don't understand how to use wealth. It's a richer world, a world without arbitrary restrictions. If it looks a lot like Alan Kay (and friends)'s Croquet, that's because Alan Kay has been going down the right path for a long time.</i><p><pre><code> .
</code></pre>
I previously asked, "4 gigs of DRAM costs less than $100, today. Who cares if software is bloated?" <a href="http://news.ycombinator.com/item?id=305937" rel="nofollow">http://news.ycombinator.com/item?id=305937</a><p><pre><code> .
</code></pre>
Julian Simon's apropos quote of Shakespeare (Sonnet 1):<p><a href="http://www.juliansimon.com/writings/Ultimate_Resource/TCHAR33.txt" rel="nofollow">http://www.juliansimon.com/writings/Ultimate_Resource/TCHAR3...</a><p><i>Making a famine where abundance lies, ...
And, tender churl, mak'st waste in niggarding.</i>