Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systems Past: The software innovations we actually use

davidad.github.io

Post reply on HN
Print view View original

41–50 of 98 posts

Re: Systems Past: The software innovations we actually use

#41

Post by mwcampbell »

On the one hand, the article challenges us to question established ways of doing things. On the other, the first footnote correctly points out some projects that were economic failures because they were technology for its own sake rather than providing something of value to people.

Some of us may have the freedom and the desire to hack on things that are destined to be economic failures. But for the rest of us, I think it's more important to err on the side of technologically conservative but economically successful projects. So, most of us, myself included, will continue to work within the context of established programming languages, operating systems, and other groundwork that has already been laid for us.

Re: Systems Past: The software innovations we actually use

#43

Post by TheZenPsycho »

pdonis wrote: post #42

If this writer is so convinced that we need a new way of interacting with computers, why isn't he building it, instead of just writing about it?

Because software actually is kind of hard, and to get anywhere you need to convince a somewhat larger group than one to all work towards the same goal.

And how do you know he is not?

Re: Systems Past: The software innovations we actually use

#44

Post by nandemo »

stevepike wrote: post #39
cscheid wrote: post #34

Earlier quoted context omitted.

> functions are functions in the algebraic sense This is a minor nit, but there are effects in pure Haskell functions, namely partiality and non-termination. (In other words, the sense in which "functions are functions" is actually a deep question) There's plenty of academic discussions on how to solve this problem. See stuff like this: http://lambda-the-ultimate.org/node/2003

Non-termination makes perfect sense, but would you mind sharing a layman explanation of what you mean by the effects of partiality?

Roughly speaking, partial functions are functions that might crash -- or that might throw exceptions, if you prefer. So even if it always terminates, it might to do so at the cost of not returning a value of the expected type.

A bit more precisely, a partial function is a function that is not defined for some values of its domain (its input). A well-known instance is the division operator, which is not defined when the divisor is zero. Other common examples are head and last:

    -- this promises to receive a list of elements of some
    type t and return the first element
    head :: [t] -> t
    head (first:rest) = first 
    head [] = error "that list has no head, yo!"
Where error is analogous to throwing an unchecked Throwable (eg RuntimeException) in Java.

One solution is to use a safer version that returns Maybe a instead of a. This is analogous to using checked exceptions.

    safeHead :: [a] -> Maybe a 
    safeHead (first:rest) = Just first
    safeHead [] = Nothing
The solution above is common and idiomatic.

Another option is to accept only arguments of a different list type that's guaranteed to be non-empty.

Re: Systems Past: The software innovations we actually use

#45

Post by TheZenPsycho »

zanny wrote: post #25

> Virtual memory should have been extended to network resources, but this has not really happened. I get that we are already operating in heterogeneous virtual memory worlds, but network transactions are so slow. I can't see it being useful to have them as virtual addresses if random reads and writes to network space take literal seconds of round trip. That is so much worse than even disk, there is a reason networkin…

perhaps it was meant in a different sense- I thought he meant that a "socket" resource shouldn't have the programmer specifying the physical hardware and port number while other programs have the ability of monopolising that resource.

Re: Systems Past: The software innovations we actually use

#46

Post by TheZenPsycho »

greatsuccess wrote: post #17

Quite a load of shit. Those innovations are now taken for granted and the "this was then", "this is now" comments it where you see the leakage in the arguments. Im not going to quote anything from this to dismiss it. Its simply wrong, a bit extreme, and out of context. You would have to be an idiot to buy the entire premise.

This comment is a load of shit, and so since you're happy to dismiss an entire essay without any back up, evidence or argument, I can just as easily dismiss your comment. Hitchen's razor.

Re: Systems Past: The software innovations we actually use

#49

Post by MaysonL »

gumby wrote: post #2

This is an outstanding essay -- more fields need this kind of thinking. Plus it's doubly ironic having it in computation, a field that has always seemed determined to ignore history, and reinvent it. A nano nit: Yes, GC came from Lisp, but its first mention was in AI Memo #1 (the first MIT AI Lab working paper) by Minsky. I have a copy someplace -- it was only a few pages long.

micro nit: McCarthy, not Minsky

Re: Systems Past: The software innovations we actually use

#50

Post by MaysonL »

netdog wrote: post #29

See David Wheeler's page, The Most Important Software Innovations " rel="nofollow">http://www.dwheeler.com/innovation/innovation.html> . The page has been online and refined for 12 years. It lists things such as the Stack, Packet-Switching Networks, Spelling Checker, Relational Model and Algebra (SQL), and quite a few other useful and important software innovations.

http://www.dwheeler.com/innovation/innovation.html
Post reply on HN