Hacker News Reader

Hacker News

Comment by angersock | Hacker News Reader

Full thread

angersock

Why are all the Haskell and functional folks trying to screw up C++?

I'm sure that's not the actual state of things, but goddamned if that isn't what appears to be happening.

EDIT:

Before downvoting, consider the elaboration I've replied below with (and then you can at least downvote that too!).

EDIT2: HN wouldn't let me submit this, so is edit:

The basic issue is not that futures/promises/monads aren't awesome--I'm quite, quite sure that they are the future (harhar) for solving a lot of things. I use them extensively, for example, in Javascript. They're Good Things (tm).

It's not that template metaprogramming is bad, or not useful, or that Boost isn't our lord and savior for greenfield C++ code.

The problem is that this shit still has to interoperate with code written more than two decades ago.

C++ began life as a weird ball of OOP and templates slathered over C. It failed to fix some of the real, true, awful parts of C (pointers, for example), and those are still around.

Pray tell me, why do I want a language which has both atomic exchanges (sorta, kinda, depending on your compiler and environment) and monads and function mapping? Doesn't that strike anyone else as, oh, I don't know...ill-focused?

C++ is simply too large a language to recommend to a beginner, too difficult to actually make guarantees about (when you can at all!), and in general the whole rotten mess should be cut in half.

Into, perhaps, C, and Haskell.

View on HN

