23 ms·

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 t

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.

saurik 13y ago
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. :(
danabramov 13y ago
You mean like they screwed C#? Or Harmony?
- mpweiher 13y ago
  yep
jamesaguilar 13y ago
Can you explain what about this article makes you think Haskell people are screwing up C++?
kpmah 13y ago
They're actually trying to fix C++. :)
- _random_ 13y ago
  It's easier to start from scratch.
  - letzjuc 13y ago
    Do that and tell us how many people use your language. We'll be waiting.
    - bjz_ 13y ago
      Here's hoping Rust will give them a run for their money.
- Iftheshoefits 13y ago
  One doesn't fix perfection.
freyrs3 13y ago
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.
- deleted 13y ago
  [deleted]
wereHamster 13y ago
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.
- AnimalMuppet 13y ago
  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.
  - freyrs3 13y ago
    Yeah, moving away from the abstract algebra names definitely improves clarity because ``template <typename HasABinaryAssociativeOperationAndIdentity>`` is a much better choice than Monoid.
    - Pacabel 13y ago
      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.
      - chongli 13y ago
        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.
chongli 13y ago
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++.
AnimalMuppet 13y ago
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.
Dewie 13y ago
Why are people trying to ruin the beauty of functional programming by grafting it on like a ninth leg to C++?
sanderjd 13y ago
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.
- angersock 13y ago
  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.
  - chas 13y ago
    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.
yngccc 13y ago
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.
Iftheshoefits 13y ago
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.
coldtea 13y ago
>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.
- BartoszMilewski 13y ago
  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.
bitL 13y ago
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.
- eru 13y ago
  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.
  - bitL 13y ago
    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.
- Dewie 13y ago
  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.
comex 13y ago
> 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.

saurik 13y ago

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

danabramov 13y ago

You mean like they screwed C#? Or Harmony?

mpweiher 13y ago
yep

jamesaguilar 13y ago

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

kpmah 13y ago

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

_random_ 13y ago
It's easier to start from scratch.
- letzjuc 13y ago
  Do that and tell us how many people use your language. We'll be waiting.
  - bjz_ 13y ago
    Here's hoping Rust will give them a run for their money.
Iftheshoefits 13y ago
One doesn't fix perfection.

freyrs3 13y ago

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.

deleted 13y ago
[deleted]

wereHamster 13y ago

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.

AnimalMuppet 13y ago
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.
- freyrs3 13y ago
  Yeah, moving away from the abstract algebra names definitely improves clarity because ``template <typename HasABinaryAssociativeOperationAndIdentity>`` is a much better choice than Monoid.
  - Pacabel 13y ago
    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.
    - chongli 13y ago
      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.

chongli 13y ago

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

AnimalMuppet 13y ago

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.

Dewie 13y ago

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

sanderjd 13y ago

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.

angersock 13y ago
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.
- chas 13y ago
  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.

yngccc 13y ago

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.

Iftheshoefits 13y ago

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.

coldtea 13y ago

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

BartoszMilewski 13y ago
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.

bitL 13y ago

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.

eru 13y ago
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.
- bitL 13y ago
  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.
Dewie 13y ago
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.

comex 13y ago

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