3 ms·

So far, your reply about Haskell seems the only promising alternative to C. Could you imagine to develop in Haskell and use, e.g., HaskellDirect, for C librarie

by fnl 16y ago

So far, your reply about Haskell seems the only promising alternative to C. Could you imagine to develop in Haskell and use, e.g., HaskellDirect, for C libraries that are not available in Haskell for certain tasks? And, it seems you can even interface with Python (see "http://wiki.python.org/moin/PythonVsHaskell http://wiki.python.org/moin/PythonVsHaskell) via the ctypes. So far, I conclude that Haskell could be the most promising language for the upcoming "onslaught" of multicore/multiprocessor architectures (especially when I look at how clean the syntax for distributed processing is). But then I also have read much blogs like this one "http://www.jelovic.com/articles/why_people_arent_using_haskell.htm http://www.jelovic.com/articles/why_people_arent_using_haske.... So is it really worth it to dive into Haskell?

wtracy 16y ago
I concur that the Haskell libraries are pretty crummy. (There's no built-in function to split a string on an arbitrary delimiter? Really?) I'll also say that Haskell has a really steep learning curve, especially if you're coming from a procedural/object oriented background. I've programmed in Scheme and ML before, and neither were as mind-bending as Haskell. I haven't done any projects yet that involved mixing Haskell with another language, so I can't comment on that. That's probably the most sane way to do a large app with Haskell--use Haskell for what it's good at, and use C/Python for what they're good at. If I had heard about Erlang's concurrency support earlier, I might have gone with it instead of Haskell, because Haskell is so hard to learn. Now that I'm already partway over the Haskell learning curve, it seems nice enough to stick with. I really can't say yet whether Haskell is worth learning. Keep in mind that it will be hard to bring new programmers on board with a large Haskell code base. (I'm using it for hobby projects, so that's a non-issue.) The best answer I can give is: If you're going to be writing large swaths of code that make few or no system calls and that are CPU intensive, it might be; otherwise, no. EDIT: Let me try to clarify what I mean by the "mind-bendingness" of Haskell. Think about the Integer and String objects in Java--once instantiated, they are immutable. All data in Haskell behaves like this. However, this immutable data lives on the stack, so you can't just reassign the reference to a new object. (If you want to increment your parameter x, you have to make a recursive call with x + 1.) The exception here is a construct called a monad. Inside a monad, you can reassign references to new objects, and the old objects are cleaned up by the garbage collector. The intermediate objects are invisible to code outside the monad. (As an example, I/O is done inside of monads.) The two things I like about Haskell are the concurrency support (if you can wrap your head around the above paradigm!) and the syntax (you can do Python-style significant whitespace, or C-style semicolons and brackets, your pick). Unfortunately, Haskell manages to screw up almost everything else.
- fnl 16y ago
  Well, following the advice I got here I started out with Erlang - where you have much of the same issues you describe, too. However, having immutable variables also allows for some pretty nifty stuff in Erlang (and I guess in Haskell even more; thinking of assignment as regex matching etc.), and I would even say for Erlang, which has no static type safety, it actually might come as a blessing. I don't know how often I have traced errors in dynamic languages exactly because of that (or - even worse - still have bogus code I never noticed...). And I don't know why, but to me functional programming in C, Python and Lisp always had seemed far easier than grasping a decent OO model in Java or anything - at best I liked AOP, but that seems pretty quiet nowadays; and with "green threads" and all that stuff coming along, it seems that my easier approach to "functional" is a benefit finally...

by fnl 16y ago

wtracy 16y ago

I concur that the Haskell libraries are pretty crummy. (There's no built-in function to split a string on an arbitrary delimiter? Really?) I'll also say that Haskell has a really steep learning curve, especially if you're coming from a procedural/object oriented background. I've programmed in Scheme and ML before, and neither were as mind-bending as Haskell. I haven't done any projects yet that involved mixing Haskell with another language, so I can't comment on that. That's probably the most sane way to do a large app with Haskell--use Haskell for what it's good at, and use C/Python for what they're good at. If I had heard about Erlang's concurrency support earlier, I might have gone with it instead of Haskell, because Haskell is so hard to learn. Now that I'm already partway over the Haskell learning curve, it seems nice enough to stick with. I really can't say yet whether Haskell is worth learning. Keep in mind that it will be hard to bring new programmers on board with a large Haskell code base. (I'm using it for hobby projects, so that's a non-issue.) The best answer I can give is: If you're going to be writing large swaths of code that make few or no system calls and that are CPU intensive, it might be; otherwise, no. EDIT: Let me try to clarify what I mean by the "mind-bendingness" of Haskell. Think about the Integer and String objects in Java--once instantiated, they are immutable. All data in Haskell behaves like this. However, this immutable data lives on the stack, so you can't just reassign the reference to a new object. (If you want to increment your parameter x, you have to make a recursive call with x + 1.) The exception here is a construct called a monad. Inside a monad, you can reassign references to new objects, and the old objects are cleaned up by the garbage collector. The intermediate objects are invisible to code outside the monad. (As an example, I/O is done inside of monads.) The two things I like about Haskell are the concurrency support (if you can wrap your head around the above paradigm!) and the syntax (you can do Python-style significant whitespace, or C-style semicolons and brackets, your pick). Unfortunately, Haskell manages to screw up almost everything else.

fnl 16y ago
Well, following the advice I got here I started out with Erlang - where you have much of the same issues you describe, too. However, having immutable variables also allows for some pretty nifty stuff in Erlang (and I guess in Haskell even more; thinking of assignment as regex matching etc.), and I would even say for Erlang, which has no static type safety, it actually might come as a blessing. I don't know how often I have traced errors in dynamic languages exactly because of that (or - even worse - still have bogus code I never noticed...). And I don't know why, but to me functional programming in C, Python and Lisp always had seemed far easier than grasping a decent OO model in Java or anything - at best I liked AOP, but that seems pretty quiet nowadays; and with "green threads" and all that stuff coming along, it seems that my easier approach to "functional" is a benefit finally...