Comment by andrewflnr | Hacker News Reader

Comment by andrewflnr | Hacker News Reader

Parent Full thread

I had some similar experiences in OCaml recently, so I might be able to shed some light on this. I found that that when compiling code, the result was often one of three things: one, type checking failed (or I got an inexhaustive match warning), and I got a useful message, two, it worked, and three, it failed but the problem was fairly obvious when I saw it. Functional programming, for me, is a fairly direct way of expressing the algorithm in my head, so the basic idea tends to be much more fully fleshed out the first time I write it down in code.

Sometimes I got a type error from some bizzare syntax mistake, usually failing to correctly delineate an expression, and sometimes the algorithm in my head was just wrong and I had to fix it. At that point, the cycle starts over, and the same benefits I mentioned above help in debugging. FWIW, the problem I was working on was fairly simple, but novel. I was a very happy camper this Christmas, working with OCaml, despite its syntax.

Out of curiosity, what language do you do your "math and parsing" in? OCaml might be a good fit.

I do most of my $work programming in C++. (Not out of any great love for the language, mind you.)

To give a somewhat extreme example of the sort of stuff I do -- one of my current projects is to try to create a first-class fillet surface type [1] for the geometry engines I work with. My current code converts each fillet to a NURBS surface, but this is slow, consumes a lot of memory, and produces surfaces which frequently are not accurate enough for my purposes. So my hope is to be able to directly calculate points on the fillet and their derivatives.

It's easy enough to calculate points on the fillet surface, but I don't see any obvious way of directly calculating the derivative along the surface. So I've been investigating Chebyshev polynomials in two variables. But that algorithm looks a bit hairy, and I don't have any feel for whether it will be an actual improvement in practice. (And having written all this, I'm suddenly wondering if I'm making every effort to sort out the simple cases that are easy to solve exactly.)

My point here is that figuring out the correct types involved seems like a tiny, tiny part of the required work. Maybe it's because I haven't put in enough time in Haskell, but I don't see how stricter than C++ types are going to help. The real work is getting the math correct and fast enough to be useful.

By the way, my comment is not meant to be a dig at Haskell (et al). I'm not sold on it as a language, but it certainly has a lot of interesting ideas -- pattern matching and laziness spring to mind.

[1] http://en.wikipedia.org/wiki/Fillet_(mechanics)

Often when using C++ I find myself solving C++ problems, not real problems. In a domain with very difficult math and performance challenges, the C++ problems will be dwarfed by the difficultly of the real problem you are solving.

For domains outside of physics and applied math, I think the dominating factor is often the inherent trickiness of writing correct procedural code vs. the ease of writing strongly typed functional code.

Yeah, all your functions would basically be float -> float -> float -> etc . I would expect a functional language to be nicer for that anyway just because it's functional (expressions FTW!), but I also wouldn't be surprised if it wasn't worth switching languages for. I had the luxury of devoting about a week of vacation to my (rather abstract) pet project [0], half as an OCaml learning project. You have nearly the opposite situation (sounds fascinating, by the way).

Pattern matching is at least as much fun as it looks like, if you have complicated data types. That's a lot of what made OCaml so perfectly match my problem.

[0] https://github.com/andrewf/apatch if you're curious. The meat is in patch.ml

Reply on news.ycombinator.com