Why do you feel that this is "screwing up C++"?! I think you need to motivate that a lot better, especially given that this author provided logical reasons for his issues with the design of std::future. :(

Simon Peyton Jones has always said that the secret goal of Haskell is not to get you to write Haskell but change the way you think about programming. Seems like we've failed to avoid success again.

What exactly are your objections?

Is it the naming convention? Functor, Monad, Applicative, bind, join, fmap etc? Yes, Haskell can be a bit confusing at first. But if you don't like them you can urge the standards committee to use different names.

Or is it the concepts themselves? That would be pretty sad. A Functor is a really basic concept. You probably use it every day, in one form or another. I'm pretty sure of that. Once you understand this basic concept, you can start building the others on top of that knowledge. It's all about building a common language and understanding of these basic concepts.

You know, if C++ used the concepts and just put sane (non-abstract-algebra) names on them, that might be really useful. I might get Haskell a lot better if the C++ committee does this well.

Yeah, moving away from the abstract algebra names definitely improves clarity because ``template <typename HasABinaryAssociativeOperationAndIdentity>`` is a much better choice than Monoid.

Your examples are either at the extreme of literalness, or at the extreme of abstractness.

The most useful name is probably somewhere in the middle. It may not necessarily consist of everyday words, but it probably relates very obviously and clearly to the C++ functionality.

"Monoid" is a very detached term. It doesn't obviously relate to the C++ construct or concept the way that terms like "typedef", "template", "stream" and so on do for other constructs/concepts.

It may not necessarily consist of everyday words, but it probably relates very obviously and clearly to the C++ functionality.

Such as?

"Monoid" is a very detached term. It doesn't obviously relate to the C++ construct or concept the way that terms like "typedef", "template", "stream" and so on do for other constructs/concepts.

Well of course! Monoid is far more general than those other concepts. It's also a far better name, being unambiguous. Those other names are reused all over the place in different contexts and their meanings subtly shift between their uses. Monoid is not so overloaded; once you learn it, you know what it means every time you encounter it.

I'm not going to claim to have a better name at this moment.

However, I would like to think that there's somebody out there who could come up with a name that describes the concept sufficiently, while still using pragmatic C++-style terminology.

All I'm saying is that "monoid" is terminology of a style that's very different from basically all other C++ terminology. To many C++ programmers, even those with a background in mathematics, it's no better than gibberish.

At least the existing C++ keywords and terminology tend to be far more descriptive of what they're referring to, even if there is ambiguity in some cases. This is true even for the more abstract concepts in C++.

"Monoid" is a very detached term.

What does that mean? How is it any more detached than object or method?

Both "object" and "method" are common words with very obvious parallels between the programming language concepts and similar real-world concepts that are familiar to basically everyone. That's what makes them good terminology.

An "object" is something specific that exists (implying it can likely also be created and destroyed), and can be distinguished from other objects. This applies equally well to a combination of a data structure and some related code as it does to a tennis ball, or to a car, or to a book.

A "method" is a systematic way of doing something. That "something" could be the operations described by some source code, or it could be tying a shoe, or even brushing one's teeth.

"Monoid" has no good real-world parallel. It has no related or relevant meaning outside of very, very specific contexts. That's what makes it "detached". It's off on its own, with an isolated and non-obvious meaning.

If you limit yourself to concepts you can express by relating them to the physical-world objects and human actions then you lack the language to express abstract concepts entirely. The words used by mathematicians are chosen to describe these structures have no real-world connotations because the ideas, in their-full generality, have no representation in our every-day experience. There's no way you'll ever be able to describe any reasonably complex structure from abstract algebra by concatenating a bunch of household adjectives, it doesn't capture the full-generality or convey any more information.

You are being too optimistic about object and method. (They look familiar because of long exposure to OOP.)

The Haskell people share your concerns. Simon Peyton Jones famously suggested "our biggest mistake [in designing Haskell was u]sing the scary term 'monad' rather than 'warm fuzzy thing'". (https://research.microsoft.com/en-us/um/people/simonpj/paper...).

So what kind of object is a multiplication, or an addition? Monoid has "no real good real-world parallel" because it is not a real-world concept. -- "It has no related or relevant meaning outside of very, very specific contexts" -- Well, that's the very nature of these abstractions; they apply to many many contexts, when working with data.

'"Monoid" has no good real-world parallel. It has no related or relevant meaning outside of very, very specific contexts. That's what makes it "detached". It's off on its own, with an isolated and non-obvious meaning.'

It's jargon, but it's jargon shared across a few fields, which makes it more worth learning. And while it lacks a "real-world parallel" it has a lot of simple examples. Lists over concatenation, integers over addition, positive integers over max, negative integers over min... It's interesting and informative to observe why integers over max (or min) is not a monoid but is a semigroup.

Also, this objection would seem to apply equally well to functions and variables as monoids.

I wouldn't say so. "Function" is a pretty common term used to refer to somebody doing some specific task. There's an obvious correlation between an employee tasked with a carrying out a specific role or action, and a chunk of source code that does something specific.

And the same holds true for "variable". It's a very common term for things that change their state of being, including stuff that isn't directly related to programming or mathematics. Stuff like the weather, somebody's mood, and so on.

"Monoid" just doesn't have any everyday meaning like those terms do, especially a meaning that so closely resembles the programming concept like in the case of "function" and "variable".

The everyday meanings of these words are misleading when applied to the context of a particular programming language. Variables in one language are not at all related to variables in another. Mathematical variables, for example, do not change at all. Similar differences exist for functions and objects. These highly-overloaded terms are a constant source of confusion for people trying to learn different programming languages.

Monoid, on the other hand, has no such problem. If you look it up, its meaning in mathematics directly translates to its meaning in Haskell.

"These highly-overloaded terms are a constant source of confusion for people trying to learn different programming languages."

Yeah, they mean yet something else in statistical software.

Do you mean names like RAII? I always break my tongue on this one.

The former was chose to make a point, but I contest the fact that Monoid is extremely abstract. It's very concrete, it effectively describes an interface and if implemented according to certain laws it is a Monoid just like a Container or Iterator. The name has existed for nearly a hundred years in mathematics, it relates very obviously to any data structure that is a monoid.

Perhaps the problem is that there's no good real-world equivalent of a "monoid" that basically everybody is familiar with.

Most people are inherently familiar with the concept of a "container", in the sense of something that holds other things, regardless of whether it's a physical container or a data structure.

"Iterator" might not be as clear as "container", but at least most people are familiar with the concept of doing something repeatedly, whether it's some physical action or executing some chunk of source code.

"Monoid" just isn't like that. It may be concrete when constrained to the context of mathematics or programming, but it's quite meaningless outside of those very specific contexts.

"the problem is that there's no good real-world equivalent of a "monoid" that basically everybody is familiar with."

But that isn't really true. Addition and multiplication are both real-world examples of monoids that everyone is familiar with (obviously, these aren't physical things, but I don't see why that's relevant).

Just realised I may have missed your point; anyway, you're right that "monoid" is harder to find an easily-understood counterpart for than "container". There are examples of monoids which everyone is probably familiar with, but we don't usually abstract from those everyday examples; whereas as well as there being everyday examples of containers (boxes, bags), we are familiar with abstracting away from those examples in everyday life to come up with the general concept of container.

Not really I've had Java developers look me in the face and say that the nonsense names (very much like the one above) that Spring uses are somehow more readable than simple operators or abstract names.

Monoid is NOT a detached term it says I have a type with an identity element, and an associative binary operator, and that that (id `op` elem) always is elem. Try to tell me that i complicated in the slightest. I can most definitely not give you a single line description of templates, or most C++ features. Abstraction makes things more general (i.e less specific) meaning it is easier to describe, reason about, and discuss because I can only talk about things that hold universally.

If you doubt me let's show some things that form a Monoid right now, and how easy it is to define.

1) Strings - identity element = "" - associative operator = +

