Becoming Productive in Haskell • Hacker News Board

Re: Becoming Productive in Haskell

#201

Post by Intermernet » Sat, Apr 25, 2015, 3:56 PM UTC

biftek wrote: post #137

lallysingh wrote: post #116

Earlier quoted context omitted.

No. The debugging time, refactor/rewrite time of writing in scripting languages is substantially longer, harder work, and distinctly unpleasant compared to just thinking and using good tools to do it right in Haskell. In Haskell, I'll often have a problem and just stare at my laptop and think for an hour. Then write a dozen lines of simple, straightforward code. The code is easy to test, and the problem is marked as…

Pausing for an hour to think about and understand your problem is important in any language. Probably more important than testing honestly.

I now do all of my logic and data structure design on paper. It usually ends up looking like a series of incomplete sketches, as I very quickly iterate over wrong ideas that would have taken hours to discover if I'd coded up all the alternatives.

The final few sketches almost always end up simpler than the original idea seemed!

I also try to follow ESR's paraphrasing of Fred Brooks:

"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."

I think this concept is actually more important than the choice of language.

Re: Becoming Productive in Haskell

#202

Post by Retra » Sat, Apr 25, 2015, 4:07 PM UTC

jonnybgood wrote: post #176

krick wrote: post #87

Earlier quoted context omitted.

> I also wouldn't want to do everything in Haskell. Examples, please? And why?

I heard Haskell is a poor choice for real-time systems and numeric computation. It's kinda ironic that a language as "mathy" as Haskell is such a poor choice for doing actual math. Assuming these things are true.

Actual math is really a pain in the butt on any computer, in any language. Doing it all in binary efficiently is the problem.

Re: Becoming Productive in Haskell

#203

Post by vilhelm_s » Sat, Apr 25, 2015, 4:23 PM UTC

cousin_it wrote: post #197

vilhelm_s wrote: post #91

Earlier quoted context omitted.

I think part of it may be that it helps with thinking, but with a different kind of thinking than scripting languages? There's that Perlis quote: "Show me your data structures, and I won't usually need your code; it'll be obvious". For me, a lot of thinking about programs involves thinking about the types of data involved, and there Haskell gives a language to talk about it. You can start writing down your datatypes,…

The quote is from Fred Brooks (author of "The Mythical Man-Month"), and it goes like this: > Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious. I don't think it's about exploratory programming. It's more about reading other people's code.

Wow, I got that extremely wrong huh. Thanks for the correction.

Re: Becoming Productive in Haskell

#204

Post by windlep » Sat, Apr 25, 2015, 7:15 PM UTC

codygman wrote: post #196

windlep wrote: post #177

Earlier quoted context omitted.

I tried to write a Haskell websocket server, the library is quite nice, but it leaked memory (space leak? fragmentation? some of both?): https://github.com/jaspervdj/websockets/issues/72 The author helped me narrow it down to some issues with how ghc by default allocates a stack space that is rarely enough, and once it starts growing the stack space the RAM per connection gets pretty ridiculous. Using higher default…

Great comments and better bug reports, just want to mention it actually says to always re-use Session in the wreq tutorial[0]. Perhaps it should be stated more prominently, repeated, or even both. For non-trivial applications, we’ll always want to use a Session to efficiently and correctly handle multiple requests. The Session API provides two important features: When we issue multiple HTTP requests to the same serve…

Yep, that was added after my bug report about it. Also fairly recently, he added the ability to do a request with no CookieJar at all.

Re: Becoming Productive in Haskell

#205

Post by zoybert » Sun, Apr 26, 2015, 3:40 PM UTC

windlep wrote: post #180

LukeHoersten wrote: post #123

Earlier quoted context omitted.

I've actually found the exact opposite. The library ecosystem is rich and mature. Haskell is, by default, "concurrency safe" because of referential transparency. You can safely "async" and compose almost any library in the Haskell ecosystem without worrying about shared memory etc underneath. Also, a lot of the really common libraries like text, attoparsec (parsers), aeson, networking, etc are highly tuned for low la…

I actually thought that too, but I guess that's not the case. I helped write some HTTP2 frame-parsers for Haskell using attoparsec, but apparently it wasn't fast enough as the lib author later rewrote all the attoparsec code to use pointers to the underlying byte buffers. https://github.com/kazu-yamamoto/http2/commit/0a3b03a22df1ca... The stream fusion stuff is sweet, but not exactly unique to Haskell since any langu…

I believe you're misunderstanding what stream fusion is. A language compiler does not really need "good iterator/generator abstractions" more than a guarantee of side-effect free transformations in order to be able to de-forest the intermediate data structures. http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.7...

Re: Becoming Productive in Haskell

#206

Post by windlep » Sun, Apr 26, 2015, 4:19 PM UTC

zoybert wrote: post #205

windlep wrote: post #180

Earlier quoted context omitted.

I actually thought that too, but I guess that's not the case. I helped write some HTTP2 frame-parsers for Haskell using attoparsec, but apparently it wasn't fast enough as the lib author later rewrote all the attoparsec code to use pointers to the underlying byte buffers. https://github.com/kazu-yamamoto/http2/commit/0a3b03a22df1ca... The stream fusion stuff is sweet, but not exactly unique to Haskell since any langu…

