Live data from Hacker News

Haskell's effect on my C++ : exploit the type system

vallettaventures.com

51–57 of 57 posts

Re: Haskell's effect on my C++ : exploit the type system

#51
post #44

Earlier quoted context omitted.

To make it clear, I don't mean to rag on C, which is a great mid-level language. It's the ++ that I hate. Assembly is infantry: can do a lot of fine-grained work, but limited to about 5 mph with equipment. C is a tank-- a pretty powerful and impressive machine. It can shoot on the run and do 50 mph off-road. High-level languages are airplanes, perfect at 500 mph but coarse-grained from an operational standpoint. C++…

> C++ exists because someone saw a tank and a plane and said, "I'm going to put wings on a fucking tank and see what happens." What a great metaphor. Hilarious, great imagery, and it's even mostly true! Thanks for that, I'll remember it.

To that, C++ proponents will reply: when done well, that gives you an awesome flying tank, as in http://en.wikipedia.org/wiki/Fairchild_Republic_A-10_Thunder.... It may not be sexy, but it sure gets the job done.

I think that is apt for C++, too. It is not sexy as in 'objects all the way down', 'functions all the way down', 'consign all the way down', or whatever else rocks one's boat, but it is sturdy and does get the job done.

Re: Haskell's effect on my C++ : exploit the type system

#52

Earlier quoted context omitted.

Thanks for your reply, it was very interesting. One small comment - what makes C++ appropriate for my usage is mainly templates. Lots and lots of templates. It is very useful to be able to easily compile an algorithm for different types. If compiling a whole 10,000+ line algorithm 4 times for char/short/int/long inputs with templates and doing run-time branching between the algorithms (but not in the algorithms) save…

I think C++'s template feature is pretty unusual in languages. Lisps have macros, which are much more fully-featured and more hygienic than C macros, but I don't think any Lisps are fast enough to be interesting to you. I know that the Scala community is working on putting macros in. Have you looked at Ocaml and Scala? Those might be close enough to suit your needs, and I think it's only a matter of time before Scala…

> I think it's only a matter of time before Scala (or something like it) starts outperforming C++ on parallel problems.

It is certainly plausible. But a few things need to change

(i) JVM applications tend to be memory heavy, even if you can approach 75% of the run time speed of a C or a C++ application you would typically need a lot more memory. In my expeience it has been 8 times or more, YMMV.

(ii) The other problem is that all the exciting native SIMD instructions are mostly out of reach. This can be a drag especially when your code uses log and exponentiation a lot. Without SIMD they are terribly expensive.

(iii) The kind of things that I use C++ for is heavy in array operations, in particular manipulating sparse arrays. In these applications the loop bounds are not constant and it is impossible to ensure at compile time that the array indexing will not go out of bounds. There Java's runtime bounds checking does slow it down. A way to override the safety would help.

(iv) The other good thing about C++ is the ability to delay evaluation via the use of templates, I am talking about expression templates. Its not pretty by any one's standards but with suitable libraries you can get the job done.

> I don't think any Lisps are fast enough to be interesting to you

Under favorable circumstances Lisps can easily give C++ a run for its money, even on numeric code. For that take a look at Stalin. It's unbelieveable how much one can optimize, even without type annotations.

There are few new curly brace languages out there, that are trying to simplify generic programming. D is the more mature among these and the new exciting ones are Clay, Deca and Rust. All have been discussed on HN. Exciting times ahead.

A multithreaded runtime for OCaMl will be realy cool. I do not need that threads be surfaced as an API but the possibility that parallelism exposed by the functional style can be exploited by the runtime (perhaps based on options used to start the runtime).

Yes there is F# but mono I hear is not that great on Linux, though I have not tried it myself.

OCaMl / Stalin: An old and civil discussion https://groups.google.com/group/comp.lang.scheme/browse_thre...

Clay: http://claylabs.com/clay/ and recently discussed here http://news.ycombinator.com/item?id=3474722

Deca: discussed here http://news.ycombinator.com/item?id=3413936 and here http://news.ycombinator.com/item?id=3413936

Rust and D I think do not need championing :)

Re: Haskell's effect on my C++ : exploit the type system

#53
post #7

Do people really still make the `=` vs `==` mistake? GCC -Wall has had "warning: suggest parentheses around assignment used as truth value" since as long as I can remember.

I use Yoda Conditions[1] in C-oid languages, so the error would be visible even without warnings (because the program would refuse to compile).

[1]: http://stackoverflow.com/questions/2349378/new-programming-j...

Re: Haskell's effect on my C++ : exploit the type system

#54
post #52

Earlier quoted context omitted.

I think C++'s template feature is pretty unusual in languages. Lisps have macros, which are much more fully-featured and more hygienic than C macros, but I don't think any Lisps are fast enough to be interesting to you. I know that the Scala community is working on putting macros in. Have you looked at Ocaml and Scala? Those might be close enough to suit your needs, and I think it's only a matter of time before Scala…

> I think it's only a matter of time before Scala (or something like it) starts outperforming C++ on parallel problems. It is certainly plausible. But a few things need to change (i) JVM applications tend to be memory heavy, even if you can approach 75% of the run time speed of a C or a C++ application you would typically need a lot more memory. In my expeience it has been 8 times or more, YMMV. (ii) The other proble…

A multithreaded runtime for OCaMl will be realy cool. I do not need that threads be surfaced as an API but the possibility that parallelism exposed by the functional style can be exploited by the runtime (perhaps based on options used to start the runtime).

This. I would love to see a multithreaded Ocaml.

Re: Haskell's effect on my C++ : exploit the type system

#55
post #34

Earlier quoted context omitted.

That's why in C++ people seem to generally recommend inline functions instead. Not only do the arguments only get evaluated once, but the whole thing is type safe too. Of course, people still misuse macros.

Macros, by definition, are always misused, complete the languages point of view. They exist to let the programmer get the job done when the language falls short.

Well, I would define misuse as using them when the language doesn't fall short, like for the max example.

Re: Haskell's effect on my C++ : exploit the type system

#56
post #7

Do people really still make the `=` vs `==` mistake? GCC -Wall has had "warning: suggest parentheses around assignment used as truth value" since as long as I can remember.

I use Yoda Conditions[1] in C-oid languages, so the error would be visible even without warnings (because the program would refuse to compile). [1]: http://stackoverflow.com/questions/2349378/new-programming-j...

That's fine when you make a comparison against a constant, but what if you're comparing two variables?

Re: Haskell's effect on my C++ : exploit the type system

#57
post #35
post #16

One of the more clever not so well known C++ type system hacks I have seen is the way Ogre3D (a graphics engine for games) handle Degrees versus radians. Basically they have a class for each and have overloaded the operators so that you can mix and match operations freely (e.g you get a radian result from some computation which you can then add twenty degrees to simply by saying + Degree(20) and have the C++ type sys…

Do you mean "members are final" or "classes are final"? A final member is constant, which has nothing to do with inheritance. A final class has no subclasses.

All members are final, and it inherits from nothing -- that way there is no need to store any table of methods with each object as so the size requirement is limited to a single table.
Post reply on HN