2) Lists - identity element = list<A>() //empty list - associative operator = concat

and we can go on and on finding instances of Monoids simply from a one line description.

I'm not sure that Java programmers are necessarily the best judges of good naming conventions. I've personally witnessed several of them immediately mention "gonads" when first hearing the term "monad".

For most C++ terminology, you don't need to give a single-line description. The keyword or concept name alone generally embodies that information very well. To use your example, at a basic level a C++ "template" is quite similar to a form letter, stencil or other real-world "templates". It's a predefined mold that you inject your specific information/material into to get a final product with minimal effort.

There just isn't a direct relation back to the real world with a term like "monoid". You end up with people who are confused at best, or more likely they're thinking of some other word that sounds similar but is totally unrelated.

> There just isn't a direct relation back to the real world with a term like "monoid".

And that might even be a good thing. The stencil analogy for C++ templates gives you a warm fuzzy feeling, but doesn't actually help you program. Contrast: the one line definition of Monoids is all there is to them. That's all there is to know about Monoids.

Monoid is NOT a detached term it says I have a type with an identity element, and an associative binary operator, and that that (id `op` elem) always is elem. Try to tell me that i complicated in the slightest.

Just for the record, I'd like to state that I couldn't make heads or tails of this explanation. 'Identity element', when thinking of C++, just makes me think of a hash function or something.

Looking at the examples, it's sort of clearer— a monoid is a type that can hold a value that's empty (or zeroed, or whatever). But that doesn't change the fact that that explanation (and the term 'monoid') is so firmly rooted in math jargon that it's basically incomprehensible to someone used to thinking in C++.

> is so firmly rooted in math jargon that it's basically incomprehensible to someone used to thinking in C++.

It's firmly rooted in like 5th grade math. Every child in the US that takes basic algebra in school learns about identities and identity rules like "0+x=x" or "1*x=x" or in pseudocode as something like "(id `op` elem)=elem".

Every child certainly doesn't learn the term "monoid" though. The issue here isn't the concept; it's the terminology.

Possibly, C++ should adopt the name anyway, but it's by no means a commonly used or understood term by most users of C++. As has been mentioned, C++ is above all a language whose design is driven by pragmatism, so if another more common term can be found for the idea of a monoid you can bet it'll be preferred (even at the expense of some literary accuracy).

Monoid is a semigroup with an identity, and also a group without inverses. Learning a small amount of algebra shouldn't be scary, and the vocabulary will help you in countless mathematical fields - many of which touch directly on programming.

> Monoid is a semigroup with an identity, and also a group without inverses.

Classic. Sometimes Haskell fans have useful things to say, and sometimes they're just using terminology to try to win an intellectual dick-size war. The tricky part is telling the two apart.

It's basic abstract algebra - this is literally stuff I learned in a math class 12 years ago. It's used in hojillion papers, some abstract and some concrete and highly relevant to real world problems (including encryption and linear algebra - both of which can be directly useful to programmers), and they're not even hard. Just learn some math - this is undergrad stuff.

The concepts themselves aren't difficult to understand. It's just that some people go out of their way to use uncommon terminology that ends up obscuring what they're trying to say, rather than making it clearer.

Is there more common terminology for "a set with a binary operation that is associative and has an identity"?

Any name that we'd come up either wouldn't capture the general case or would be just as arbitrary as Monoid ( ignoring historical usage). The gist of this argument is that Pacabel and the like can't describe the concept using the traditional OOP evocative naming style but insist that term "Monoid" is wrong because of some irrational aversion to terms from abstract algebra. There's really nowhere for this argument to go...

Imagine trying trying to describe a monoidal category or topoi in the OOP style, it's like trying to describe what a Fourier transform is to someone who insists on using roman numerals.

