| | chongli on July 12, 2015 | parent | context | favorite | on: Translating Haskell to C++ metaprogramming
I don't know why people don't just use Haskell. Because perception is everything in this business. Haskell is perceived to be an impractical, academic language. Therefore, people refuse to use it and instead try to translate lessons they learned from it to "more practical" languages such as C++. If everyone was working solo and didn't need to justify their decisions to others, maybe Haskell would catch on faster. As it is, people seem to find it harder to convince others in their groups/teams/companies to use Haskell than to simply go with what everybody else is using. |  | | SamReidHughes on July 12, 2015 [–]
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, once written, than imperative code. †Edit: Well, it's practical for some stuff, but it's not particularly more practical than other languages, and there's a big spooky bit of danger that comes with it. | | | | codygman on July 13, 2015 | parent | next [–]
> 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 makes it much easier to edit then it's imperative counterpart which likely depends on global mutable state. > Lazy evaluation is a big risk, if you aren't writing programs that start and finish. Have you written much lazy evaluated code? Have you written much Haskell code? > and there's a big spooky bit of danger that comes with it. Can you elaborate on this? It sounds like "Haskell is bad because reasons that are spooky". | | | | efnx on July 13, 2015 | root | parent | next [–]
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 ;) | | | | deeviant on July 13, 2015 | root | parent | prev | next [–]
You link two cherry picked pro-Haskell links as proof that "the world believes that Haskell's is totally practical language"? Good grief. | | | | codygman on July 13, 2015 | root | parent | next [–]
I was never trying to prove "the world believes that Haskell's is totally practical language". My response was purely a rebuttal to: "Haskell's perceived as an impractical language because it is one" The "cherry picked pro-Haskell links" were picked because they link to examples of Haskell's practical uses in industry. Should I have created a faulty rebuttal that didn't list real world counter-examples of "Haskell's perceived as an impractical language because it is one"? I don't think I could find a link to practical uses of any language in industry that wasn't "cherry picked". | | | | SamReidHughes on July 13, 2015 | root | parent | prev | next [–]
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 global state by looking at its argument list. Those that use database connections take the database connection. Those that create database connections receive a parameter that tells them what to connect to. Pretty much everything writes log messages. If you're in a position to choose Haskell, then you're also in a position to make your software this way. | | | | phamilton on July 13, 2015 | root | parent | next [–]
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. | | | | SamReidHughes on July 13, 2015 | root | parent | next [–]
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. | | | | codygman on July 13, 2015 | root | parent | next [–]
> 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 imperative ones with ST when needed? If not, I don't think you can fairly say that Haskell is bad for programming contests whereas C++ worked out pretty well. You at least need to compare the two with an equivalent knowledge of implementing algorithms with each, not that figuring out or even approximating that equivalence would be easy . > You'll find yourself much more aware of how much time you spend stumbling over functional code after that. I'm well aware of when/how much I stumble over functional code since I still have vastly more experience with the imperative paradigm. All I can do is try and keep an open mind to logical arguments and keep writing code in multiple languages and multiple paradigms to know what the best answer is for a given scenario or set of scenarios. > how keyboard users often overlook cases where using a mouse would be more efficient Don't see how this is relevant, but I'll bite... what cases would this be? I of course agree that gaming or navigating a 3d world is better with a mouse, but I struggle to see where programming related tasks would be better suited to using mouse. | | | | SamReidHughes on July 14, 2015 | root | parent | next [–]
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. | | | | SamReidHughes on July 13, 2015 | root | parent | prev | next [–]
As for Haskell, I was... fully functional, programming with... multiple techniques. | | | | efnx on July 13, 2015 | root | parent | prev | next [–]
Yeah, for and while loops can be done with a simple fold - accumulating a tuple. But you've got so many other options. | | | | codygman on July 13, 2015 | root | parent | prev | next [–]
> 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 | | | | mightybyte on July 13, 2015 | parent | prev [–]
> 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 truth. Haskell's ease of maintenance is vastly better than every other language I've used because of purity and its much more advanced type system. I've had a colleague make a highly non-trivial sweeping change to a 2500 line application I had written that they had not worked with before and their change worked literally the first time they got it to compile. This is not one of those statements of "if it compiles, it works", which are obvious hyperbole to make a point. It's an actual experience I've had that happened exactly that way. My coworker and I were rather surprised and we both agreed that there's no way that could have happened in any other language in mainstream use today. It's actually still in our commit log with the description "Godly refactoring". | | | | SamReidHughes on July 14, 2015 | root | parent [–]
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). | | | 
