Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thinking in Types

robots.thoughtbot.com

Post reply on HN
Print view View original

31–40 of 124 posts

Re: Thinking in Types

#31

Post by sparkie »

> If we’re careful in our module exports, a change like this can be done in a backward-compatible way. Such an approach is outlined here (http://www.yesodweb.com/blog/2011/10/settings-types).

The problem with this import solution is that almost nobody actually does it! Nearly every module you will ever import exposes most of the constructors of the ADTs they define - because Haskell encourages it - it's much simpler and cleaner to pattern match over constructors than the functions you use in place of them in order to encapsulate the constructors - which you need to use guards to match over instead.

Re: Thinking in Types

#32

Post by m0a0t0 »

dmunoz wrote: post #4
woah wrote: post #2

Seeing so much stuff about Haskell lately, but there seems to be a curious dearth of actual software written in it, if it's so great. How is it that janky hacked together languages like JS and PHP have huge numbers of projects built with them, while a supposedly superior language like Haskell is mostly academic? If it really makes you that much faster, where are the apps?

I understand the critique being made, but this seems like a slightly outdated view of Haskell. There is quite a bit of software being written in Haskell these days. One project that got some press recently is a long existing project that recently went open source, Cryptol [0]. While lots of projects in Hasekll continue to be libraries written for Haskell, there are also lots of languages using Haskell for their imple…

To be fair most of the trending github projects are libraries for use in Haskell. There are very few actual applications - there is pandoc, git-annex and hakyll and that is it.

Re: Thinking in Types

#33

Post by jarrett »

sgerrand wrote: post #30
jarrett wrote: post #22

On a related note: The article (quite reasonably) avoids discussion of the graphics library, but I want to know more about that side of things. I wish graphics got more attention in the Haskell ecosystem in general. The options right now are pretty dismal. There is quite literally not a single Haskell graphics or GUI package that I've been able to install on OS X. I'd love to use Haskell to build games or desktop GUI…

Have you looked at the Haskell QML bindings? They generally work for cross platform requirements. http://hackage.haskell.org/package/hsqml-0.1.1/docs/Graphics...

Yes. It does not compile on my Mavericks machine. Same with every graphics package I've tried.

Re: Thinking in Types

#35

Post by zmoazeni »

platz wrote: post #6

Frequently there will be many different ways to solve or architect a problem in Haskell, for better or worse depending on your viewpoint. Personally I think it it is better. But anyways, another option would be to make a type for your list which wraps each possible element, then you can just pattern match on the ADT. Also slightly concerned that this has language targeting beginners with almost 0 Haskell knowledge: I…

I'm all for more posts like this and I hope we see more. I think it helps tear down the misconception that Haskell is only for people who do a ton of research beforehand.

Re: Thinking in Types

#36

Post by dllthomas »

tel wrote: post #10

Heterogenous lists are always coming up when people try to translate OO ideas into Haskell. It's great that this example used the barrier of heterogeneity as a reason to think harder about their design instead of barreling forward. In particular, heterogeneity causes a form of information loss via type erasure (existential typing). The problem is that this is pretty heavy machinery and is not always well-suited to su…

"[I]f you have an existential type where only one way forward remains... you may as well just take that way forward. This is especially easy in a lazy language like Haskell."

This doesn't seem especially easy in Haskell (in that it doesn't seem harder elsewhere), but especially the case a lazy language like Haskell. In an eager language, (forall a . Renderable a => a) is isomorphic to (() -> IO ()) and subtly distinct from (IO ()).

Re: Thinking in Types

#37

Post by dllthomas »

jarrett wrote: post #33
sgerrand wrote: post #30

Earlier quoted context omitted.

Have you looked at the Haskell QML bindings? They generally work for cross platform requirements. http://hackage.haskell.org/package/hsqml-0.1.1/docs/Graphics...

Yes. It does not compile on my Mavericks machine. Same with every graphics package I've tried.

Get in touch with the developers and work with them to get it building. Often times they don't have access to your platform, so just being that helps. Anything you can do on top of that is gravy.

Re: Thinking in Types

#38

Post by platz »

zmoazeni wrote: post #35
platz wrote: post #6

Frequently there will be many different ways to solve or architect a problem in Haskell, for better or worse depending on your viewpoint. Personally I think it it is better. But anyways, another option would be to make a type for your list which wraps each possible element, then you can just pattern match on the ADT. Also slightly concerned that this has language targeting beginners with almost 0 Haskell knowledge: I…

I'm all for more posts like this and I hope we see more. I think it helps tear down the misconception that Haskell is only for people who do a ton of research beforehand.

Fair enough, I'm for whatever works!

Re: Thinking in Types

#39

Post by dllthomas »

IsTom wrote: post #25
jarrett wrote: post #20

Earlier quoted context omitted.

I think the package ecosystem is a big barrier. I code on OS X, and it seems like half the Haskell packages I try to install fail to compile. I always get super motivated to do my next project in Haskell, but then give up when I can't install the required libraries. Maybe the situation is better on Linux. In any case, I think Haskell will need reliable package management on at least OS X and Linux before most develop…

It's not that much better on Linux. As a fan of Haskell it makes me sad.

It's tractable, but a lot more manual than it should be. It makes everyone sad.

Re: Thinking in Types

#40

Post by wting »

woah wrote: post #2

Seeing so much stuff about Haskell lately, but there seems to be a curious dearth of actual software written in it, if it's so great. How is it that janky hacked together languages like JS and PHP have huge numbers of projects built with them, while a supposedly superior language like Haskell is mostly academic? If it really makes you that much faster, where are the apps?

Haskell is used in the NYTimes special features group that deploys 60+/yr web apps.

http://www.infoq.com/presentations/haskell-newsroom-nyt

tldw:

- RoR shop, too slow and can't afford to scale simply by spinning up more AWS instances.

- Haskell type system results in fewer bugs, less downtime than RoR.

- Haskell's Conduit library is great for information flow (e.g. scanning Twitter firehose for breaking stories).

- Static binaries for easy deployment.

- Declarative style and expressiveness helps coworkers understand code quickly.

Post reply on HN