Live data from Hacker News

Thinking in Types

robots.thoughtbot.com

111–120 of 124 posts

Re: Thinking in Types

#111
post #7

I'm getting tired of reading: > This is why we hear that Haskell reprise if it compiles, it works. If this were true then functions would not need bodies, you would just define their signatures and move on with life. The truth is that even with its superb type system, Haskell still needs to run your code. Your code might be statically correct but its runtime is up to you. I would prefer it if people rephrased this cl…

"If this were true then functions would not need bodies, you would just define their signatures and move on with life."

That's because both addition and multiplication, for example, have the same type signature.

    Prelude> :type (+)
    (+) :: Num a => a -> a -> a
    Prelude> :type (*)
    (*) :: Num a => a -> a -> a
A better rephrasing might well be "If it compiles and you've used the right operations, which is made easier because most of the wrong operations will blow chunks all over the place, it works."

Dependent typing anyone? (I think what you're looking for goes by the name "code extraction" in Coq, but I've never gotten into it as a programming environment.)

Re: Thinking in Types

#112
post #93

Earlier quoted context omitted.

I can add another anecdote. In almost 10 years now of using Haskell on Mac, Linux and Windows, I've never once had any success building any GUI binding for Mac OS, despite trying every one I could find (gtkhs included) at least once a year on many different OS/hardware combinations. (unless you count HOC, but I never actually got it working as-was - I brought it back from bit-rot on a couple occasions, adding ObjC 2…

Huh. It is sounding like there's an issue with Mac GUIs, then. Maybe the Mac/Haskell overlap is just too small? Both are small-to-niche... It would probably make sense to get a group oriented around getting that fixed up. For myself, I'm meeting my needs - and both 1) more GUI apps and 2) more Mac support are almost entirely orthogonal to them, so I'm not likely to participate.

> Maybe the Mac/Haskell overlap is just too small?

Probably so. Though I would suggest that the neither one is a small niche in itself. Mac especially--it's the favored platform for every developer I know except one. Yes, it's less popular outside tech circles (probably due in part to the price).

Imagine this scenario: There are tons of Mac users who want to learn Haskell. They try it, but can't install libraries. The Haskell community never hears from them; one could say the system failed silently. Meanwhile, Linux works fine, and the Haskell-Linux community keeps growing.

So perhaps there's a self-reinforcing Linux-centric bias in the developer population.

Re: Thinking in Types

#113

I think a better example is needed. The example's solution to the Haskell heterogeneous list "problem" could be implemented in other statically typed languages (C++, Java) although it wouldn't be necessary to do so. I don't see how the Haskell type system is safer in this example but I feel there's something interesting there which I don't understand. Can someone explain the advantage of type classes over what could…

"...although it wouldn't be necessary to do so."

That's actually the point. (Have you read the "wearing the hair shirt" paper?)

One of the hardest problems in moving from other languages to Haskell is that many of the solutions that you would immediately default to rely on run-time information or behavior, like the heterogeneous list. Those don't translate well, if at all. Instead, you need to step back and change the problem, by relying more on compile-time, type-level information.

Re: Thinking in Types

#114
post #20
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 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…

[deleted]

Re: Thinking in Types

#115
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…

To make this discussion more concrete, here are some problems I've thus far found on the Mac:

- GHC ships with the wrong compiler path for (some version s of?) OS X, causing various C-related stuff to fail. https://gist.github.com/cartazio/7131371

- ghc-pkg gets itself into an error state pretty quickly after installing a fresh Haskell Platform, and ghc-pkg recache must be run.

- You must manually request the latest version of cabal-install. cabal install cabal-install by default gives you a version without sandboxes.

These are just a few of the issues that come to mind; I've run into quite a few more in my Haskell explorations. You can imagine how this state of affairs would cause a lot of developers to give up. I'm not at all blaming anyone in the truly wonderful Haskell community. Everything about Haskell is done volunteers, and I'm grateful for their work. I'm just offering a theory as to why Haskell hasn't been embraced as warmly as, say, Node or Go.

Re: Thinking in Types

#116

Earlier quoted context omitted.

Huh. It is sounding like there's an issue with Mac GUIs, then. Maybe the Mac/Haskell overlap is just too small? Both are small-to-niche... It would probably make sense to get a group oriented around getting that fixed up. For myself, I'm meeting my needs - and both 1) more GUI apps and 2) more Mac support are almost entirely orthogonal to them, so I'm not likely to participate.

