91–100 of 124 posts
Earlier quoted context omitted.
Lots of typeclasses have associated "laws" that well-behaved instances are expected to abide by.
But these are not enforceable by the type system (at least in Haskell), kind of supporting my point that types alone are rarely sufficient :)
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…
It's not just OSX, it's a problem (in general) on windows, too. I was trying to create my first haskell project as a web crawler. Every direction I turned I had issues installing libraries to the point where I decided it's a deal breaker because I can't write code on my preferred OS. Even if they eventually make these transitive dependencies OS agnostic, the libraries that already exist will depend on the versions th…
Earlier quoted context omitted.
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.
I wasn't making any point. Fwiw, I have been able to meet my own (quite limited) gui needs in Haskell with gtk... Edit: On reflection, I find your assertion a little strange here. Anecdotal failure to build on one particular setup doesn't seem like a particular highlighting of bad bindings.
(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 support and rewriting a fair chunk of the low-level stuff, but never did find the time to update the fragile header-parsing stuff for the actual Cocoa-binding generator)
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…
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…
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 simulate double-dispatch, or multiple dispatch in Haskell? This is sorely missing from mainstream OO languages.
Earlier quoted context omitted.
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…
Why do you need to build the latest and greatest? Building the very latest gcc/clang is also going to be a PITA. In either case, there's a perfectly servicable binary distribution and the stuff packaged in my OS's repo is still plenty usable.
Why shouldn't I? When Scala 2.11 was released I downloaded the binary, changed my PATH, fired up a new terminal and started exploring the latest release. Takes 2 minutes or so.
I'd like to do the same with Haskell. 7.8 looks to have significant language improvements that I want to explore vs. read about and be stuck on 7.4.1 (Fedora 18's provided version).
Earlier quoted context omitted.
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.
And I agree that sandboxes are great!
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.
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…
As for multiple dispatch, you could always use multi-param type classes:
{-# LANGUAGE MultiParamTypeClasses #-}
class Say a b where say :: a -> b -> IO ()
instance Say Int () where say = putStrLn "Case one"
instance Say Int Int where say = putStrLn "Case two"
(defgeneric say (a b))
(defmethod say ((a integer) (b null)) (format t "Case one"))
(defmethod say ((a integer) (b integer)) (format t "Case two"))
Earlier quoted context omitted.
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…
> 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 simple…