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

51–60 of 98 posts

Re: Systems Past: The software innovations we actually use

#51

Post by davidad_ »

TheZenPsycho wrote: post #43
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?

Yes. I am working on it, but it is "kind of hard" to do by oneself. Also, writing about it is a good step, regardless of who might be convinced or not, simply because it forces me to get my ideas more straightened out.

Re: Systems Past: The software innovations we actually use

#52

Post by nandemo »

cscheid wrote: post #34
tikhonj wrote: post #14

> FORTRAN’s conflation of functions (an algebraic concept) and subroutines (a programming construct) persists to this day in nearly every piece of software, and causes no end of problems. This is exactly what Haskell solves. Not by eliminating subroutines, but by separating the two concepts out again. In particular, functions are functions in the algebraic sense, and subroutines just become values in the IO type. > T…

> 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

Your link is a good example of partiality:

> user error: Table './ltu/cache' is marked as crashed and should be repaired query: SELECT data, created, headers FROM cache WHERE cid = 'filter:4:37963a22e3cdd6b501519c657a75ceeb' in /home/vhost/ltu/www/includes/database.mysql.inc on line 66.

Re: Systems Past: The software innovations we actually use

#53

Post by davidad_ »

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…

This indirection already happens in present systems. Check out my previous blog post about it: http://davidad.github.io/blog/2014/02/19/relocatable-vs-posi... Modern hardware is optimized to do this kind of indirection reasonably fast. What I propose can exploit the same hardware acceleration.

Re: Systems Past: The software innovations we actually use

#54

Post by StandardFuture »

Most of the comments in this discussion are missing the point of this article in almost its entirety. I am seeing everything from "Haskell is the most mathy of the languages and resolves an approach to algebraic concepts!" to "This article is bullshit!" ... Sad, really.

An easy way to summarize what this article is trying to convey can be derived from the title of the article: Systems Past. The next chapter would simply be: Systems Future. And this is what the author is trying to get across.

There is nothing wrong with languages or OSes. What's wrong is a seemingly pervasive attitude throughout the hacker community to never want to improve on foundational concepts. This is usually argued as: 'if it ain't broke don't fix it'.

One critique of this article I will give is: these software innovations are dependent on the hardware architectures used. And we have been using the same basic computer architecture for decades. So maybe it is not fair to assume revolutionary systems innovations should happen before we have revolutionary hardware systems to program?

Re: Systems Past: The software innovations we actually use

#55

Post by Dylan16807 »

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…

Local networking can be significantly faster than accessing a hard drive. It's very common to have only network filesystems. Look at EC2, for example. Toss a cache on it and everything's good.

Re: Systems Past: The software innovations we actually use

#56

Post by merak136 »

Am I the only one impressed with how long some of these technologies have been around? I know most of the common ones such as the internet and FORTRAN but I did not realize how long markup languages have existed. Also at the rate that technology improved in such a short amount of time. That must have been an exciting time to work in the field.

Re: Systems Past: The software innovations we actually use

#57

Post by jagger27 »

TheZenPsycho wrote: post #47
akkartik wrote: post #8

Only? No mention of viewport clipping? Compression? Encryption? Bittorrent?

would the way we use computers be completely unrecognisable without those things?

What would the internet look like without encryption?

Re: Systems Past: The software innovations we actually use

#58

Post by andrewflnr »

Millennium wrote: post #20
ariwilson wrote: post #6

Haven't people been communicating information to other people as text for thousands of years? I'm not so convinced that there's a universally better mechanism for communicating with machines.

Text isn't as important as language itself, but there's the rub: no one has yet devised a better way to program computers than language. Even the so-called "visual environments" we see today ultimately boil down to recognizable linguistic concepts: they do it by arranging shapes in space rather than writing text, but you can pick out the same nouns, verbs, and other parts of speech. And that's the problem. Visual env…

What, precisely, do you mean by language? Machine language doesn't exactly have grammar the same way that human language does, and I can't interpret a concatenative language that way either (which is much higher level). We're not going to get away from the idea of a linear sequence of bits/symbols, but beyond that almost anything goes, and indeed probably has gone.

Re: Systems Past: The software innovations we actually use

#59

Post by andrewflnr »

davidad_ wrote: post #51
TheZenPsycho wrote: post #43

Earlier quoted context omitted.

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?

Yes. I am working on it, but it is "kind of hard" to do by oneself. Also, writing about it is a good step, regardless of who might be convinced or not, simply because it forces me to get my ideas more straightened out.

I'm quite curious where you intend to go with the "mesh" project on Github. "An operating system with the heart of a database" sounds like some of my ideas, as does your doc/index.md, but it seems to stop there.

Re: Systems Past: The software innovations we actually use

#60

Post by davidad_ »

StandardFuture wrote: post #54

Most of the comments in this discussion are missing the point of this article in almost its entirety. I am seeing everything from "Haskell is the most mathy of the languages and resolves an approach to algebraic concepts!" to "This article is bullshit!" ... Sad, really. An easy way to summarize what this article is trying to convey can be derived from the title of the article: Systems Past. The next chapter would sim…

I am very happy that you get the point! :-)

To address your criticism: Internetworking fundamentally required new hardware, Interactivity and Hypermedia depended on advances in display technology, and Virtualization and Transactions benefit substantially from hardware acceleration. However, the OS, the PL, and the GC were all independent of any new developments and hardware. Our display technologies are already way ahead of the computational features they should be able to support. Same goes for telecommunications. And the hardware acceleration that powers virtual memory and memory locking is versatile enough to be applied to more advanced abstractions as well (although the advanced abstractions might later benefit from more advanced acceleration).

I spent a few years at MIT trying to design revolutionary hardware systems and left with a deep respect for Intel. Much as I'd like to have a PC based on the Lisp Machine or the Connection Machine, I've come to believe it's we software folks who really aren't keeping up, rather than any kind of stagnation in the hardware world.

In fact, Intel comes out with a whole pile of new machine instructions every other year, and they probably never get invoked once on most PCs: most binaries are effectively compiled for AMD Opteron (the first x86_64 processor, released in 2003) so that they'll run seamlessly on anything since then.

Post reply on HN