I believe you're misunderstanding what stream fusion is. A language compiler does not really need "good iterator/generator abstractions" more than a guarantee of side-effect free transformations in order to be able to de-forest the intermediate data structures. http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.7...

I meant more that languages with an iterator/generator usually have similar constant space usage. That is a drastic oversimplification of stream fusion and fails to mention other practical outcomes as you mention, along with a variety of optimizations.

I found this posting a little more approachable to seeing the various optimizations possible with stream fusion: https://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-...

Re: Becoming Productive in Haskell

#207

Post by dllthomas » Sun, Apr 26, 2015, 6:10 PM UTC

QuantumRoar wrote: post #124

dllthomas wrote: post #113

Earlier quoted context omitted.

Haskell does support mutable arrays. Your code that does the mutating will have to live in IO (or perhaps ST), but the downsides of that are exaggerated.

Oh. I didn't know that. Thanks for pointing that out.

Haskell strikes many as "bad for mutation" because introductory tutorials don't really cover it. This is because 1) mutation is not terribly idiomatic, 2) relying on mutation often (not always) a bad design decision, 3) Haskell handles the immutable case really well, and 4) mutation involves some more complexity than is involved in other languages. All of these are good reasons to avoid talking about mutation in a beginner Haskell tutorial, but when you need to address a problem where mutation is the best fit you'll find that it actually works pretty well. Haskell doesn't make mutation difficult, it makes it explicit, which has upsides and downsides.

Re: Becoming Productive in Haskell

#208

Post by dllthomas » Sun, Apr 26, 2015, 8:24 PM UTC

tel wrote: post #159

dllthomas wrote: post #99

Earlier quoted context omitted.

As others pointed out, the way Haskell uses the term "functor" is related to the way mathematicians had been using it for at least a decade before cfront. I agree that a shared vocabulary is important, but standardizing in a way that makes the mathematical writings on the topic more accessible seems a big win. Moreover, "functor" is a bit more precise than "mappable" - a functor is a mapping that preserves structure.…

I'm... hesitantly okay with "Functor == Mappable", but I really think Monad should be "Embedded DSL" and Monoid "mergeable". Or really Semigroup. Monad is definitely abnormally difficult to humanize. The trio (T, ∀ a. a -> T a, ∀ a b. (a -> T b) -> (T a -> T b)) is really hard to nail down.

I like "embedded DSL" for Monad, although I think more specialized notions might provide more hooks to hang understanding on in particular cases.

I don't object to "mergeable" for Monoid, but I think I weakly prefer "appendable" since it seems to say a little more about how things merge (and of course the free monoid is exactly that).

Speaking again to the broader context, one thing I really like about Haskell's choice of naming these abstractions after the math is that this type of discussion has no bearing on what types adhere to the abstractions - we're not left arguing over whether Sum and Product are "really" appending, or set intersection is "really" merging. Integers are a clearly monoid under Sum and Product, and set intersection is clearly a semigroup but not a monoid (if our universe is open) because there is no identity.

Re: Becoming Productive in Haskell

#209

Post by AnimalMuppet » Mon, Apr 27, 2015, 4:11 PM UTC

sordina wrote: post #189

AnimalMuppet wrote: post #184

Earlier quoted context omitted.

Fair enough. And yet, at the time (and even today, outside of the FP crowd), category theory is really far outside the scope of what most people consider programming, so it's hard to blame them for not looking there for terms. For that matter, category theory borrowed the word from linguistics, and most definitely did not keep the same meaning.

I certainly wouldn't blame anyone for not being familiar with the terms. What I would blame people for is attacking Haskell's choice of terminology due to it not 'being like c++'. A generous interpretation of intent goes a long way, and if that is out of reach, at least do enough research to make sure you're not pointing out weaknesses based on a false premiss. Instead I commonly see people starting from "I don't fin…

Well, let me see if I can meet you partway. Haskell is grounded in abstract algebra and category theory; using words like functor to mean what they mean in category theory is therefore a reasonable choice for Haskell.

But Haskell is a programming language. Using words like functor to mean something different from what other programming languages mean by the term creates a barrier to understanding for (non-FP) programmers. (The other definition is rather well established in non-FP circles, which is by far the majority of programming.) And when Haskell proponents state that their definition is right because it's the one from category theory, non-FP programmers find that rather arrogant.

Re: Becoming Productive in Haskell

#210

Post by grp » Tue, Apr 28, 2015, 10:35 AM UTC

gallabytes wrote: post #187

grp wrote: post #10

Earlier quoted context omitted.

Haskell with Emacs is awesome! There's a few modes available to have a powerful IDE. I don't remember which ones as xmonad + yi (or vi) is enough for me now.

How've you liked actually using yi? My only experience with it was rather frustrating.

My main reason of change is because emacs was getting too slow and buggy. After trying a few hacks in 'init.el' and co, it was getting worse... Suddendly Yi!

As I code only in haskell, it's perfect fun for me. Now, maybe a good way to start is using/practicing their Vimgolf client. [0]

In emacs, as I didn't use any others modes (except haskell-mode ...), I don't need their wonderful package managers any more.

[0] https://yi-editor.github.io/pages/vimgolf/