> Maybe the Mac/Haskell overlap is just too small? Probably so. Though I would suggest that the neither one is a small niche in itself. Mac especially--it's the favored platform for every developer I know except one. Yes, it's less popular outside tech circles (probably due in part to the price). Imagine this scenario: There are tons of Mac users who want to learn Haskell. They try it, but can't install libraries. Th…

I wouldn't at all say either is "a small niche." As niches go, they're both pretty large... I actually have no idea how the prevalence of Mac differs inside and outside tech circles. It's a decided minority in every case, with Windows still dominant and likely Linux still dominated (though I'm far less confident about that in dev circles than I used to be). For what it's worth, virtually every developer I know well enough to know what they prefer uses either Linux or Windows, with the exception of my mother who decided some few years back that Mac is "Unix enough" now. I expect that there's a lot of clustering, though, and neither of our experience represents a uniform sampling.

Your general point - that it's likely self-reinforcing - is certainly strong. I'd even expect it to be exacerbated a bit in this case by it being GUI things in particular showing issues, where (at the risk of stereotyping) there is probably a correlation between those who prefer a Mac and those who prefer a GUI.

Re: Thinking in Types

#117
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…

To make this discussion more concrete, here are some problems I've thus far found on the Mac: - GHC ships with the wrong compiler path for (some version s of?) OS X, causing various C-related stuff to fail. https://gist.github.com/cartazio/7131371 - ghc-pkg gets itself into an error state pretty quickly after installing a fresh Haskell Platform, and ghc-pkg recache must be run. - You must manually request the latest…

"- You must manually request the latest version of cabal-install. cabal install cabal-install by default gives you a version without sandboxes."

So far as I'm aware, doing a

   cabal update
   cabal install cabal-install
should always get you the latest version of cabal-install.

One thing people encounter frequently, that may be confused for this, is that cabal doesn't install things system-wide, and so you have to 1) make sure that the place cabal is installing things is in your path, and 2) possibly make sure your shell hasn't cashed the location of the old system-wide version of cabal.

It's totally possible that there's a bug that's more specifically as you describe that I just haven't heard of, of course - just trying to help if I'm able.

Re: Thinking in Types

#118
post #94

Earlier quoted context omitted.

My preferred way to approach this, in Haskell specifically, is to use records as a naïve encoding of objects or interfaces. For example, expanding on the functionality a little bit: data GameEntity = GameEntity { render :: IO () , getPosition :: Point , setPosition :: Point -> GameEntity } makeBall :: Point -> GameEntity makeBall pos = GameEntity { render = myRender , getPosition = pos , setPosition = mySetPos } wher…

> What I've done is used a record type to encode the interface that it's supposed to expose, I love how Haskellers (in general, not you in particular) bash OO and then come up with the exact same technique of simulating OO that is used in C (a struct of function pointers). Something which OO languages provide out of the box (interfaces, virtual methods, etc). Now, let's take this a step further: how would you simulat…

There is a slight technical difference that winds up being a more significant practical difference between the C solution (struct of function pointers) and the Haskell solution (record of Haskell functions): the Haskell functions can close over arbitrary data.

Re: Thinking in Types

#119

Earlier quoted context omitted.

> So go ahead and download the binary Indeed I did just that, the issue is that the only binary distributions for Linux are CentOS 6 and some flavor of Debian, both of which are dinosaurs compared to any modern distro. The long and short is the installation fails due to a missing dependency on antiquated libgmp.so.3, thus cooking my CPU for an hour and building from source. If you want to talk about barriers to Haske…

"both of which are dinosaurs compared to any modern distro." Without any clue of what constitutes "any modern distro" in your mind, I don't see how this can proceed further. Note that Centos 6.5 and Debian wheezy are the latest from their respective projects. I believe the Debian version will happily install under recent Ubuntu and derivatives. I'm sorry your preferred distro doesn't have better support.

Fedora here, Debian's not an option (which would work as it's got the libgmp every "modern" Linux distro has).

CentOS binary is the only choice and it won't work. FWIW CentOS 6 is equivalent to Fedora 12 or so (latest is Fedora 20).

Anyway, it's done, but a serious PITA, hopefully in future there will be a more sane way to get started exploring the latest & greatest.

Re: Thinking in Types

#120
post #7

I'm getting tired of reading: > This is why we hear that Haskell reprise if it compiles, it works. If this were true then functions would not need bodies, you would just define their signatures and move on with life. The truth is that even with its superb type system, Haskell still needs to run your code. Your code might be statically correct but its runtime is up to you. I would prefer it if people rephrased this cl…

I always took that quote as more of a feign-arrogance joke than a truism.
Post reply on HN