In case you missed it, John discussed his functional programming adventures in Haskell at QuakeCon 2013... well worth a listen.
"So what I set out to do was take the original Wolfenstein 3D, and re-implement it in Haskell."
[...]
"I've got a few conclusions coming from it. One of them is that, there's still the question about static vs dynamic. I know that there was a survey just coming out recently where the majority of programmers are still really not behind static typing. I know that there's the two orthogonal axes about whether types are strong or weak, and whether it's static or dynamic. I come down really pretty firmly, all my experience continues to push me towards this way, that strong, static typing has really significant benefits. Sometimes it's not comfortable, sometimes you have to build up a tight scaffolding to do something that should be really easy, but there are real, strong wins to it."
I used to think that way too. I've met programmers who still don't write unit tests and are not test driven and remain brilliant. Carmack is one of these guys. I think the static / strong typing thing works well with them because they never developed the practices. If you're test-driven, you're basically building up your own, domain specific compiler as you go not having to play by a language-specific static type systems rules. Dynamic typing make writing code this way really easy. Static typing doesn't. In the end I want the types of my system to work they way my system needs to. I could care less about the type system of merely a language (as applied to my system). And types are just one way to enforce correctness.
Lately I find with languages in the Lisp family, these other types of tools feel much more productive, easier to reason about and flexible to me than type systems. When I believed in static typing I felt very busy, but I was mostly spending my time making the compiler happy, rather than the other way around.
Except that to perform the level of checks that a compiler does with a good type system, you would have to write a large amount of tests. Code is a liability, and testing code is no exception.
Writing tests in static languages is still required. You just have to write a smaller amount of them. What's more, type checking is enforced in a more systematic way. With tests, you have to rely on people to write them. If a type system is well designed, people will use it to model their code, and the type checking is done automatically.
What's more, types should not be reduced to the type checking phase. Types are a way to provide a high level model/structure. You still need this if you are working in a medium/large project. With static types, this model have nicer semantics, and is more useful.
Ok try this: Go model a square and a rectangle in your favorite statically typed language. You will find that square extends rectangle and setting the length on a square also sets the width. So far so good? So if I have a collection of rectangles which contains an unknown number of squares of which I set the width on each of them. You can't answer the question as to whether the result is correct or not. And I have just destroyed your type system's purpose by using polymoronism, expectoration and dispossession, the three-legged stool of static typing OO, with a very simple and well-defined domain subset of geometry.
Of course it's contrived but since I've been programming (which is longer than I care to say here, because it really dates me) this is basically where I'm at with static type systems. AS long as I've spent with them I find they're not as useful as they should be. I haven't tried Haskell (I probably should) but I'm getting too much done with dynamic languages, especially Lisps, to look back right now. Too much power to look away. Tschau!
> Go model a square and a rectangle in your favorite statically typed language.
Okay.
data Shape = Square Int | Rectangle Int Int deriving (Show)
> You will find that square extends rectangle and setting the length on a square also sets the width.
Why? I don't really see a need for square to extend a rectangle.
> So if I have a collection of rectangles which contains an unknown number of squares of which I set the width on each of them.
Like this?
> let unknowns = [(5,4),(3,2),(4,4)]
> let toShape (x,y) = if x == y then Square x else Rectangle x y
> map toShape unknowns
[Rectangle 5 4,Rectangle 3 2,Square 4]
Tomorrow I'll see if I can make this type-safe by using dependent typing as shown in: [0][1][2]
This was easily solvable in my staticly typed language as you can see. In something like Idris I could have
very easily encoded the toShape function the the type signature.
Thats cool. Here's the somewhat equivalent in C++:
struct square
{
int x;
};
struct rectangle
{
int x;
int y;
};
boost::variant<square, rectangle> to_shape(int x, int y)
{
if (x == y) return square(x);
else return rectangle(x, y);
}
std::vector<std::pair<int, int>> unknowns = {
{5, 4},
{3, 2},
{4, 4}
};
auto shapes = unknowns | boost::adaptors::transformed(boost::fusion::make_fused(to_shape));
Of course, the structs are not polymoprhic and can't be printed out. I just left that out because it requires a little more code to do that. Obviously with haskell its much less code.
I would very much be interested in the dependently typed version.
I've been debating whether or not to choose C++ or D to learn as my "when performance really matters" language. I'm still going to learn Rust, but I'm very interested in D. I also like that it has a pure keyword ;)
> I don't really see a need for square to extend a rectangle.
Except that a square is-a rectangle! Especially in terms of geometry. So you should be able to use this isomorphism in a type system as a perfect isomorphic mapping this is the entire purpose of the Liskov Substitution Principle. But the polymorphic result doesn't work polymorphically in a way that helps people reason about how the system works. It does things that are "correct" from a LSP and static typing system POV, but isn't helpful.
Mathematically, a rectangle and a square are entities that do not have mutable state; any particular square in mathematics has a fixed width and height.
If you define something that has a setWidth method, then it is not isomorphic to anything in mathematics! "is-a" is defined in terms of the operations that are valid.
What semantics would you specify for the setWidth of a rectangle?
The only reasonable contract for a general Rectangle is that setWidth sets the width but does not affect the height. Your proposed implementation of setWidth on a Square would violate that contract, and any other implementation would violate the invariant of the Square, and so it's clear that mutable Square "is-a" mutable Rectangle is simply not true.
Basically the problem you are looking at is a variant of the reference typing problem, where you have, given S <: T, for writing Ref S <: Ref T and for reading Ref T <: Ref S, and in the general case of the read-write reference there is no subtype relationship between Ref S and Ref T.
> Except that a square is-a rectangle! Especially in terms of geometry.
The thing in geometry that is called a "square" which is a special case of the thing in geometry which is called a "rectangle" is an immutable object whose side lengths and other features are part of its defining identity.
Modeling this relationship works perfectly fine in an OO language -- but squares and rectangles of this type are immutable objects.
A mutable square with operations which mutate the side lengths while preserving squareness is not a special case of a mutable rectangle with operations which mutate side lengths while preserving rectangleness without also preserving aspect ratio.
The analytical problem here is mistakenly assuming an is-a relationship that applies to immutable entities in geometry applies to mutable objects whose mutation operations are defined in such a way that the is-a relationship does not logically hold.
> So you should be able to use this isomorphism in a type system as a perfect isomorphic mapping this is the entire purpose of the Liskov Substitution Principle.
Actually, the entire purpose of the Liskov Substitution Principle is to provide an analytical basis for excluding mistakes like subclassing a mutable "Rectangle" class for a mutable "Square" class with operations that aren't consistent with an is-a relationship simply because of an intuition about an is-a relationship between squares and rectangles in geometry which doesn't actually hold when you analyze the operations on the particular entities you are modelling (which are outside of the geometric definitions of squares and rectangle.) The LSP defines what can and cannot be a subclass, and it rules out the kind of mutable square to mutable rectangle relationship you have proposed in this thread.
If LSP defines this why do people keep modeling things this way? More importantly, why do all the type systems let me create models this way. They have one job: to help me with correctness. Looks like that failed. So you see my point.
I'll admit I'm a little rusty on my geometry, but I'm fairly sure I was never told that a square is a rectangle. If you mean insofar as operations on rectangles should work on squares, this could be accomplished with typeclasses.
Ah ha! Now you see the problem. Whether or not a square is a rectangle in a Euclidian sense it is a normal thing to use a type system in this way. And yet a discussion of it has emerged to whit this exchange. Gives one pause about the value of type systems for correctness eh?
> Whether or not a square is a rectangle in a Euclidian sense
It is. A square is a rectangle whose length and width are equal.
> it is a normal thing to use a type system in this way.
It is a common mistake to misuse an OO type system this way -- to take an intuition about is-a relations of immutable objects and infer an is-a relationship about mutable cousins of those objects, which is almost always wrong without careful constraints on the mutations. It is this kind of mistake which is addressed by the Liskov Substitution Principle. Of course, that's the reason the LSP is usually taught fairly early on in any OO programming course, because the mistake is well-known.
> Gives one pause about the value of type systems for correctness eh?
No, type systems are great for enforcing correctness, but they are no better than the analysis behind the definition of the types.
Of course, violating the LSP with a bad subtyping relationship is just as problematic without a static type system.
> It is a common mistake to misuse an OO type system this way.
So common, I would argue, that it suggests there is a fundamental problem or question of utility with using type systems for correctness. You're right that this has nothing to do with a _static_ type system specifically but they're almost always used together that when you say "static" you are almost always heard as "statically typed", so the point is moot in my experience.
> Whether or not a square is a rectangle in a Euclidian sense it is a normal thing to use a type system in this way.
Why do I care about whether or not it's normal way (for some people/languages) to use a type system in this way? I care about reality and having my types reflect it precisely.
> Gives one pause about the value of type systems for correctness eh?
I actually don't see how. It seems like you are saying "regardless of whether a square is a rectangle in reality, people (mis)use type systems to say this".
Someone’s misuse of a tool doesn't call the tools value into question.
Basically, I may not be able to model your exact relationships in the exact same way but I can model real world concrete things in the type-system which obtains the same or more flexibility and maintainability.
Exactly my point. This continuing misuse is VERY common even among experienced developers. The ongoing argument itself is a counterargument for type systems as being useful for correctness. At least it should give you some pause?
"with a very simple and well-defined domain subset of geometry."
I don't think you're actually working with a well-defined subset of geometry. What is breaking here is the notion of persistent identity over time - "take this square and change its width - leaving us with not a new square/rectangle but the same square changed" - which I don't recall encountering in geometry.
> Go model a square and a rectangle in your favorite statically typed language. You will find that square extends rectangle and setting the length on a square also sets the width.
The coordinates of the vertices are part of the identity of a square and in any reasonable model of a square cannot be changed.
An object with mutable size that is constrained to always be a square probably cannot be a member of a class which extends a class representing objects with mutable length and width that is constrained to remain a rectangle (but necessarily a square), since the properties of the former under mutation are not a simple extension of the properties of the latter, so that the two do not really have an is-a relationship (unless the transformations applicable to the two are designed in an unusual way -- as might be the case where the transformations on the rectangle were constrained to preserve the aspect ratio in all cases.)
People often on initial analysis how mutability really destroys is-a relationships which are based on relations between immutable entities.
Mutability or not doesn't change the fundamental assertion that the result is not intuitive even to the author of the class hierarchy. My whole point is not whether the modeling of the problem in a typical type system is correct or not. The point is that a typical type system allows for a wide range of "incorrectness" that still compiles and runs and does exactly what it was designed to do but still leaves the programmer with an inscrutable result.
Therefore, it can be seen, that there might be other, better ways to assert your system is correct than using types.
Well if you have a Square type that's a subtype of Rectangle then you can't have methods on Rectangle that, when called on a Square instance, would invalidate the invariant of a Square. If your system is sufficiently dynamic (prototype-based?) you can exchange the class of an instance at runtime. If not, simply make your Rectangles immutable, so a setWith method returns a new instance and you can then return a new Rectangle or a new Square from a Rectangle's setWidth. That should work in any statically typed language with inclusion polymorphism.
> You will find that square extends rectangle and setting the length on a square also sets the width.
"setting the length"?? Do you mean "making a copy with the length set to a different value"?
If you have a square, which is-a rectangle, you can of course use the rectangle's copy function, or a rectangle lens or some such, to make a copy with a different length. Which will be a rectangle. Utterly trivial.
I've had just the opposite experience. I used to write a lot of tests, but now I can usually encode my constraints in the type system, where I get a lot for free thanks to the structure - often I just need to compose a couple of existing things specialized to the right types. All the useful ways I've found to enforce correctness boil down to types in one guise or another.
When I was writing tests I felt busier because I spent more time typing; now I spend more time thinking and less time writing code, but I'm ultimately more productive.
I'd also argue that the divide between dynamic, and static typing systems has fallen down. Almost completely.
Java/C# and even Haskell have dynamic typing. They even sort of have a scripting feel.
However, you can also statically type dynamic languages, and dynamic languages are getting static typing too. For example, JavaScript with asm.js. Lots of type inference is done by IDEs and lint systems now. Even with python, static type checking is very possible (both at the C level, and at the python level).
I don't know about the other languages, but while C# may have dynamic typing, it's extremely uncommon to see it in use. It's introduction was to make certain types of interop easier. It was not intended to be a general-purpose programming feature.
> If you're test-driven, you're basically building up your own, domain specific compiler as you go not having to play by a language-specific static type systems rules.
> I could care less about the type system of merely a language (as applied to my system).
These two sentences are contradictory. You are merely making up your own language-specific static type system rules instead of learning how to use the one already provided by static type systems.
I will agree that languages with less flexible type systems to get in the way, but languages like Haskell, Ocaml, and other ML do a lot of the work for you.
> If you're test-driven, you're basically building up your own, domain specific compiler as you go not having to play by a language-specific static type systems rules. Dynamic typing make writing code this way really easy. Static typing doesn't.
Dynamic typing makes this easier for you to start writing code, not necessarily to get your end result faster. Dynamic typing allows you to build your own "type system of merely a language (as applied to your system)", and you can apply your lines of thought to it.
Static typing will require that you think about the types/type system of the language you are using and will inevitably slow you down at first. However it's not much different than the trade-off of using an existing library for a programming task or writing your own.
The marked difference is that I don't trust myself or many others to recreate a comprehensive type system rivalling that of mature compilers and people most likely much smarter than us.
The end result is that you have an ad-hoc type or effect system that isn't well defined, and the quality/correctness is assured through brute force by way of writing all the unit tests you can think of.
I assure you that you can't brute force test more edge conditions than your computer.
This post is getting long, but I feel like it really hits on why many "real world programmers" use Haskell and stronger static type systems: We don't trust ourselves, have been slapped in the face by our limitations and mistakes, so we would like to offload a ton of complexity to the compiler.
"I do believe that there is real value in pursuing functional programming, but it would be irresponsible to exhort everyone to abandon their C++ compilers and start coding in Lisp, Haskell, or, to be blunt, any other fringe language.
To the eternal chagrin of language designers, there are plenty of externalities that can overwhelm the benefits of a language, and game development has more than most fields.
We have cross-platform issues, proprietary tool chains, certification gates, licensed technologies, and stringent performance requirements on top of the issues with legacy codebases and workforce availability that everyone faces." [0]
Which may be why we haven't heard a peep from Carmack on the subject since. Could see pure FP languages entering performance critical domains like game development in the not too distant future, but for now the state of the art isn't quite there.
I'm doing HPC work for a few years now and I'm familiar with FP concepts, use it (albeit never purely so far) in non performance critical code where maintainability and testability is more important. My question: How could it even work in performance critical domains? Most of the time memory bandwidth is the limiting factor, thus copying memory and cleaning up unused memory are very expensive. With pure FP, all I can do is hope the compiler won't create all the copies I'm instructing it to do and optimize it back to procedural in-place update. When that doesn't work all I can do is reimplement it procedurally. How does anyone think that this programming concept can be applied for high performance domains? What am I missing?
Well if you are in HPC you are probably familiar withhttp://en.wikipedia.org/wiki/SISAL, what primarily necessitates garbage collection in modern functional programming languages is the insistence on functions as first class values (essentially they want to live in a cartesian closed category). If you look at something like Intel Thread Building Blocks or even CUDA, you will recognise that at its heart it really is a functional programming model. I mean sure in the case of CUDA you can try to write the same variable multiple times, but in reality to preserve parallelism you would not implement for example matrix multiplication by overwriting one of the matrices in the process. Moreover a more functional / mathematical view on most HPC actually yields additional insight on how to parallelise a problem.
One of the pitfalls when analyzing HPC requirements is to start with a model that's too simplistic - and matrix multiplication is typical for that. What you usually want to run is a solver or simulation. These have timesteps and numerical approximation algorithms (e.g. Runge-Kutta) where you want to make sure that intermediate values live only exactly as long as they need. The reason being that when you distribute your main memory to your threads, especially for GPGPU, you only have a few hundred kilobytes per thread if you want to achieve saturation. So what do you do? In C you typically see the inner timestep functions being called with output and input pointers, then these are swapped for the next step - no allocation, no copying, no overhead, very simple code and nothing that any compiler could screw up. That's just one example of a trick that makes a HPC programmer's life easy, not just because it performs optimally 100% of the times it's used, but because it doesn't complicate performance analysis. In order to be able to analyse code performance properly, one must be able to understand to device code that comes out of the compiler, and how it will interact with the pipeline, the cache etc. If there's too much of a mismatch, it becomes near impossible to understand what's going on. In theory compilers could always achieve the optimum for you and a programmer wouldn't have to care about hardware at all, and just live in his logical bubble. Experience shows that this ideal is pretty far off in the future.
TBB and CUDA seem like odd choices to me for an example case. They are based much more heavily around vectorized / SIMD style for regular more general purpose operations. The in-place vs not thing making those functional is a stretch. Very much bulk parallel procedural.
You know how GCC compiles mutable C code? It converts it into immutable SSA form, optimizes it in this form, and it's only at the register allocation stage that things become mutable again - if two different reassignments of your variable end up compiling to the same register, at some level it's only coincidence that they did so. So unless you're doing handwritten assembly, you're already relying on the compiler's ability to optimize away redundant copies.
Why does GCC do it like this? For the same reason FP systems do: because it's easier to reason about immutable values, and easier to optimize things you can reason about. In general the closer we can get to telling the compiler our intent, the better the performance we should ultimately be able to unlock. If we tell the compiler to create a loop variable and increment it, it has to do that (or at least, has to simulate the effects of doing that). If we just tell the compiler to apply this function to every element of this list, it has the option of being smarter about it.
There's an argument that this will be much more important as the world becomes ever more multicore. In a multicore environment immutable values become much easier to work with because they can be safely copied around; with mutable variables your program can end up spending more time on synchronization overhead than actually doing things. I'm not sure how much I believe this, but it could explain the recent rise in popularity of functional languages.
What is omitted there however is a discussion of pointer parameters and call-by-reference; probably these cannot be treated in the same way as local variables since they point to a fixed address passed in by the caller, so at that point SSA can't be functional, unless I'm missing something.
A possible solution would be to devise a language with a type system that tracks allocation, such that a garbage collector is not needed, and that all allocation deterministic, and yet safe. Some work has been done on this already, in the form of region inference systems, although they have to my knowledge only been used to compile functional languages to run without a garbage collector, and not been exposed in the user-visible type system. The MLkit compiler for Standard ML is the most prominent region-user I am aware of.
Obligatory Rust comment: Rust's type system relates allocation to variable lifetime in such a way that garbage collection is not needed, and almost all deallocation is deterministic, and yet safe.
Rust is still in flux, and its documentation is a bit all over the place, but here are some references:
Another possible reason we haven't heard a peep from Carmack on the subject since is that he joined OculusVR and has a bunch of interesting hardware problems to work on.
C++14 can be a nice functional programming language, coupling algorithms, lambdas, automatic memory management and secure data structures like std::vector and std::string instead of bare bones C like data types.
So it can be a nice language when we have control over the codebase.
However, the biggest problem is being able to do so in the industry at large. I am willing to bet that most C++ code in the wild is done in a pre-C++98 style, with developers unaware of what came afterwards.
Specially bad in those companies where getting any software upgraded is a pain of bureaucracy.
I dug into it a bit, and based on what I found on Twitter, the site crashed hard and the owner hasn't gotten to recovering the data yet. (He mentioned possibly having to pull it from Archive.org.)
I recently tried to make a lambda function in C++ call itself.
My first approach didn't work, because the variables were captured by reference, causing my program to crash (the enclosing scope had disappeared when my recursive lambda function was called). I easily tracked down that problem. But this generated a second problem: without using "capturing by reference", I couldn't make the lambda function refer to itself!
Of course, I looked around on the internet, and I found [1], which actually shows the insane amount of hacking required to make a lambda function call itself. And in the end, this solution didn't even work for me.
So, concluding, I think we're a long way from "functional programming in C++".
Having a lambda call itself seems like self-serving functional wankery to me. Lambdas in C++ are nothing but unnamed classes with an () operator. They're blobs of captured values (or references), made immutable by default, that happen to have a function associated with them. If you want to recurse, give the damn thing a name, or rewrite the body in an iterative form.
They do have a name, but unfortunately it's just a compiler-generated one that's not known beforehand. And you would think that because the body of the lambda is really inside an operator(), 'this' could naturally be used to refer to the lambda itself, but alas, it doesn't work:
This is one thing about lambdas that I think the standards folks messed up. Having a lambda call itself might not be such a compelling use case, but it comes from the more general fact that a lambda cannot refer to itself, even though there isn't any reason preventing it from doing so; e.g. being able to pass itself ('this') as a parameter to some other function can be very useful.
Why does a rather trivial construct like this require an arcane label like 'fixed-point combinator'?
In any case, this is cheating. What you effectively have here is a pair of mutually recursive functions, Recursive<>::op() calls anonymous_lambda_type::op(), which calls Recursive<>::op() again, and so on. I checked Wikipedia without even knowing 'mutual recursion' was an official mathy thing, it just sounded right, and I'm pretty sure this label is sufficient to describe the idea.
If only even more advanced functional concepts were demonstrated without all the unnecessary pomp and ceremony common to Haskell and other functional advocates then I'm sure we'd all benefit. I'm constantly reminded when I see examples like this of Bodil Stokkes presentation 'What Every Hipster Should Know About Functional Programming'
> Why does a rather trivial construct like this require an arcane label like 'fixed-point combinator'?
Because that's what it is. I'm trying to communicate to people who know basic ideas from computer science. This is the last place I would expect someone to call the Y combinator too highbrow.
> This is the last place where I would expect anyone to call the Y combinator too highbrow
It's not highbrow at all, that's what annoys me. I can describe in detail how code like this will translate to machine code, the operations on the stack, the flow control going on etc and think of several ways such constructs could be used to solve real problems. I can, however, read the entire Wikipedia page on 'Fixed-point combinators' and learn nothing beyond the first paragraph which describes their broad classification and properties.
Don't you consider it a had sign that the Wiki page for FPCs eventually reads "The analog for mutual recursion is a polyvariadic fix-point combinator, which may be denoted Y*." ... and when you Google 'polyvariadic' the first page of hits is almost entirely Haskell? ... oh and only ~5,000 results. Basic terminology indeed, clearly not niche gouging wankery.
In any case, neat solution to recursing in to a C++ lambda. I'm just venting generally.
It goes back to the mathematical roots of programming. Turns out that if your language consisted entirely of unnamed lambda functions, it would still be turing-complete because you could use one of several types of combinators to implement everything else. The Y combinator and a few other similar ones implement recursion, which is quite a feat for such a limited language.
Mathematical terminology exists only to add precision to human languages, which are notoriously vague. It can be overdone, of course. Polyvariadic is a bit silly, it just means that the combinator has been generalized so that it works on functions which have more than one argument (literally "many-variable-having"); the original Lambda Calculus pared away even that to leave just functions of one argument.
That hypothetical language, btw, is called the Lambda Calculus. It was formalized and studied by Alonzo Church, and entered software engineering most directly in the form of Lisp. Most of the research these days probably happens in Haskell and similar languages.
Is there any difference between "variadic" and "polyvariadic"? The two seem to both mean "taking a variable number of arguments", but definitions of each never seem to mention the other. "Variadic" is standard C terminology...
I get this with higher-kinded types. The concept seems pretty straightforward to me, but go and read any explanation of it and it seems like someone got a bulk discount on asterisks.
Yeah. It's not actually complicated, but I don't know if you could express it more simply. The "kind" of a type of an actual piece of data is represented with an asterisk. Higher kinded types, then, are thought of as (curried) functions from types to types.
Higher kinded types can be thought of as curried functions from types to types, but that's not how i think of them, and that's exactly the kind of explanation that i find unnecessarily offputting. For some people, thinking about functions on types is natural and useful, but for people not already deep in the functional juju, it's not.
My explanation is something like:
"You know generic types, right? They have a type parameter, and when you bind that type parameter to a particular concrete type, you get a concrete type. So, List<E> is generic, and when you bind it to the concrete type String, you get a concrete type List<String>. Well, a higher-kinded type is a generic type where you can bind the type parameter to a generic type instead of a concrete type. So you might have CollectionMaker<T>, and bind that to List<E>, and end up with a CollectionMaker<List<E>>, where the E isn't bound. Then, particular methods on the class can go on and bind that parameter to particular types."
That explanation is probably isomorphic to the one about functions on types. But it's given in terms of constructs a programmer might actually use.
I'm in favor of getting a variety of approaches to explanation out there. My post was attempting to provide context you'd seemed to be missing, not attempting an entirely separate explanation. I'm sorry you found it offputting. Using C++ template style syntax for paramaterized types does seem a reasonable alternative, though they're not exactly known for their clarity. I do think you're going to lose a whole lot of programmers with CollectionMaker (smelling a bit of industrial-Java style overengineering) - a better example should be found.
"But it's given in terms of constructs a programmer might actually use."
A lot of programmers I know actually use StateT - myself included.
It has a label like that because the math folks who came up with it a hundred or so years ago were thinking of math, not trying to accommodate math-phobic C hackers in the next century.
How the hell is "pair of mutually recursive functions" any less "arcane" than "fixed-point combinator"? "fixed-point combinator" is an obvious name that describes exactly what it does: it's a combinator that returns a fixed point. Can't get plainer than that.
To someone who knows what a function is, and what mutual recursion is, but does not know what a fixed-point is or what a combinator is, certainly the former is more understandable and the latter sounds more like jargon. That's a pretty specific position in knowledge-space to be targeting, but it seems likely the one the parent occupies.
A more important point is that "fixed-point combinator" tells you what the function does - it takes a function (a combinator is a function that operates on a function) and returns its fixed point; a "pair of mutually recursive functions" could do anything, and so conveys less information.
>"which actually shows the insane amount of hacking required to make a lambda function call itself"
I doesn't require any hack at all, it doesn't even require to capture the variable. You just need to be sure to make it persist and be accessible in the scope of the lambda.
When you wrap a lambda into a std::function variable, it involves a call to a virtual function which add overheads (often unnoticed unless you repeat the call several times), so a regular recursive functor would be even faster.
The subject was discussed in the following threads:
The Y combinator causes problems with typing (it has an infinite recursive type), so I'm curious what solution they came up with.
In any case, if calling a lambda function from within itself is going to take more than a single line of straightforward code, then I'm afraid the solution still doesn't cut it for practical purposes.
They could've done something similar to what you do when you implement a functional language in C and used a union to represent every possible return type, and included functions (closures if you will) in that union, then you solve the problem of the infinite type.
It would be interesting to hear what John Carmack has to say about functional reactive programming, as that is meant to have it strengths especially in game programming.
It probably hasn't been proven enough for him to deem worth of his time. I don't say that condescendingly, but he seems to have a pretty pragmatic approach to trying out new stuff. Unsurprising, given how busy he inevitably is.
"So what I set out to do was take the original Wolfenstein 3D, and re-implement it in Haskell."
[...]
"I've got a few conclusions coming from it. One of them is that, there's still the question about static vs dynamic. I know that there was a survey just coming out recently where the majority of programmers are still really not behind static typing. I know that there's the two orthogonal axes about whether types are strong or weak, and whether it's static or dynamic. I come down really pretty firmly, all my experience continues to push me towards this way, that strong, static typing has really significant benefits. Sometimes it's not comfortable, sometimes you have to build up a tight scaffolding to do something that should be really easy, but there are real, strong wins to it."
https://www.youtube.com/watch?v=Uooh0Y9fC_M#t=4876
(Starts at approximately 1:21:16 in case the direct link doesn't work correctly.)