Earlier quoted context omitted.
would the way we use computers be completely unrecognisable without those things?
What would the internet look like without encryption?
so wait.
are you saying encryption… encryption was invented after 1970?
Systems Past: The software innovations we actually use
61–70 of 98 posts
Re: Systems Past: The software innovations we actually use
#62> 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
I always thought that algebraic functions are not guaranteed to be defined given certain parameters. It's just that perfectly algebraic functions don't throw errors, they silently return +-infinity. Like the asymptotes in `tan x`.
Re: Systems Past: The software innovations we actually use
#63For some truly innovative operating system and programming language, I recommend everybody to go learn about Urbit.
Re: Systems Past: The software innovations we actually use
#64Earlier quoted context omitted.
would the way we use computers be completely unrecognisable without those things?
What would the internet look like without encryption?
I included a footnote to address this criticism.
http://davidad.github.io/blog/2014/03/12/the-operating-syste...
Re: Systems Past: The software innovations we actually use
#65Earlier quoted context omitted.
Honestly I feel like this type of viewpoint is one that almost every programmer gets to after about 10 years doing real work. The difference is tact. Some hack out some experiments in new programming paradigms and some post detailed ideas or concepts of how things can be improved, and others just try to gain street cred by just saying everything is obviously shit and we are all fools for not "fixing" things.
Well said, sir. Worth noting that this overview of where we've come from and how not far we've come was posted by a fellow is both clearly a genius, and who has his most popular github project written in x64 assembly. So I'd argue that even he sees the merit in the past when attempting to blaze a trail into the future. For one thing, as long as our computers are binary, they are going to require instructions in a ver…
My entire article is about things that happened between 1955 and 1969. The part where I state my thesis literally concludes "With a solid historical perspective we can dare to do better." I'm not sure how much more obvious I could make it that I "see the merit in the past when attempting to blaze a trail into the future".
It's the _present_ whose merit I find lacking.
Re: Systems Past: The software innovations we actually use
#66For some truly innovative operating system and programming language, I recommend everybody to go learn about Urbit. http://www.urbit.org/
I am very glad that Urbit exists and is being funded. I have corresponded with the author and differ with him on some design decisions that I consider significant. Nonetheless, it is an excellent example of the "rethink everything" type of ambition that I would like to see expressed more.
Re: Systems Past: The software innovations we actually use
#67Earlier 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
I always thought that algebraic functions are not guaranteed to be defined given certain parameters. It's just that perfectly algebraic functions don't throw errors, they silently return +-infinity. Like the asymptotes in `tan x`.
To be pedantic, tan doesn't have a value at tau/4 (or pi/2, if you swing that way). Also, algebraic functions don't return, they are - cos(0) is 1, it doesn't return 1, it doesn't compute 1, it is not a kind of computer, nor a kind of program, nor any kind of thing that consumes resources and time and returns a value; it really literally is 1.
Algebraic functions are just syntactic notation. You can sit down and convert from one notation to another, like how cos(5) is a number quite close to 0.28366218546322625, and deriving one representation from the other does take resources and time, because it's a physical process performed by a person or computer.
But sin, cos, tan, cotan, log and all their friends by themselves don't compute, they are just a different kind of notation for numbers.
Which is why I find the desire to make functions in programming like algebraic functions silly - by definition they are two completely different things. One is a specification for a process that produces binary-encoded numbers, the other is a syntactic notation for real numbers.
Re: Systems Past: The software innovations we actually use
#68Haven'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.
This is a fair point which deserves a response.
Before text was invented, people communicated using spoken language. Text was a major breakthrough because once some communication was written, it became a physical object which could be stored in libraries, carried by sea or horseback, and read by more than one person. However, it was a compromise: you could no longer interact with the reader. As a result, most people prefer to communicate interactively. Even people who cannot speak use sign language instead of resorting to text.
What we are doing right now is a hybrid of textual and interactive communication; we're taking turns writing chunks of text. In the programming world, this is roughly equivalent to a REPL. But actually developing software using a REPL is still quite uncommon; I think it's reserved mostly for Emacs Lisp hackers.
We're doing this instead of communicating by audio partly to create a public indexable record of our correspondence, partly to protect our privacy, partly for synchronization reasons, and partly due to arbitrary norms and the information systems that co-evolved with them; but mostly to save ourselves from mentally keeping track of the edits we make to our expressions before committing them ("scratch that...what I meant to say is.."). When the target of one's communication is a machine with a visual display, that latter concern completely evaporates.
Naturally, the screen editor (introduced in 1961 as Expensive Typewriter for the PDP-1 and pretty well refined by the NLS era) implements this suggestion thoroughly. Yet, generally, the screen editor is used only to edit pieces of text, which are then separately turned into programs. What I'm proposing is nothing more outrageous than a screen editor which edits programs directly instead of textual representations thereof.
Re: Systems Past: The software innovations we actually use
#69> 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."
APL did not descend from Fortran either - it wasn't even designed as a programming language - rather as a standard notation for algorithms
Re: Systems Past: The software innovations we actually use
#70Is it just me, or is #2 (Operating System – running separate programs concurrently independent of one another) effectively the same as #6 (Virtualization)? It is the same idea – the programmer can pretend that the program has a machine all to itself.