# Input/output in 'mathematical' programming languages [closed]

More than once I have observed this: A person describes a functional programming language (as opposed to a programming language that makes heavy use of interspersed states), that person will say it is very mathematical, so we should use the language of mathematics; then to demonstrate, begins, "Let's say we have a function f that takes input x and gives output y..." or something like this.

This bugs me because I have never heard a mathematician describe a function as taking inputs and giving outputs. Instead, I believe, a function is thought of as a map, and it could be said that the domain, the map, and the co-domain all exist at the same time.

In the world of computer processing, a certain time duration is typically associated with an operation, but it does not have to be: it could be that the language representation does not truly represent the operation directly (the function might even be completely removed by the code compiler or interpreter), or maybe the function actually takes some different input than it is thought to, is distributed over many processors, etc. In short, the machine operations are not necessarily represented in a straightforward way for human interpretation by the programming language.

Furthermore, the time for the operation might be negligible, might be run parallel with another operation, or the steps of a program might be run in a different sequence. It might even require some other later operations not obvious to the observer, so might have an influence on other points in time.

I think there is a more fundamental conflict possible, though. As expressed by Schopenhauer in 'The Four-Fold Root', there is a problem applying the concept of 'causation' in the physical sense to the metaphor of logical 'causation'.

Computer processing seems to be right in the space between 'inference as a physical model' and 'inference as a logical model'. Is this a fundamental problem as I've expressed it? Is it possible that these mixed metaphors are going to become more problematic as the field of data processing progresses?

• While I see paragraphs and formatting (which is a good sign), I'm not quite seeing where the philosophy question is. I see a lot of statements about computing though. Could you somehow highlight the question that you're asking here? Jan 17, 2015 at 1:06
• Welcome to Philosophy! This sort of reads more like an answer than a question -- is there any chance you can try to specify a little more explicitly what exactly the problem is that you're encountering in your study of philosophy? What does an answer to this question look like in your mind; what exactly would you like someone here to explain to you (in a few paragraphs)? Jan 17, 2015 at 16:26
• Hi, thank you! Maybe my question was more of an answer than a question, and perhaps a bit broad. I was really hoping to expand my studies by getting a reference in philosophy or history in an answer. @CortAmmon's answer was good, but I thought "anything is possible" and "metaphors change" didn't quite get at the point, although they might have been extended. The 'In Short' section of Keelan's answer, while somewhat opinion-based, was a pretty good outline. quen_tin's answer was pointed but didn't have supporting reference. FredBarker's had a reference but didn't quite get to the issue.
– dwn
Jan 18, 2015 at 13:38

I don't think we're really doing anything else than using different words for the same thing. If you for example look at the Haskell `mod` function for modulo:

``````mod :: a -> a -> a
``````

Mathematically, the modulo function is something like   Z × Z → N   (where Z is the set of integers; N is the set of natural numbers, non-negative integers).

You can see the same in Haskell, except that they don't distinguish between Z and N, which is mathematically correct, and that they use only arrows instead of × and an arrow.

In math we call the left of the arrow the domain and the right the codomain; in functional programming we call the left the inputs and the right the outputs.

The use of the words 'input' and 'output' in the context of a functional programming language is horrible, because input and output change and functional languages are based on the idea that things don't change. When you're using actual input and output (things that change), you're using the language in a way that is not strictly functional anymore, with the use of monads. However, when someone understands the concept of a functional language, I don't think using 'input' and 'output' can do more harm than cause some confusion.

You're also talking about the difference that computing takes time. Functional languages are sometimes lazy, meaning that one will only calculate stuff when it needs to. For example, we can put the whole (infinite) set of natural numbers in a list, as long as you don't tell it to calculate all members (by asking for the sum or something like that). This concept of laziness is in fact very similar to what we do in math. When we prove something, we rarely actually calculate something.

The point of physical inference versus logical inference is a good point, especially since making hardware for functional languages is hard. Research is being performed on the university of York, where they are developing the Reduceron, but as far as I know this is not yet on a level that we can see that the machine is fully functional.

Maybe, but I'm not sure, this (physical level vs. logical level) is actually the reason that making hardware so hard: that we're trying to build something which belongs in a totally different world. Was Schopenhauer perhaps the first computing scientist? :)

I'm not completely aware of the limitations of functional programming languages, but it may be theoretically possible to order it to calculate something for which it will need something infinite (be it time or memory), whilst math can do it without much trouble.

### In short:

