31–40 of 98 posts
As a matter of fact, everything didn't descend from FORTRAN. COBOL was heavily influenced by FLOW-MATIC which descended from the A-0 System. All three of these were created mostly due to the work of Grace Hopper, commonly called "the mother of COBOL."
> Every programming language used today is descended from FORTRAN As a matter of fact, everything didn't descend from FORTRAN. COBOL was heavily influenced by FLOW-MATIC which descended from the A-0 System. All three of these were created mostly due to the work of Grace Hopper, commonly called "the mother of COBOL."
One of those ideas, I believe, is expression of programs as text. It wasn't even a distinct idea, it's just the most efficient, natural way to express algorithms. You can't get around the fundamental mathematical fact that you need a formal symbolic system to express algorithms, i.e. you need a language. Until we gain the ability to directly interface our brains with computers we'll need to express language in written symbols, and even then I doubt we could get away without text for cognitively expensive activities such as programming (because of limitations of our working memory, etc.). "Lines of text" are anything but limiting.
What the article says are some drawbacks of operating systems I don't think are drawbacks at all. Having the OS lying to programs so that they don't have to know irrelevant details of the machine is a really good thing.
> But when it comes to what the machine is actually doing, why not just run one ordinary program and teach it new functions over time?
What?! You mean like one monolithic piece of code doing everything ranging from memory management to email and multimedia? I must be missing something, am I stupid and just don't understand the proposal?
> Why persist for 50 years the fiction that every distinct function performed by a computer executes independently in its own little barren environment?
Because it's a good idea, it reduces complexity for the function (program) in question.
> A righteous operating system should be a programming language.
Like we had with some early PCs where you essentially had a BASIC interpreter for an OS? That concept got replaced because it was a horrible way for humans to do actual work instead of dicking around all day with toy programs.
> Let’s do some old-school hacking on our new-school hardware — like the original TX-0 hackers, in assembly, from the ground up — and work towards a harmonious world where there is something new in software systems for the first time since 1969.
While I have nothing against assembly (to quote Michael Abrash: "I happen to like heroic coding."), first, I find the idea of regressing to old methods of producing programs to yield new ways of computing a little strange, and second, there's a good reason assembly isn't used unless necessary--it's a horribly unproductive way to solve problems. Unless the assembly in question is Lisp. ;) Or Haskell. So if we're dreaming, let's dream all the way--we need pure functional computing machines, not just "better mouse traps".
> 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…
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
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…
Shared Memory seems dangerous because you assume that both actors are behaving correctly. The reason why programs are isolated I always thought wasn't because programmers were lazy but to ensure that a malicious or a badly written program can be contained.
Isolation was a protection about badly written programs, but it was mainly about simplifying things and increasing the (virtual) memory available.
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.
I would love to read that if you could post it.
Interesting article, but I think that the basic premise, that it's "bizarre" that we're still using concepts developed 50+ years ago, is a bit naive. To give an analogy from a different engineering field, the basics of rocketry and space travel have been conceptually almost completely developed almost 100 years ago. Multistage rockets, orbital stations, etc. Should it be considered bizarre that we still use those sam…
>Like we had with some early PCs where you essentially had a BASIC interpreter for an OS?
I think that line has some relation to the graphical programming language at the beginning. If so, no, it's nothing like old BASIC interpreters, and more like making GUIs out of interoperating modules.
> 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
> 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…
It's just another stage of the storage hierarchy, isn't it? Registers → CPU cache → DRAM → Flash storage → spinning-rust storage → network storage → archive storage.
It's not practical to cover all of those with the one abstraction (having a CPU read-byte instruction pause while a robot navigates a warehouse to find the right backup tape is a bit ridiculous), but what we have at the moment is mostly a reflection of the way our technology ecosystem has developed, rather than the best way to organise and cache information.