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

51–60 of 63 posts

Re: Translating Haskell to C++ metaprogramming

#51

Post by pjmlp »

jlarocco wrote: post #31
banachtarski wrote: post #9

Earlier quoted context omitted.

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'…

Just upvoted you.

Yes, but C++ enjoys profilers like Instruments, Visual Studio Profiler, Intel Amplifier among many others that allow to check how all that meta-programming is affecting the application, while Haskell tooling is much more limited.

Re: Translating Haskell to C++ metaprogramming

#52

Post by pjmlp »

banachtarski wrote: post #28
oever wrote: post #7

Earlier quoted context omitted.

Haskell is a great language. But there are large codebases out there in C++. Porting those is often not feasible. Yet, Haskell can serve as a great inspiration of how to write clean code. C++ does not have the limitations/strictness of Haskell, but that does not mean that a programmer cannot apply the rigor of Haskell to C++ code. Blasien is meant as a way to improve software that works with XML. Big packages like Li…

Agreed. While I would never use Haskell to, say, right a next gen graphics engine, I can confidently say that learning to write idiomatic Haskell code has improved my C++ code.

Specially with C++14, algorithms and functional libraries.

Re: Translating Haskell to C++ metaprogramming

#53

Post by cies »

codygman wrote: post #49
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…

Have you seen this Haskell tls[0]? "This library provides native Haskell TLS and SSL protocol implementation for server and client." 0: http://hackage.haskell.org/package/tls EDIT: This Github issue provides some great discussion about the security of this library and links to some good discussion as well: https://github.com/vincenthz/hs-tls/issues/89

Wanted to point out the same. Haskell (unlike many other languages) has an SSL/TLS implementation. A few days ago I found out that OCaml has one as well :)

Re: Translating Haskell to C++ metaprogramming

#54

Post by banachtarski »

jlarocco wrote: post #31
banachtarski wrote: post #9

Earlier quoted context omitted.

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'…

I think that's probably mostly accurate.

That said, I do use templated code in my inner loops even. After all, the benefit of generics is that you do the work at compile time instead of runtime (no casting, data marshalling is tight, etc).

Even with code that needed to be significantly templatized (as is the case with many core libraries), I have to give C++ a clear edge as far as runtime debuggability and performance is concerned.

Re: Translating Haskell to C++ metaprogramming

#55

Post by Nullabillity »

saurik wrote: post #35
theseoafs wrote: post #30

Earlier quoted context omitted.

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

Yup. They're distinct types, but mentally they are the same (and the standard library has functions to convert between the two forms).

Re: Translating Haskell to C++ metaprogramming

#56

Post by gaze »

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

You should first understand currying. If I have a function f :: A -> B -> C -> D, every time I apply an argument, as in f a where a is of type A (b :: B, c :: C, ...), you get a new function back of type B -> C -> D. Read :: as "has type." Therefore

f :: A -> B -> C -> D

f a :: B -> C -> D

f a b :: C -> D

f a b c :: D

This is why Haskell's function call syntax seems a bit funny, and the typing syntax (->) seems funny. Every time you apply an argument you get a new object back which represents the result of applying the function. Once you've applied everything to the left of the rightmost type, you have the result.

It's a statement of implication. If I have an a and an f, the most I can have is a function which takes arguments of type B, C, and D, and so forth.

Re: Translating Haskell to C++ metaprogramming

#57

Post by SamReidHughes »

codygman wrote: post #45
SamReidHughes wrote: post #40

Earlier quoted context omitted.

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 u…

> 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++ Were you familiar with pure functional data structures and algorithms or at least simulating imp…

As for Haskell, I was... fully functional, programming with... multiple techniques.

Re: Translating Haskell to C++ metaprogramming

#59

Post by SamReidHughes »

codygman wrote: post #45
SamReidHughes wrote: post #40

Earlier quoted context omitted.

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 u…

> 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++ Were you familiar with pure functional data structures and algorithms or at least simulating imp…

Now that I'm done putting 900 miles on my odometer, let me expand on that. The ST monad is not the answer. If you're writing code and suddenly you realize you need to modify state, there's a big difference between adding a variable, and rewriting the whole thing to sit inside the ST monad. And if you put everything inside the ST monad in the first place, you're working with a much more cumbersome imperative language than one where you have to write newSTRef for every variable you create.

Re: Translating Haskell to C++ metaprogramming

#60

Post by SamReidHughes »

mightybyte wrote: post #48
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,…

> Lazy evaluation is a big risk, if you aren't writing programs that start and finish. No it is not. I've been writing Haskell full-time for five and a half years and I can count on one hand the number of times that lazy evaluation has been a significant problem. > At the line-by-line level, purely functional code also takes more effort to edit, once written, than imperative code. This couldn't be further from the tr…

Refactorings in Haskell are relatively safe because you tend to be forced to acknowledge changes in a type or function's behavior at every place it's used. For example, if you add a field to a datatype, every pattern binding will have to recognize that fact. But for every place where that's the case in Haskell, you can accomplish the same thing in other languages. For example, if you add a field to a struct in C, you can rename its other fields, and then fix up every usage in your program. Other tricks include renaming a function you've changed, adding a dummy parameter, and of course, putting something in a wrapper type while you do the refactoring.

Haskell's type system (assuming you mean with GHC extensions because you called it advanced) only gives you an advantage in cases where other languages would have to resort to reflection or dynamic casts, i.e. specifically where they give up type safety and you'd miss a recompilation. In reasonable languages with generics, like C#, this is quite rare. For example, once in a while, in C#, you might wish you had associated types (or functional dependencies).

Post reply on HN