> it's like trying to describe what a Fourier transform is to someone who insists on using roman numerals.

Or describing Latin declensions to someone who reads kanji. The key is that, if the audience admires Latin speakers, you can appear smart.

You're right, why use precise language to describe abstract concepts when we could just communicate knowledge using longform metaphors and cryptic analogies. Or maybe we could just grunt at each other like animals.

It's good to use precise, specialised language to communicate with other people who are familiar with that specialised language. Using specialised language to "explain" another piece of terminology from the same specialised vocabulary, though, doesn't create the impression of someone who is genuinely interested in communication.

"typedef" is one of the most misleadingly named constructs in the language. You can "define a type" without it, it just changes how things are tokenized. Giving it as an example of good naming is weird.

Don't you mean template <typename HasABinaryAssociativeOperationAndLeftIdentityAndRightIdentity>

What's wrong with the names? I see this complaint everywhere but not a single person has yet managed to explain to me what's wrong with them. Is it because they're from math? Perhaps we should rename them after dog breeds or something.

Nothing is wrong with them. A lot of people aren't used the level of abstraction that Haskell uses, so they look at a specific instance of the structure (often the List type) and think of a name that fits that instance ignoring the more general class. You end up with names like Appendable ( Monoid ) or FlatMappable ( Monad ) both of which give horrible intuition for the general case.

I think the abstract algebra names are great because they describe the general case precisely without any preconceptions carried along with them.

"I think the abstract algebra names are great because they describe the general case precisely without any preconceptions carried along with them."

And there's papers about interesting things you can do with them.

Math has a tradition of one-letter names. I mean who in their right mind would name anything with rich semantics as just a, b, c, or x, y, z, or B, C, D... Oh wait...

We are talking about the names of algebraic structures, not symbols in equations.

It was a joke. Notice the letters B, C, D... do they look familiar?

What's wrong with the names is that they don't communicate very well to the 95%+ of programmers who aren't in the FP/Haskell world. That's most of the people who are going to try to use it on C++.

I mean, some concepts are clearly not able to be explained to the layman; you need some background. But do people really need to learn abstract algebra to be able to get their heads around this stuff? Are there no better terms that communicate to more people?

And, given that that's the problem, clearly dog breeds are not the answer either.

What's wrong with the names is that they don't communicate very well to the 95%+ of programmers who aren't in the FP/Haskell world. That's most of the people who are going to try to use it on C++.

I'm not a C++ programmer; I don't know what half the names are from the GoF book. Does that make them bad names? No! Since when should a word have to carry around its own definition so that people who've never seen it before automatically know what it means?

Concepts like Functor and Monoid and Monad are extremely simple. You don't need to go back to school to learn them. You only run into trouble if you expect them to be explainable by analogy to a more concrete notion.

And, given that that's the problem, clearly dog breeds are not the answer either.

It was a sarcastic remark but it highlights an important point I want to make. Assuming you knew nothing at all about dogs; if you were given a list of dog breeds and a stack of photos of dogs, would you be able to match the breed names to the photos? No, probably not. That doesn't mean their names are bad; you simply lack the experience to figure it out.

I think the point is that if you did get into C++ you'd get a pretty good grasp of the keywords and other common identifiers without even having to look them up. They are mostly all designed to appeal to intuition.

>Concepts like Functor and Monoid and Monad are extremely simple. You don't need to go back to school to learn them.

The issue here is not at all how complicated the concepts are. The issue is how common and/or descriptive the name for them is. "Monoid", to someone who hasn't studied abstract algebra, is neither. Something like "Appendable" might be more appropriate for C++.

Not every monoid has an append operation, most don't.

To be fair, Monoid's operation in Haskell is called 'mappend'.

"Haskell calls it that" isn't the same thing as "its a good descriptive name".

Of course.

> Something like "Appendable" might be more appropriate for C++.

So I can append False to True to get False (Boolean monoid under &&) or append 8 to 9 to get 72 (integer monoid under multiplication)? There's also a monoid instances for any single-argument function into a monoidal type, where (f <> g) x = f x <> g x; I don't know what to call that but it's definitely not appending.

Append is a name that works in a few cases but horribly breaks down in the general case.

> "Monoid", to someone who hasn't studied abstract algebra...

