11 ms·

3d scene representation in Haskell

68 points by zik 12y ago

damncabbage 12y ago
I think there may be a typo with the first example: newtype ID a = ID Int deriving (Eq,Ord,Show) Should possibly just be: newtype ID a = ID a deriving (Eq,Ord,Show)
- edwardkmett 12y ago
  Nah, it is a type of numeric ID's for different types of things. The parameter 'a' is just a phantom type parameter to keep you from mixing up a mesh ID with a texture ID.
- ajtulloch 12y ago
  This is an example of a 'phantom type'. See http://www.haskell.org/haskellwiki/Phantom_type http://www.haskell.org/haskellwiki/Phantom_type (and references therein) for an explanation (including a motivation) of this technique.
orangeduck 12y ago
I think this demonstraights a real weakness of Haskell. Several times I've started a new project only to spend several hours trying to work out the correct way to structure what I want. Often it is hours before I even get my first successful compile. This is exactly as shown in this blog post. While some people enjoy this kind of tinkering, for me this really quickly saps all my motivation for the task. I just want to get something, anything, working. I work best jumping directly into a task and understanding it from the inside out, learning from my mistakes. Sometimes if I do find a quick and dirty way to get something working in Haskell - often refactoring it also becomes pretty difficult - which turns me off again. Neither of these are problems I have in other languages. Arguments for which approach is better aside, it is no wonder lots of people who learn and approach tasks like me, feel a little betrayed by Haskell. I've used it for a bunch of things, I'm past the steep learning curve - but it seems I'm still not reaping the rewards. Is my philosophy of jumping into projects really so bad? Is it Haskell's place to question such an approach, when it has served me so well elsewhere?
- reikonomusha 12y ago
  I agree. Haskell enforces a programmer to create structure. There's no way around it. And it's (nearly) impossible to hack things together without failing early and often. As a result, before the problem you're trying to solve can be explored, you're stuck making guesses on how the problem should even be structured. You spend a few hours with one guess, it turns out to not get your far, and you try another. The unfortunate part is that these guesses aren't letting you get to the meat of the problem effectively; you're stuck trying to solve a meta-problem. Of course, once you have solved the meta-problem well enough, you can start exploring your problem. Unfortunately, you may find that your meta-solution doesn't actually let you answer questions you didn't know you wanted to answer from the get-go, and now you're back to square-one. When everything is right, the program is usually very beautiful, safe, and—if you're skilled enough—efficient. Perhaps not all Haskell programmers have this issue for very non-trivial programs, though I certainly do.
  - lclarkmichalek 12y ago
    I don't really agree. The greatest structure in most of my Haskell programs is some kind of ErrorT or something. That requires me to structure the way I handle IO and the way that Errorable things happen, but beyond that, `a` is just as generic as any Python type. Sure, a lot of libraries do require you to accept certain premises, which may be a problem, but most of them provide ways to break out of their abstractions: ErrorT provides `runErrorT :: (Monad m, Error e) => ErrorT e m a -> m (Either e a)` which allows me to break out very easily, and due to the composable nature of Haskell, even if the library does not provide a function, it is often far from hard to write one yourself.
  - tinco 12y ago
    I agree that Haskell forces the programmer to create structure, but I don't agree with your meta-problem hypothesis. I think the structure actually is a big part of the real problem, and Haskell just prevents you from implementing incomplete or incorrect solutions. Those solutions might in another language require a hack or leaky abstractions to work, if they would be possible to get to work at all. I've walked into problems like the OP has before with Haskell, and when there seems to be no nice way of defining a type structure to model the problem, it usually meant that the idea in my head had a fundamental problem. If I look at this tree I get the feeling that perhaps he just has two problems, and he's looking at it like he's got only one. And once you do get your type structure neatly in place, often times the implementation will just flow out of your fingertips. And when it does, it will be powerful, flexible and robust.
hawkharris 12y ago
A very small tip for people learning Haskell (coming from a fellow newcomer to the language): as you read the code, mentally replace "::" with "has type of."
joereggan190 12y ago
http://learn.hightail.com/t5/Ideas/Watch-2014-FIFA-World-Cup-Argentina-vs-Brazil-Live-Stream-Online/idi-p/86912 http://learn.hightail.com/t5/Ideas/Watch-2014-FIFA-World-Cup...
wyager 12y ago
This is the "problem" with haskell. It makes you have a reasonably good model before you can even codify it. You have to front-load all the whiteboarding. Everything is easier (and usually bug-free) after that. There have been many times where my inability to codify a mental model in haskell made me realize why that mental model was inherently wrong/unsafe.
lobster_johnson 12y ago
Lots of good discussion in this thread -- but no suggestions relevant to the author's problem. Is there a better solution?

