Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Translating Haskell to C++ metaprogramming

vandenoever.info

Post reply on HN
Print view View original

31–40 of 63 posts

Re: Translating Haskell to C++ metaprogramming

#31

Post by jlarocco »

banachtarski wrote: post #9
jlarocco wrote: post #2

I don't know why people don't just use Haskell. C++'s template system has become the ugliest part of the language, both the syntax and the perverse ways people twist the language with it. I understand most of the metaprogramming tricks are in the same vein as "Look what I made in Brainfuck!", and are more about showing off than for serious consideration, but for getting real work done it's a huge headache to work wit…

I'll explain it to you, as a person who was a Haskell enthusiast and uses C++ professionally. The problem with Haskell is that while it is very effective at expressing ideas and logic , it is just as ineffective at expressing runtime behavior . In world where everything is lazily evaluated by default and garbage collected, it is very difficult to reason about how the code will actually execute. Are you trashing the c…

That reply came off a little condescending.

I'm not some kind of Haskell zealot, and I haven't even used it in several years. That said, I'm well aware of the downsides of Haskell, and I've pointed out on numerous occasions that "real life" Haskell doesn't match up with the pure, lazy Haskell people often talk about.

However, the reality is that people who really care about performance and predictability in C++ aren't doing crazy template metaprogramming because, although not as bad as Haskell, it's also difficult to reason about and understand what's going on under the hood.

My guess is that every time somebody has said, "I translated this Haskell code to C++ metaprogramming," they could have just used Haskell with no negative repercussions.

Re: Translating Haskell to C++ metaprogramming

#32

Post by phamilton »

SamReidHughes wrote: post #23
codygman wrote: post #12

Earlier quoted context omitted.

> Haskell's perceived as an impractical language because it is one †. Theoretically maybe ;) The real world disagrees with you however: https://www.fpcomplete.com/business/haskell-industry/ https://wiki.haskell.org/Haskell_in_industry > At the line-by-line level, purely functional code also takes more effort to edit, once written, than imperative code. How? You can locally reason about purely functional code which ma…

The spooky danger comes from lazy evaluation. The "line-by-line" level has nothing to do with global mutable state. It has to do with locally mutable state. It's a lot simpler to change code that is written in terms of for loops and accumulator variables, than it is to change code written in terms of maps, folds, intercalates, whatever. In any reasonably architected software, you can see how a function depends on glo…

I disagree on the for loops claim. A well written for loop is generally a decomposed pipeline of an optional filter/takeWhile plus a map plus an optional reduce. Easy-to-edit for loops separate those concerns. Easy-to-edit functional programs separate those concerns. It's all the same.

As far as "you can see how a function depends on global state by looking at its argument list" you are actually referencing systems that avoid global state. Dependency Injection is the process of taking global state and making it local state.

Re: Translating Haskell to C++ metaprogramming

#33

Post by kenko »

igravious wrote: post #24
gaze wrote: post #22

Earlier quoted context omitted.