Oh come on, man! I can't believe this ridiculous discussion. I'm not lashing out at you, don't get me wrong, but seriously, you think you need to study abstract algebra to understand what a monoid is? Um, I remember one of the first things mentioned in the, literally, first lecture in undergraduate course on calculus was a monoid, among other algebraic structures. Granted, it was theoretical physics, but still, I doubt any respectable university teaching CS would fail to give students at least some familiarity with basic algebraic structures. But you don't even need a university education to grasp this, seriously, stop being afraid of precise terms, there's nothing scary behind them.

EDIT: And to actually address your point :), "intuitive" can only go so far. Sometimes there is simply no intuitive term that can do justice to the concept at hand. As Feynman once said: "I'm not going to lie to you, I'm not going to tell you it's like a ball bearing on a spring because it isn't." Especially in programming I'm not convinced that intuitiveness of a mere label for something is a valuable goal. You can't program on intuition, at some point you just have to learn how the thing really works.

> you think you need to study abstract algebra to understand what a monoid is?

No no no. My whole point is that while the concept is not complicated, that particular term ("monoid") simply isn't common.

I agree with your edit section though. And I don't necessarily think C++ shouldn't adopt the term 'monoid' due to its relative obscurity (especially if no better term can be found); I just think it's got some figurative points against it for that reason.

"Why is it that 'positive integers and minimum' is appendable, but 'integers and minimum' isn't?"

It seems a massive violation of basic DRY to come up with new names instead of using those that have been a staple in math for the last 50 years. It's also just about 5 words in total, if you count the most important and widely used Haskell/FP typeclasses. I really hope people in general are able to memorize five words.

>It seems a massive violation of basic DRY to come up with new names instead of using those that have been a staple in math for the last 50 years.

DRY is not abour reusing names from other fields. Perhaps you were going for the "principle of least surprise".

But given that most people are not familiar with those Math names in the first places (including mathematicians not versed in type theory, trust me, I've asked a few Math colleagues from university and it's chinese to them too), I doubt even that applies here.

So, no, some arbitrary names like Monoid and co, obscure even for people with a passable Math knowledge, picked back in the day, is not the best naming scheme for that behavior that people can come up with.

The best that it has going for it is that is has been used in Math "for the last 50 years" (still, hardly a "staple").

A lot of math naming and notation is arbitrary and a historical accident. That was one of the things the "axiomatic language" guys tried to solve back in the '20s after all.

If you don't know what a Monoid is you are probably a pretty poor mathematician as it is core structure to do even undergraduate abstract algebra.

Many computer scientists already understand reasoning about abstract structures and use them in their work.

For example commutative operators are incredibly powerful tool in distributed systems, as I am able to disregard ordering. In general it is useful to be able to say that if I meet an abstract specification (i.e a Monoid, Group, Ring, ect) because it allows me to perform operations with confidence that they are correct.

If you doubt the usefulness of this just look to Twitter (can't get much more "real world" than that) and see how they have been leveraging abstract reasoning in projects like Summing Bird (and its sub-projects like Algebird, Bijection, ect).

I think what you meant to say was "you are probably not very well versed in a specific branch of mathematics." Because otherwise you're coming off as needlessly--and baselessly--arrogant asshole who also has mistakenly generalized his specific area of expertise far beyond what it actually is.

>If you don't know what a Monoid is you are probably a pretty poor mathematician as it is core structure to do even undergraduate abstract algebra.

Well, I asked undergraduate math students on their final year, and they didn't know. Perhaps all PhDs in math do, but that's not much of an argument in reusing those terms in CS.

Myself had several classes of algebra in different years in university (for the CS degree) and we didn't ever talk about Monoids and such.

> Well, I asked undergraduate math students on their final year, and they didn't know.

I have no reason to not believe you, but how is this possible, and what does it say about either those students or that university or even both? Do they also not know what a group is? A ring, a field? How can a mathematician (and a nearly graduated student in maths is certainly a mathematician) not know what basic algebraic structures are? I'm shocked, frankly. It's literally equivalent to saying they don't know what real numbers are, without exaggerating one bit.

>* I have no reason to not believe you, but how is this possible, and what does it say about either those students or that university or even both? Do they also not know what a group is?*

They should know what a group is, because even us, CS students, were taught group theory for a whole semester.

As for the monoid thing, I guess they could have been taught at some point, along with being taught 20 other branches and fields of mathematics in different classes, and they were more likely to remember a) the basic stuff, b) the stuff they started to specialize on and concentrated upon writing their thesis. So, I guess if I had talked to someone who had taken a preference to type theory and such, they would have known.