68 points by zik 12y ago

I think there may be a typo with the first example: newtype ID a = ID Int deriving (Eq,Ord,Show) Should possibly just be: newtype ID a = ID a deriving (Eq,Ord,Show)

edwardkmett 12y ago
Nah, it is a type of numeric ID's for different types of things. The parameter 'a' is just a phantom type parameter to keep you from mixing up a mesh ID with a texture ID.
ajtulloch 12y ago
This is an example of a 'phantom type'. See http://www.haskell.org/haskellwiki/Phantom_type http://www.haskell.org/haskellwiki/Phantom_type (and references therein) for an explanation (including a motivation) of this technique.

orangeduck 12y ago

I think this demonstraights a real weakness of Haskell. Several times I've started a new project only to spend several hours trying to work out the correct way to structure what I want. Often it is hours before I even get my first successful compile. This is exactly as shown in this blog post. While some people enjoy this kind of tinkering, for me this really quickly saps all my motivation for the task. I just want to get something, anything, working. I work best jumping directly into a task and understanding it from the inside out, learning from my mistakes. Sometimes if I do find a quick and dirty way to get something working in Haskell - often refactoring it also becomes pretty difficult - which turns me off again. Neither of these are problems I have in other languages. Arguments for which approach is better aside, it is no wonder lots of people who learn and approach tasks like me, feel a little betrayed by Haskell. I've used it for a bunch of things, I'm past the steep learning curve - but it seems I'm still not reaping the rewards. Is my philosophy of jumping into projects really so bad? Is it Haskell's place to question such an approach, when it has served me so well elsewhere?

reikonomusha 12y ago
I agree. Haskell enforces a programmer to create structure. There's no way around it. And it's (nearly) impossible to hack things together without failing early and often. As a result, before the problem you're trying to solve can be explored, you're stuck making guesses on how the problem should even be structured. You spend a few hours with one guess, it turns out to not get your far, and you try another. The unfortunate part is that these guesses aren't letting you get to the meat of the problem effectively; you're stuck trying to solve a meta-problem. Of course, once you have solved the meta-problem well enough, you can start exploring your problem. Unfortunately, you may find that your meta-solution doesn't actually let you answer questions you didn't know you wanted to answer from the get-go, and now you're back to square-one. When everything is right, the program is usually very beautiful, safe, and—if you're skilled enough—efficient. Perhaps not all Haskell programmers have this issue for very non-trivial programs, though I certainly do.
- lclarkmichalek 12y ago
  I don't really agree. The greatest structure in most of my Haskell programs is some kind of ErrorT or something. That requires me to structure the way I handle IO and the way that Errorable things happen, but beyond that, `a` is just as generic as any Python type. Sure, a lot of libraries do require you to accept certain premises, which may be a problem, but most of them provide ways to break out of their abstractions: ErrorT provides `runErrorT :: (Monad m, Error e) => ErrorT e m a -> m (Either e a)` which allows me to break out very easily, and due to the composable nature of Haskell, even if the library does not provide a function, it is often far from hard to write one yourself.
- tinco 12y ago
  I agree that Haskell forces the programmer to create structure, but I don't agree with your meta-problem hypothesis. I think the structure actually is a big part of the real problem, and Haskell just prevents you from implementing incomplete or incorrect solutions. Those solutions might in another language require a hack or leaky abstractions to work, if they would be possible to get to work at all. I've walked into problems like the OP has before with Haskell, and when there seems to be no nice way of defining a type structure to model the problem, it usually meant that the idea in my head had a fundamental problem. If I look at this tree I get the feeling that perhaps he just has two problems, and he's looking at it like he's got only one. And once you do get your type structure neatly in place, often times the implementation will just flow out of your fingertips. And when it does, it will be powerful, flexible and robust.

hawkharris 12y ago

A very small tip for people learning Haskell (coming from a fellow newcomer to the language): as you read the code, mentally replace "::" with "has type of."

joereggan190 12y ago

http://learn.hightail.com/t5/Ideas/Watch-2014-FIFA-World-Cup-Argentina-vs-Brazil-Live-Stream-Online/idi-p/86912 http://learn.hightail.com/t5/Ideas/Watch-2014-FIFA-World-Cup...

wyager 12y ago

This is the "problem" with haskell. It makes you have a reasonably good model before you can even codify it. You have to front-load all the whiteboarding. Everything is easier (and usually bug-free) after that. There have been many times where my inability to codify a mental model in haskell made me realize why that mental model was inherently wrong/unsafe.

lobster_johnson 12y ago

Lots of good discussion in this thread -- but no suggestions relevant to the author's problem. Is there a better solution?