You should get over it. It's just syntax... and it's there for a reason (Makes more sense for curried functions, and it's a holdover from logic where you say that if you have a nameclass, you have an object that sense a qname to a bool, and if you have a nameclass and a qname then you have a bool.)

What? Are you saying that I can legitimately read contains :: NameClass -> QName -> Bool two ways? Like, contains :: (NameClass, QName) -> Bool And contains :: NameClass -> (QName, Bool) ? What about four types? contains :: Urk -> NameClass -> QName -> Bool

No, a -> b -> c always means a -> (b -> c).

a -> b -> c -> d always means a -> (b -> (c -> d)).

"->" is right-associative.

Re: Translating Haskell to C++ metaprogramming

#34

Post by codygman »

SamReidHughes wrote: post #23
codygman wrote: post #12

Earlier quoted context omitted.

> Haskell's perceived as an impractical language because it is one †. Theoretically maybe ;) The real world disagrees with you however: https://www.fpcomplete.com/business/haskell-industry/ https://wiki.haskell.org/Haskell_in_industry > At the line-by-line level, purely functional code also takes more effort to edit, once written, than imperative code. How? You can locally reason about purely functional code which ma…

The spooky danger comes from lazy evaluation. The "line-by-line" level has nothing to do with global mutable state. It has to do with locally mutable state. It's a lot simpler to change code that is written in terms of for loops and accumulator variables, than it is to change code written in terms of maps, folds, intercalates, whatever. In any reasonably architected software, you can see how a function depends on glo…

> It's a lot simpler to change code that is written in terms of for loops and accumulator variables, than it is to change code written in terms of maps, folds, intercalates, whatever.

for loops are less structured than maps or folds meaning that divining the meaning of one is more difficult. I think that for loops seem easier because many developers have a lot of previous experience with imperative constructs.

> In any reasonably architected software, you can see how a function depends on global state by looking at its argument list.

Most code isn't reasonably architected.

> If you're in a position to choose Haskell, then you're also in a position to make your software this way.

But then you lose out on all of the other advantages of Haskell. I'd love to hear your responses to the reasons why the Haxl team at facebook chose Haskell. Here's a link:

https://news.ycombinator.com/item?id=7874537

Re: Translating Haskell to C++ metaprogramming

#35

Post by saurik »

theseoafs wrote: post #30
Nullabillity wrote: post #26

Earlier quoted context omitted.

Not quite. It's equivalent to either contains :: (NameClass, QName) -> Bool or contains :: NameClass -> (QName -> Bool) In other words, you can treat it as a function taking two arguments, or one function taking one argument and returning another function.

It is equivalent to the second, not the first. The first is a completely distinct type -- though you can certainly write a function with that type, given the original function, by uncurrying it.

FWIW, I think the person you are responding to is using the non-Haskell requested mental syntax used by the person who asked the original question, in order so they better understand the semantics (even if at a cost of confusing them for later development in Haskell).

Re: Translating Haskell to C++ metaprogramming

#36

Post by harry8 »

Why is there no usable haskell SSL library? It would seem this is an area where the claims about haskell eliminating whole classes of bugs and so on would really be worthwhile and an amazing advert for haskell advocates.

The claims about being able to formally prove the code implements the spec would be pretty damn compelling in that space too.

Once upon a time I asked on HN if there are any useful and usable haskell programs you can just install and run for a purpose that isn't writing haskell code. Shellcheck & pandoc seemed to be the suggested examples. Is that still the case or are there now a few more?

Re: Translating Haskell to C++ metaprogramming

#37

Post by rtpg »

harry8 wrote: post #36

Why is there no usable haskell SSL library? It would seem this is an area where the claims about haskell eliminating whole classes of bugs and so on would really be worthwhile and an amazing advert for haskell advocates. The claims about being able to formally prove the code implements the spec would be pretty damn compelling in that space too. Once upon a time I asked on HN if there are any useful and usable haskell…

There's xmonad, the tiling window manager. Apart from that I can't think of anything that is actively worked on and has any major traction.

Re: Translating Haskell to C++ metaprogramming

#38

Post by efnx »

codygman wrote: post #12
SamReidHughes wrote: post #10

Earlier quoted context omitted.

Haskell's perceived as an impractical language because it is one †. There aren't many projects where you'd get any plausible benefit from using Haskell instead of some other reasonable garbage collected language. Lazy evaluation is a big risk, if you aren't writing programs that start and finish. It sure is one that I've suffered from. At the line-by-line level, purely functional code also takes more effort to edit,…

> Haskell's perceived as an impractical language because it is one †. Theoretically maybe ;) The real world disagrees with you however: https://www.fpcomplete.com/business/haskell-industry/ https://wiki.haskell.org/Haskell_in_industry > At the line-by-line level, purely functional code also takes more effort to edit, once written, than imperative code. How? You can locally reason about purely functional code which ma…

Dude - stop trying to explain to HN how great Haskell is. The longer it takes people to catch on the more of a head start we get. In the mean time we can continue to be extremely productive writing programs we can maintain easily and refactor confidently without unit tests, while reaping the benefits of a great community that provides an awesome standard library and thousands of other useful packages (all in a cohesive, standard format).

It may not be as fast as hand optimized C. It can be within a factor of 2. Though it can be cross compiled to many platforms without any changes.

But I digress - it's my secret weapon and I'd like to keep it that way ;)

Re: Translating Haskell to C++ metaprogramming

#39

Post by efnx »

phamilton wrote: post #32
SamReidHughes wrote: post #23

Earlier quoted context omitted.

The spooky danger comes from lazy evaluation. The "line-by-line" level has nothing to do with global mutable state. It has to do with locally mutable state. It's a lot simpler to change code that is written in terms of for loops and accumulator variables, than it is to change code written in terms of maps, folds, intercalates, whatever. In any reasonably architected software, you can see how a function depends on glo…

I disagree on the for loops claim. A well written for loop is generally a decomposed pipeline of an optional filter/takeWhile plus a map plus an optional reduce. Easy-to-edit for loops separate those concerns. Easy-to-edit functional programs separate those concerns. It's all the same. As far as "you can see how a function depends on global state by looking at its argument list" you are actually referencing systems t…

Yeah, for and while loops can be done with a simple fold - accumulating a tuple. But you've got so many other options.

Re: Translating Haskell to C++ metaprogramming

#40

Post by SamReidHughes »

phamilton wrote: post #32
SamReidHughes wrote: post #23

Earlier quoted context omitted.

The spooky danger comes from lazy evaluation. The "line-by-line" level has nothing to do with global mutable state. It has to do with locally mutable state. It's a lot simpler to change code that is written in terms of for loops and accumulator variables, than it is to change code written in terms of maps, folds, intercalates, whatever. In any reasonably architected software, you can see how a function depends on glo…

I disagree on the for loops claim. A well written for loop is generally a decomposed pipeline of an optional filter/takeWhile plus a map plus an optional reduce. Easy-to-edit for loops separate those concerns. Easy-to-edit functional programs separate those concerns. It's all the same. As far as "you can see how a function depends on global state by looking at its argument list" you are actually referencing systems t…

A function that takes a database connection as a parameter does use global state, the state in question being the world outside the process.

If you want some convincing about the for loops claim, well, first I recommend considering how keyboard users often overlook cases where using a mouse would be more efficient, and then I recommend trying some programming contest like the Google Code Jam using Haskell. Then try using C++, or D or something. Once upon a time, I didn't do programming contests, but some people from IRC got me to try the Code Jam. I thought I'd use Haskell, being very familiar with it, and the experience was a most illuminating disaster. On the other hand, C++ worked out pretty well, even though I was a total cargo cult functional programming weenie at the time and had a real bad attitude about C++, while having only used it for a couple of college classes. You'll find yourself much more aware of how much time you spend stumbling over functional code after that.

Post reply on HN