>How can a mathematician (and a nearly graduated student in maths is certainly a mathematician) not know what basic algebraic structures are? I'm shocked, frankly. It's literally equivalent to saying they don't know what real numbers are, without exaggerating one bit.

Is it? I don't know. You can read whole books in Algebra and not mean the word "Monoid" once in them, including some university books.

For example (not even one mention): http://www.amazon.com/gp/search?index=books&linkCode=qs&keyw...

This again no mention: http://www.amazon.com/gp/search?index=books&linkCode=qs&keyw...

This (a "graduate level" book) only mentions Monoid once, somewhere on the first pages, and adds that it won't be emphasised: http://books.google.com.sg/books?id=C4TByeUh9A4C&printsec=fr...

And I'm pretty sure in our Algebra books (for CS students, 2 classes in the 1st and 2nd year) there was no much mention of monoids (or, possibly, the professor skipped over those chapters, maybe had some brief explanation and went on to other things).

Of course, what university gradutes of a field do not know can sometimes be even more daunting. For example, a surprising percentage of degree-ed Computer Scientists cannot even solve the fizz-buzz problem:

http://blog.codinghorror.com/why-cant-programmers-program/

Of course, to not remember exactly what a monoid is is completely fine for a mathematician who's field isn't abstract algebra and related stuff, but to be clueless as to what the concept is at all is somewhat disturbing. I would have no problem if they said something like "ah, yeah, it's a little simpler than a group, I can't remember the exact properties ATM".

Hm, I just gave a quick glance to one group theory textbook (the only one I have in English), and to be honest in the first 20 or so pages there is no mention of the word "monoid" (as far as I can see, I really just quickly scanned through the first chapter) but it does mention semigroups (which are just an identity element away from monoids)...

> And I'm pretty sure in our Algebra books (for CS students, 2 classes in the 1st and 2nd year) there was no much mention of monoids (or, possibly, the professor skipped over those chapters, maybe had some brief explanation and went on to other things).

