On the other hand (and I'm slightly playing Devil's advocate here), books and other physical media go out of print eventually. It can become difficult to find a copy of some archaic technical manual that interests you. (Anyone selling any Symbolics manuals? :-))
There is no reason for a digital publishing to stop creating new copies of a digital work (once they finally develop an economic model that works.)
Honestly, I think this is one of the best use cases for piracy. There may be no money in putting out a Symbolics manual, but it costs a pirate uploading a digital version almost nothing. Look at older video game emulation as well. It's probably not worth it to the companies to continue to put out the type of games that wind up on abandonware sites, but thanks to dedicated fans who pirate them, they wind up preserved for future generations.
Emacs does not come with a lot of features built in, it comes with lots of loadable modules. If you don't need them then don't load them. The notion that Emacs is bloated has not really stood since around 1985.
The power to write a first person maze (which just blew my mind since it appears to be written as a character based hack, rather than an embedded widget) is the same power that allows you to write powerful libraries for modifying text.
Why not stop rendering HN pages in tables with inline formatting and render the page as a semantically structured document with a default style sheet. This will allow others to come along and restyle the site as they see fit. Don't like comment points? hidden. Post score is less than -4? hidden.
I personally don't understand the reasoning behind using tables as formatting and inline styles on a site whose content generally includes articles about web development.
The question about comment points is "do I think HN works better if comment points are hidden for all users", not "do I want to see comment points myself".
And to the second point, HN is PG's experiment with the programming language he's developing and the community for his company more than an example of modern web design. The point is probably that tables were quicker and easier.
Rendering a page as a semantically structured document won't remove the ability to globally disable a feature. (In fact, I would argue that it would make it easier.)
It's fair enough that pg does whatever he likes... no one can argue that point.
The Haskell 98 standard prelude is 39 kb big. Computers with less RAM than that were in use in the early 1980s. Since you're obviously an engineer by training, you may now ask why somebody would try to load an Haskell prelude in the early 1980s on a computer that isn't even capable of running a Haskell programme.
Anyway, I guess what I actually wanted to say got lost in the space between.
Actually, I'm wondering what Haskell has to do with any of this at all.
You're comparing the size of the current incarnation of a fairly modern functional programming runtime with the capacity of computers that existed 10 years before the first incarnation was realised...
The only message I can take from that is that programs today are quite big. That's only really interesting from a nostalgic point of view, I don't see what relevance it has to the discussion of mutability?
Of course, I could have missed something obviously significant here...
The parent poster was talking about immutability, "the early days" and copying data. I think my point was that you don't have to copy data all the time but this requires a clever interpreter/compiler that you could not have run "in the early days".
I'd also like to use the opportunity to say that I find those OOP vs FP posts at HN rather pointless.
Mutable objects are there so that you don't have to create new instances whenever a field changes. The danger of shared mutable objects is that the ground can change beneath your feet.
Immutable objects enable safe sharing, however, if you have an immutable object and want to change it, you have to copy it and make the change during construction of the new object.
I guess the 'copy penalty' in either case depends on the size of your objects.
If your compiler is smart enough (i.e. you are programming in clean, or use Haskell's GHC) the `copy penalty' can be zero for objects that only have "one future", i.e. you only ever keep one copy of your structure. (And that's still cleaner and safer than mutable structures.)
The `copy penalty' for multiple uses of your objects, say a = update1 (x), b = update2 (x), does not depend so much on the size of your object as one the amount of sharing you can do. Immutable objects allow sharing. For mutable ones you have to work much harder.
The 'us and them' mentality exists across many boundaries and I don't think it's going away any time soon. Most just learn to ignore it because whatever you decide is good, someone, somewhere, disagrees with you.
