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

91–98 of 98 posts

Re: Systems Past: The software innovations we actually use

#91

Post by theoh »

anon4 wrote: post #67
efnx wrote: post #62

Earlier quoted context omitted.

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 conv…

In a purely mathematical sense, if tan(pi/2) doesn't denote a number, what is its type as a value?

Re: Systems Past: The software innovations we actually use

#92

Post by lutusp »

anon4 wrote: post #67
efnx wrote: post #62

Earlier quoted context omitted.

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 conv…

> 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.

No, they are a notation for ideas. The fact that they have numerical values associated with them is true but misses the point that trigonometric functions are primarily defined with respect to each other and with respect to certain geometric concepts.

In other words, cos(0) equals 1, but 1 has many more meanings than just cos(0). I would much rather have a student tell me that tan(x) = sin(x) / cos(x) than to say tan(x) is just a number.

Re: Systems Past: The software innovations we actually use

#93

Post by lutusp »

theoh wrote: post #91
anon4 wrote: post #67

Earlier quoted context omitted.

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 conv…

In a purely mathematical sense, if tan(pi/2) doesn't denote a number, what is its type as a value?

tan(pi/2) is undefined, like 1/0.

http://math.stackexchange.com/questions/189621/is-tan-pi-2-u...

Re: Systems Past: The software innovations we actually use

#94

Post by pinealservo »

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

The Haskell language is described in The Haskell Report via an informal presentation of its denotational semantics. Its types are all "lifted" from Sets to something like Scott Domains to account for partiality and non-termination, which are denoted by the value called "bottom" or _|_.

So, they are not strictly functions in the normal set-theoretic sense, but they are (mostly?) mathematically accurate continuous functions between Scott Domains. As the semantics are not formally defined, there is a limit to what you can say about them, but there is an interesting paper entitled "Fast and Loose Reasoning is Morally Correct" that shows that treating Haskell as if it worked in terms of total set-theoretic functions is a reasonable thing to do in some practical circumstances in the use of Haskell.

If you want really pure, total set-theoretic functions in a programming language, you will have to go to a total functional language such as Coq or Agda. You lose Turing-completeness when you stick to total functions, though, and most people only type-check their functions rather than actually running them (this is not as crazy as it sounds--these languages are primarily used to help formulate formal proofs, which are finished when they pass the type-checker).

In any case, the bit in the blog about FORTRAN and everything conflating procedures and algebraic functions strikes me as nonsense, at least without further explanation to clarify/justify it.

Re: Systems Past: The software innovations we actually use

#95

Post by pinealservo »

anon4 wrote: post #67
efnx wrote: post #62

Earlier quoted context omitted.

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 conv…

To be really pedantic, "algebraic functions" are functions that can be defined as the roots of polynomial equations, I.e. solutions of equations of the form f(x_1, x_2, ..., x_n) = 0. There are other, more general notions of "function" in mathematics, though. I'm not sure how pedantic the author of the original post meant to be!

Most generally, a function is not a number, it is a relation between two sets. One can define such things in a number of ways, but one way is to describe the relation via a formal language such as the lambda calculus. The lambda calculus is not technically a "programming language", it is a formal system of meaningless symbols and a set of rules for forming, manipulating, and eliminating them.

Although there is no fixed relation between reduction rules in the lambda calculus and physical resources in a computer, one can still compare the number of reduction steps required to determine which form in the co-domain of a function defined in the lambda calculus corresponds to a specific form in its domain, and this will provide a reasonable stand-in for comparisons between resource usage of similar computer programs.

So, really, computation is not completely foreign to mathematics, and mathematical functions and "computing functions" are not completely different animals, just... distantly related? Some languages are more mathematical in their approach than others.

Re: Systems Past: The software innovations we actually use

#96

Post by pinealservo »

I wholeheartedly agree with the sentiment expressed by the introduction to this article. We really do seem to have got stuck in a deep rut, where we can make progress laterally but can't seem to come up with anything truly novel to move the state of the art dramatically forward.

I have some issues with the style of the rest of the article, though. It consists of a lot of very interesting and thesis-supporting facts, but they are couched in a lot of arbitrary statements ("only 8 software innovations...") of dubious facts that don't seem very well supported on their own.

I mean, yes, you say there are eight and then list eight, but I am not left convinced that those are the ONLY eight. You say that all languages (aside from a bit of backpedaling in the footnotes) are descended from FORTRAN, which is a pretty bold claim to make, but the justification you provide seems to reduce "descended from" to a mostly meaningless "probably borrowed some ideas from" that is hard to base any value judgement on. Surely not all ideas in FORTRAN were misguided!

The whole rest of the article continues in this pattern, distracting from basically good points with brash and sometimes bizarre (from my perspective, at least) statements that seem to belie a wide but very spotty understanding of computing history. Granted, it's been chaotic and not terribly well-documented, but that ought to give one second thoughts about writing with such a definitive and dismissive tone.

I want to repeat that I agree with the general premise, and I think that it's unfortunate that I came away from the article feeling like I disagreed with it due to the problems noted above. I had to re-read the intro to remember the intent. Hopefully this criticism is accepted in the constructive sense in which I offer it, as I think that there's some great insight there that could be more effectively conveyed.

Re: Systems Past: The software innovations we actually use

#97

Post by renox »

HaloZero wrote: post #27

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.

I think that shared memory is bad because it doesn't scale: once you've saturated your memory bus because you have too many cores that use it, then you need to have several memory buses and 'shared memory' doesn't seem so nice anymore..

Re: Systems Past: The software innovations we actually use

#98

Post by gumby »

grinich wrote: post #4
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.

I would love to read that if you could post it.

The memo was not #1 but #58 (apologies -- my hardcopy is buried someplace, and I made it years ago when rummaging through Marvin's file cabinets for something interesting and ran across it).

But thanks to the miracle of modern science, it's online here: ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-058.pdf

#1 was JMC's memo on Lisp, but (tying back to this thread) you had to manage memory with CONS (malloc()) and erase (free()).

(I note the date was around the time the first PDP-6 was delivered to the AI Lab so the memo was probably timely. Boy, the PFP-10 (basically the 'real version' of the PDP-6) was such a pleasure to write for, with an instruction set that was basically lisp primitives.)

Post reply on HN