Yeah, and that's fine, but for maths students to not even remember that it was mentioned is kind of sad. It shows they don't really care that much about what they're doing. If it wasn't even mentioned by the professor, shows a disinterest on his/her part to actually teach concepts. It's always much better when teaching a concept to also at least mention related concepts or similar ones at different levels of abstraction, that gives a complete picture in which you can neatly place things. A group doesn't just appear out of nowhere (although it certainly can be defined on it's own), and it's not alone...

> For example, a surprising percentage of degree-ed Computer Scientists cannot even solve the fizz-buzz problem:

Sigh... I know. But you see, that's why I found this discussion about the unintuitiveness of the word "monad", here of all places, absurd. I wouldn't expect people who cannot solve fizz-buzz to have any clue about anything, and on some level I'm fine with that, this is not an elitist rant, but people in a place like this? After all, programming routinely involves dealing with concepts that are much more unintuitive that a monoid, IMHO.

We are not mathematicians. Those terms are not really part of our industry.

Um, which industry do you work in? Enormous amounts of words from mathematics have been incorporated into the programming lexicon. Vector, matrix, index, graph, tree, function, domain, ... the list goes on and on.

The words you listed tend to have well-understood meanings in numerous contexts aside from mathematics that are still related in some way to the software concept.

Some of those words are very likely non-mathematical words that were adopted and re-purposed by mathematicians. "Tree" is inspired by how the data structure's shape is very similar to that of trees (that is, the plants), for example.

You missed the point, they all come from mathematics and their meaning in the context of programming is precisely related to their mathematical context.

Though many of us are computer scientists (at least by education), and engineers. Vocabulary does not just manifest out of thin air. Where do you think the words function, or algorithm came from? I can tell you they were in use before 1950. We have already collectively borrowed a huge amount of vocabulary from mathematics. There is nothing wrong with adopting a few more that accurately describe what these objects are. For example we could call Functor Mappable or some such but it falls short in describing the abstraction. For example functions of one argument form a Functor and its "map" is function composition. So for functions Mappable is a pretty poor name.

Edit: Yes languages get this wrong but I was focusing on the borrowing of vocabulary more so than the correct usage of it. Many words are abused like Functor to mean function object in C++, functions referring to procedures, ad-hoc vs. parametric polymorphism, strong and weak typing ect.

Unfortunately the term 'function' is somewhat misused in most programming languages, where 'procedure' would be a better term. The Wirth languages, Haskell, and Nimrod are the few that seem to get this right.

Ada too, it has distinct procedures and functions; the latter producing only one output based only on its inputs (though I believe recently they added the ability to also have out parameters so multiple values can be returned).

Eh, sorry, but you work with a machine whose purpose is to manipulate mathematical constructs, following a mathematical algorithm, receiving mathematical symbols as input, and outputting that same class of symbols, originally invented by mathematicians, and improved by them through several iterations until they achieved the form they have now.

Oh, and lots and lots of your peers are formed in an specialization of mathematics called "Computer Science".

Of course. But the fact that I'm doing this work on a device built from electronic components does not make me an electrical engineer, and the fact that physicists discovered the principles which make semiconductors possible does not make the work I'm doing a part of physics.

One might as well say that biology is a branch of philosophy, because it was the source of all the natural scientists; but such a description, in modern times, would not be particularly informative.

They are simple concepts, just more abstract than you're used to. They actually turn up all over the place - they're a bit like classes were before object orientation was popular, and everybody was building structs filled with function pointers in C in order to emulate polymorphism. The things these concepts address are things you're doing in your code today, by hand, and don't realize how they can be compressed, mostly because C++ has historically lacked a concise notation for type-inferred lambdas.

They're able to turn a lot of algorithms inside out; make the kernel a simple function of values where they used to be threaded through the code flow, and use things like bind to mix them back in. This makes algorithms testable and more composable, and raise the level of abstraction in the rest of your code so that you're operating more at the DSL level for your domain, whatever it is.

It's worth learning the concepts. Once you do, you'll be surprised that there's so little "there" there.

And their commonality and generality are exactly the reasons why they should have short yet precisely general names.

Most of the comments on here seem to be talking about whether the name is good or not. For me, the question isn't what a 'monoid' is called, or whether it can be defined in a few lines of English, but rather what it is that they are useful for.

I've been using Scala full time for a couple of years now, but it took me ten months to really understand not just what monads are, but how they are useful in expressing a program from a different perspective to other approaches, and the benefits that come from that. Now I use them all the time and see how they add huge benefits to my code.

In all the time that I've been working with Scala, and building my knowledge and experience of how to apply functional principles usefully, I have yet to (knowingly) use a Monoid, or encounter a situation where it was clear that they would have a benefit. I'm not saying that there are no such situations, and it may be that there have been situations where they would have been useful, but I didn't know it, and I would love to be able to add them to my toolbox. However, I do see that a lot of the time these concepts are introduced in a very abstract way and what it missing is not the simple definition, but rather some clear idea of when, how and why to use them.

Answered in sibling post above!

Some, not all! I'm a Haskell folk and I've no interest in changing C++. I'd rather just use Haskell and teach others about it! Isn't that novel?

Personally, I don't think you'll ever reach perfection if you restrict yourself to adding features. Sometimes you've got to take them away and that's not really feasible with a mature language like C++.

What do you think about a language like Rust that is trying to bring some of these ideas into a C++-like language from the get-go, without the necessity of interacting with code written more than two decades (or one decade, or one year, or sometimes even one month) ago?

I'm curious because you seem to have made two different points: 1) it doesn't make sense because adding new features to such an old and widely used language is hard, and 2) it doesn't make sense because of the kind of language C++ is. (1) isn't true for Rust, but (2) is.

So, I don't know Rust, so I'm not going to try and voice an opinion that would be unsubstantiated.

As for your observed point 2 though: at some level, systems languages need to allow the twiddling of bits on and off, perhaps allow the direct interaction via assembly with the processor, have some notion of native word size, and perhaps also make simple common idioms in low-level programming (stacks, interrupts, and so forth).

It is very rare (in my experience, which may not be accurate) that these issues should be even visible at semantic layer concerned with mapping functions over data and other functions, with sorting sets, and sending messages. It's simply too polluted a headspace.

In my experience, C++ is really a double-edged sword in this regard.

