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

41–50 of 124 posts

Re: Thinking in Types

#41

Post by freyrs3 »

tel wrote: post #13
bilalq wrote: post #12

Earlier quoted context omitted.

The ecosystem plays a big part in this. NPM is actually a pretty nice package manager to work with. Cabal, on the other hand, took me quite some time to setup and use.

Cabal is actually an extremely nice package manager... it just, like much of Haskell, likes to tell you things won't work far before they fail. In particular, building things with Cabal requires that everything compiles together successfully. This is a much stronger requirement than NPM and has push some more sophistication into the dependency resolution Cabal does.

Indeed, if we deferred all type errors and compile failures from Cabal to runtime like Javascript/NPM then nobody would complain about Cabal! I think it's unfortunate that Cabal get's so much unnecessary blame when the problem is often in some other place entirely.

Re: Thinking in Types

#42

Post by zmoazeni »

jarrett wrote: post #20
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 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…

I'm not sure which issues you're running into, but for what it's worth, I've had a lot better success using the newer cabal sandboxes[1] than just running `cabal install foo` all the time. (If you're from the Ruby world, it acts a lot more like bundler with `--standalone`).

Previously, I had more issues with conflicting version constraints which I think is more of an issue with library authors and not necessarily cabal itself.

[1] - http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html

Re: Thinking in Types

#43

Post by AnimalMuppet »

zmoazeni wrote: post #29
AnimalMuppet wrote: post #24

I'm not sure that this works in more general cases, though. If I have a more general game with more objects of more types in it, adding each type to the render function is going to get old. In object oriented programming, I'd just call render() on each entry in the list of game objects. But this approach is going to lead me to: - render each entry in the list of Foo objects - render each entry in the list of Bar obje…

The post links to this page http://www.haskell.org/haskellwiki/Heterogenous_collections and one of other solutions is to use existential types to do it. But the author even said: However, I don’t think this is a good use case. We can get around this problem in a cleaner and safer way by using the type system rather than subverting it.

Right, I know he said that. But my point is, his solution doesn't scale well to a more complicated problem. (Unless I misunderstood either his solution or your point?)

Re: Thinking in Types

#44

Post by badman_ting »

"A type class defines a set of functions which must be implemented for a type to be considered in that type class. Other functions can then be written which operate not on one specific type, but on any type which is in its given class constraint."

Call me crazy but this just sounds like a Java interface to me.

Edit: On further thought, I guess the difference is that in Java, the interface itself is a type. So all instances of classes which implement IShowable can be said to be of type IShowable. Whereas it seems that in Haskell a typeclass is not, itself, a type.

Re: Thinking in Types

#45

Post by jarrett »

dllthomas wrote: post #37
jarrett wrote: post #33

Earlier quoted context omitted.

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.

Sometimes I do. Often, if a Haskell package doesn't have a Github repo, I don't know how to contact the developers or submit a bug report. Is there a standard place on Hackage or in ghc-pkg where one can find that info?

Re: Thinking in Types

#46

Post by jarrett »

zmoazeni wrote: post #42
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…

I'm not sure which issues you're running into, but for what it's worth, I've had a lot better success using the newer cabal sandboxes[1] than just running `cabal install foo` all the time. (If you're from the Ruby world, it acts a lot more like bundler with `--standalone`). Previously, I had more issues with conflicting version constraints which I think is more of an issue with library authors and not necessarily cab…

I'd love to, but Haskell Platform ships with an old version of Cabal that doesn't have sandboxes. The new version of Cabal itself doesn't compile on the Mac. (In keeping with the theme of "nothing compiles.")

Edit: At least, I can't get the new version of Cabal/Cabal Install working on my Mac.

Re: Thinking in Types

#47

Post by jarrett »

dllthomas wrote: post #39
IsTom wrote: post #25

Earlier quoted context omitted.

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.

Manual is OK if there's at least a clear path to getting something to install. I don't see that path, though.

My biggest issue is that I don't have the expertise to debug an obscure Haskell compilation error. I won't develop that expertise unless I can use Haskell over the long term on real projects. I can't do that unless libraries are available. So it's a chicken and egg problem.

I think the same is true for many people who'd like to dive deeper into Haskell. If we can't initially lean on the work of expert package maintainers, we can't ever become Haskell experts ourselves. I believe the developer community could expand very quickly if this problem could be solved.

Re: Thinking in Types

#48

Post by virtualwhys »

ephemeralgomi wrote: post #23
spitfire wrote: post #8

Earlier quoted context omitted.

Well, JS is used because it's the only way to run code on a client system. If there were a byte-code available you can bet people would be using other languages. ASM.js exists, and many languages compile to js at the moment. As for PHP, lots of people still eat at McDonalds. I can't explain why.

Partially because McDonalds/PHP lets you eat/deploy by cramming/uploading the food/file directly into your mouth/server. No utensils/tools required.

> No utensils/tools required

I think a more apt analogy would be: no furnace to forge your own cooking utensils (hour long build from source to get latest and greatest [7.8] installed) which you use to prepare the meals (wait for your application to compile) that you then stuff into your mouth (deploy to server).

Re: Thinking in Types

#49

Post by [deleted] »

AnimalMuppet wrote: post #24

I'm not sure that this works in more general cases, though. If I have a more general game with more objects of more types in it, adding each type to the render function is going to get old. In object oriented programming, I'd just call render() on each entry in the list of game objects. But this approach is going to lead me to: - render each entry in the list of Foo objects - render each entry in the list of Bar obje…

[deleted]

Re: Thinking in Types

#50

Post by badman_ting »

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?

Honestly, it seems to me like if you don't understand category theory and type theory well, using Haskell will be either hard or impossible. That's what people who are into Haskell are into, and they seem to be a relatively rare breed. (I have a lot of trouble understanding these subjects, though I continue to try. I still don't know what the hell a monad really is.)
Post reply on HN