• I don't think functional languages treat functions much different than math does, although programmers may use confusing terms.
• The difference operation time makes can be largely decreased by using lazy execution.
• Physical causation trying to imitate logical causation may certainly cause problems, but we're not that far yet.
• I don't think quantum computing would reverse the time arrow or anything, but I do wonder if it could change the understanding of processing time, with reversible operations and such. On another note, I've only recently started using Clojure for webscripting, but have kind of bounced away from Haskell. Can't help wondering if I'll miss something from it, though.
– dwn
Jan 16, 2015 at 23:48
• @dwn an important difference is that Clojure is impure, 'in that it doesn't force your program to be referentially transparent, and doesn't strive for 'provable' programs. The philosophy behind Clojure is that most parts of most programs should be functional' (from clojure.org/functional_programming) - when the language isn't fully functional, different things may apply. As far as I know Haskell comes the closest to fully functionalness. However, that also makes it kind of difficult to use if you're not doing something purely mathematically.
– user2953
Jan 16, 2015 at 23:52
• @Keelan - Well, Idris? Coq? Haskell isn't really the most functional, just the most functional of the arguably real-world-usable languages (in that it has libraries, can deal with keyboard input, etc.). Jan 17, 2015 at 4:09
• It's not the case that functional languages, even pure functional languages, are generally lazy. Haskell is unusual in that. (It's also unusually prominent among the pure functional languages.) Jan 17, 2015 at 5:32
• @RexKerr thanks, my knowledge doesn't reach so far.
– user2953
Jan 17, 2015 at 9:21

Lazy answer: Yes, anything is possible

Okay, now for the longer answer

I think the wording difference between "input/output" and "mapping" is used because of side effects. Mathematical mappings have no side effects, they are simply mappings. The difference between having a value, 1, and having a complicated equation evaluated at a point which maps to 1 is unimportant unless you want to operate on the equation explicitly.

Functional programming languages try to avoid side effects, to achieve a similar mathematical purity. However, there are side effects which cannot be avoided, such as the consumption of computing resources. This forces people to think in slightly less mathematical terms. For one thing, every functional programing language has at least one procedural concept, "evaluate," which kicks the process off. This little kernel forces programmers to think slightly different.

The functional programmers do have one valid argument: if I have to evaluate f(1, 2), the answer doesn't change if I evaluate f(1,2) and f(3, 4). A functional language could be thought of as every value-coexisting at once, compared to procedural languages which have side effects that prevent us from having the freedom to execute arbitrary code.

As for metaphors becoming more problematic, that depends on what you consider problematic. Consider that all metaphors over all time have all been problematic, because that is how metaphors work. There is not a field of study in the entire world which does not have an ecosystem of metaphors that rise up when they are helpful, and wane as they become less useful. I fully expect this pattern to continue within computing.

There are already great examples of places where metaphors have broken down. Consider, in the procedural programming world, multithreading. For the longest time, we could use the von Neuman machine as a metaphor for our actual computer. However, with modern atomic operations, we are forced to admit the presence of memory caches and other things which do not appear in the metaphor. C++ just released a new specification that includes atomic operations. 90% of the specification's treatment of atomics is now on things which cannot be explained using the von Neuman machine. The solution was that C++ invented a new metaphor: the C++11 memory model, which gets closer to what modern hardware does. When that model fails, we'll invent a new one.

A function in mathematics is often said to take inputs and give outputs. A function is a more restrictive concept than a general relation between two domains: it will map only one value in the output domain to each value of the input domain (it's a many-to-one relation). This is also a definite characteristic of functions in a functional programming language. A mathematical function is not strictly speaking a programming function, but based on these similarities, it is a useful abstraction to address the latter (contrarily to imperative languages where some functions can return different values at different times, for example when they use state variables or external inputs such as clock). In any case there are strong relations between mathematics and algorithmic. Both have the same logico-mathematical foundations.

The programmer can expect a direct correspondance between the code and the compiled program. Each implemented operation will be performed as such. Perhaps they will be optimized, but the result is guaranted to be the same by the compiler. Otherwise programs would not be reliable. In other words, a programmer can reliably reason "as if" the computer were actually reading the code at execution time and applying mathematical functions as a mathematician would do.

Optimizations at compilation time result in less reliability as for duration expectations (only result is guaranted), but in most cases, getting the same result will amount to do the same operations and an estimation of durations based on the code will give approximatively good result. I think the general structure of the program is generally reflected in the compiled program.

In imperative programming languages there are technics to get more accurate duration measures at runtime, which are used for profiling (improving the efficiency of the program). I don't know if they exist for functional languages.