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

51–60 of 124 posts

Re: Thinking in Types

#51

Post by dllthomas »

jarrett wrote: post #45
dllthomas wrote: post #37

Earlier quoted context omitted.

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?

"Is there a standard place on Hackage or in ghc-pkg where one can find that info?"

Both! It's in the ghc-pkg dump output, though there's doubtless a better way at getting at that. As for Hackage, if you just pare the above link back to https://hackage.haskell.org/package/hsqml you'll find package meta-info which includes:

    Author	Robin KAY
    Maintainer	komadori@gekkou.co.uk
    Home page	http://www.gekkou.co.uk/software/hsqml/
    Source repository	head: darcs get http://hub.darcs.net/komadori/HsQML/

Re: Thinking in Types

#52

Post by dllthomas »

jarrett wrote: post #47
dllthomas wrote: post #39

Earlier quoted context omitted.

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 p…

Certainly the case. Much eased (though not eliminated) by the recent addition of cabal sandboxes. There's still no good way to see all the native libraries required by a cabal install, and occasionally there are actual conflicts between packages... I've been meaning to populate http://en.wikibooks.org/wiki/Haskell/Resolving_Cabal_Hell but have been kinda hoping (almost certainly in vain) that someone with deeper knowledge beats me to it.

Re: Thinking in Types

#53

Post by virtualwhys »

wting wrote: post #40
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). - S…

It's worth pointing out that the presenter's first language was Haskell and he's been coding in it for over a decade.

LYAH won't get you from apples to expert in weeks, much less months; more likely years.

Consider me skeptical -- needing to build the latest and greatest of Haskell [7.8] from source on a modern Linux distro (CentOS binary with antiquated libgmp.so.3 dependency, seriously?) is a gigantic PITA compared to virtually every other language where you just download a standlaone binary of latest & greatest from langugage X, modify your PATH, and hit the ground running.

Re: Thinking in Types

#54

Post by VMG »

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.

While what you suggest is reasonable and the right thing to do, it just highlights the original point. The state of UI bindings is pretty bad.

Re: Thinking in Types

#55

Post by tree_of_item »

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…

As a fellow green Haskell developer, I get the sense that the best option is going to be GHCJS[0]. The browser is far and away the best environment for graphics programming because of its ubiquity and easy to use APIs. Sure, someone could step up to the plate and write a nice, idiomatic wrapper for SDL and OpenGL and whatever, but a good Haskell library that targets the browser would spread like wildfire in comparison.

[0] https://github.com/ghcjs/ghcjs

Re: Thinking in Types

#56

Post by tel »

dllthomas wrote: post #36
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 distinc…

I think on second thought, the easy comes more from purity than laziness.

Re: Thinking in Types

#57

Post by tel »

badman_ting wrote: post #44

"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 ins…

There are a few other differences as well. I'm not completely familiar with the ins and outs of Java interfaces, but:

    * You can instantiate types to classes at any point in
      time (type definition, class definition, or even orphan 
      instances, though that last category is frowned upon)

    * Typeclasses indicate typing bounds but do not destroy 
      type information. This means that we can define 
      things like

        showableId :: Show a => a -> a
        showableId x = x

      which allow only showable types to pass but does not 
      destroy type information

        > showableId (3 :: Int)
        3 :: Int
        > showableId (id :: Int -> Int)
        !! Type error

    * Typeclasses can dispatch on *any* type in the signature.
      This includes the famous "return type polymorphism" but
      generally means that typeclass resolution involves 
      solving a terminating form of Prolog during 
      typechecking. This means that type information flows
      forward and backward over judgements and allows for
      greater inference.

    * Typeclasses can abstract over higher kinded types. So we
      can write something like

        count :: Traversable t => t a -> Int
        count = getSum 
              . getConst 
              . traverse (const $ Const (Sum 1))

      which generically counts the elements in any container
      instantiating the "interface" Traversable.
There's also some even funkier techniques you can use when you start involving MultiParamTypeClasses, FunctionalDependencies, or TypeFamilies.

Re: Thinking in Types

#58

Post by dllthomas »

tel wrote: post #56
dllthomas wrote: post #36

Earlier quoted context omitted.

"[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 distinc…

I think on second thought, the easy comes more from purity than laziness.

I think I agree. Especially where safe implies easy.

Re: Thinking in Types

#59

Post by tel »

AnimalMuppet wrote: post #43
zmoazeni wrote: post #29

Earlier quoted context omitted.

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?)

There are more real solutions which scale better, but in these toy problems it's hard to get to the meat of the problem. Sometimes the "existential antipattern" is a good choice (see Oleg's finally tagless encoding of, say, the linear lambda calculus). Sometimes creative use of static structure can scale much more neatly than lists of concrete objects.

Re: Thinking in Types

#60

Post by rntz »

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…

Could you explain what you mean here by initial/final encoding, and why you say OO favors final encodings but initial encodings generate type information? I'm familiar with the notions of initial algebra, and slightly less so with final coalgebras, but I don't quite see what you're getting at.
Post reply on HN