At its best, it provides tools for building cost-free abstractions that hide bit-twiddling and assembly hacks while providing an expressive set of building blocks for the semantic layers above them. In this case a programmer only thinks about one layer at a time, so the mapping and messaging can be tuned to their domain, but the implementation is abstracted.

At its worst, it provides the verbosity of Enterprise Java with the memory safety of C and it becomes very difficult to trace what the program is doing and how. I have found this is very strongly related to the widespread use of non-smart pointers. This lets the semantic domains smear into each other and tends to produce astonishingly brittle code.

>Why are all the Haskell and functional folks trying to screw up C++?

All 10 of them? You do understand that these C++ proposals and additions have nothing to do with Haskell people, but come from seasoned C++ veterans, like Herb Sutter and such.

Actually, Haskell people do influence C++ rather heavily. The ideas behind many of the functional aspects of C++ can be traced back to Microsoft Research in Cambridge, UK, where Simon Peyton-Jones works and whose collaborators/students went on to design F#, which very strongly influenced C#, with major contributions from Erik Meijer, a Haskeller extraordinaire and the inventor of LINQ and Reactive. Microsoft PPL library, which is the driving force behind most recent concurrency extensions to C++ has been created by functional programmers. The truth is that C++ cannot survive in the multicore world without an injection of functional programming.

Can you explain what about this article makes you think Haskell people are screwing up C++?

Even if you feel that way, remember part of the philosophy of C++: You don't pay for what you don't use.

You don't like this? Fine. It's pretty easy - don't use futures, and it won't be in your face. You can ignore it completely and use the rest of C++ as you see fit.

You don't have to use C++XX features you don't like. One of the more beautiful things about C and C++ that I like is that I can go as "bare bones" as I want and still have an incredibly powerful (not to mention performant) language to program in. You didn't (and still don't) have to use STL (any version). You also don't have to use the lambda function syntax or range operator, move operators or rvalue references, or basically any other thing that is "new" to the C++XX standard(s). In fact, if you eschew these things your code is likely to be more portable and longer lived, although it may require more time to develop, and include more re-implementation of boilerplate.

Also it's amusing you opine that pointers are "awful" in the same post in which you rail against others' for "screw[ing] up C++". Pointers are one of the best things about the two languages in my opinion. I love the power and flexibility they provide.

You mean like they screwed C#? Or Harmony?

yep

> Pray tell me, why do I want a language which has both atomic exchanges (sorta, kinda, depending on your compiler and environment) and monads and function mapping? Doesn't that strike anyone else as, oh, I don't know...ill-focused?

Dunno, but I think part of the reason Rust is popular lately is that it combines safety and functional features with high performance by default and the ability to /theoretically/ easily drop down into lower-level code to eke more out.

I think C++ is an unnecessarily complex language for various reasons, but adding some basic functional methods to a STL class isn't the end of the world on that front and sounds fairly useful.

p.s. Java has atomic exchanges.

They're actually trying to fix C++. :)

It's easier to start from scratch.

Do that and tell us how many people use your language. We'll be waiting.

Here's hoping Rust will give them a run for their money.

One doesn't fix perfection.

The article discusses a proposal to add new functionally to part of the standard library, which just happen to mimic a monadic interface. I fail to see how it even affect the language.

I find it quite funny. Monads were considered a hack to functional programming to add some imperative features like, you know, IO and similar funky stuff for which there was no math theory. Now seeing them grafted to a language that is considered the golden measure of all imperative languages is kinda LOL.

That's somewhat backward. Monads come from Category theory.

A while ago the FP people figured out that their `hacks' to do IO actually conform to the structure of a Monad. So they exploited the fact. Now the author sees that the `hack' to do futures in C++ also conforms to the structure of a Monad, and suggests exploiting that fact.

Sure, monads come from category theory. IO and interactivity doesn't.

Yes, though futures were always like that when you look at Java for example. Java always suffered from the need to prepare complex design patterns to do simplest things as it was much less flexible than C++. Now C++ is getting there as well.

I personally would stick with some earlier C++ standard and use Haskell for my functional programming needs. Feels much more natural than trying to bend each language to support every thought process imaginable, and doing a poor job at that.

Imperative languages seem like state monads. But a monad doesn't need to be a state monad. If you want something different than a state monad, it might not be any more simple to implement that in an imperative language than a declarative one.

Why are people trying to ruin the beauty of functional programming by grafting it on like a ninth leg to C++?

Reply on news.ycombinator.com