3 ms·

It seems like snap is headed in the yesod direction. By that I mean the "faithfully replicate the mistakes of php/mysql worst practices as interpreted by rails

It seems like snap is headed in the yesod direction. By that I mean the "faithfully replicate the mistakes of php/mysql worst practices as interpreted by rails", not the "conflate type safety with DSLs". Happstack doesn't appear to be overly damaged by phpisms, but happstack-foundation isn't useful for a lot of people because it uses acid-state for storage. Also, HSP is terrible and using it should be a criminal offence. So you basically have to build your own collection of stuff as you go on top of snap or happstack-server and the various glue packages for happstack. I don't buy the "but the compiler is working hard" excuses for ghc's horrible performance. Ocaml is a similar language, and it compiles similar projects in 1/10th the time, and in 1/20th the RAM. It is a huge issue on large projects, waiting 30 seconds for a single line change to compile is brutal, and that 30 seconds ends up being 5 minutes because you get distracted while waiting.

mightybyte 13y ago
> faithfully replicate the mistakes of php/mysql worst practices as interpreted by rails I assume you're talking about things like snap-extras and restful-snap. Those libraries are not a part of the Snap Framework. They are simply libraries that I and my coworkers are using to help us ship apps more quickly. We put them on hackage because we thought others might be able to benefit from them. They are still very young and it is uncertain what direction they will finally take. The core framework still consists of just snap-core, snap-server, heist, and snap. If you as a Snap user still think this is a sign that the framework is going in the wrong direction, we'd love to get your input and involvement.
- chrisdone 13y ago
  There's also snap-app http://hackage.haskell.org/package/snap-app http://hackage.haskell.org/package/snap-app which I'm using on hpaste, ircbrowse and haskellnews =p Which sort of backs up his point about making your own utility libraries on top of snap. Although this was implemented for hpaste years ago before snap got all that weird snaplet lens stuff, and I copy-pasted it for ircbrowse and ended up librifying it so I could cabal install it on my different projects.
nightski 13y ago
OCaml is not similar at all. OCaml for better or worse is much closer to compiled form than Haskell code. Haskell requires much more analysis and transformation than OCaml during compilation in order to achieve the performance of GHC compiled code.
- papsosouid 13y ago
  You are going to have to be detailed and specific if you want that statement to be taken seriously. Ocaml is very obviously quite similar to haskell. What specifically is so much more work about compiling haskell? And why does only GHC suffer from this extra work while other compilers were able to compile haskell code in reasonable time and space?
  - mightybyte 13y ago
    Laziness, purity, and graph reduction--i.e. it's a completely different execution model. Funny how you demand specifics here, but "faithfully replicate the mistakes of php/mysql worst practices as interpreted by rails" is left oh so vague.
    - papsosouid 13y ago
      How is laziness making ghc slow? Completely strict code doesn't compile any faster, and writing completely lazy ocaml code doesn't compile any slower. How would purity make compilation slower? I want specifics here because it is a specific, factual claim. My opinion on frameworks was left somewhat vague as it is simply my opinion and I had no reason to think anyone wanted more specifics on it. I'm happy to be more specific if you like, what did you want to know?
      - mightybyte 13y ago
        See chrisdone's comment above. For more details on how GHC began life, check out SPJ's book: http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/ http://research.microsoft.com/en-us/um/people/simonpj/papers... You might also take a look at GRIN. Here's a quote from the GRIN paper: "For a lazy language like Haskell, compilers typically compile one module at a time. At first sight, this might appear as a good opportunity to optimize several procedures at once. However, it seems as if this does not apply very well to low level optimizations, like those presented in this paper, where the actual dynamic control flow is important... In a lazy language, a function that is local to a module in the source code might very well escape from the module at run time (if it is built into a closure) and then be called from somewhere else." I'm very interested in your thoughts on frameworks, but this isn't really the right forum. It's usually pretty easy to catch me in #snapframework on IRC.
dustingetz 13y ago
"faithfully replicate the mistakes of php/mysql worst practices as interpreted by rails" can you recommend any reading that spells out these worst practices?
- papsosouid 13y ago
  Unfortunately, I don't know of anything. http://database-programmer.blogspot.ca/ http://database-programmer.blogspot.ca/ is good for learning about how to use a database as a database instead of a persistent hash table, but it doesn't really address the why of it so much.

mightybyte 13y ago

> faithfully replicate the mistakes of php/mysql worst practices as interpreted by rails I assume you're talking about things like snap-extras and restful-snap. Those libraries are not a part of the Snap Framework. They are simply libraries that I and my coworkers are using to help us ship apps more quickly. We put them on hackage because we thought others might be able to benefit from them. They are still very young and it is uncertain what direction they will finally take. The core framework still consists of just snap-core, snap-server, heist, and snap. If you as a Snap user still think this is a sign that the framework is going in the wrong direction, we'd love to get your input and involvement.

chrisdone 13y ago
There's also snap-app http://hackage.haskell.org/package/snap-app http://hackage.haskell.org/package/snap-app which I'm using on hpaste, ircbrowse and haskellnews =p Which sort of backs up his point about making your own utility libraries on top of snap. Although this was implemented for hpaste years ago before snap got all that weird snaplet lens stuff, and I copy-pasted it for ircbrowse and ended up librifying it so I could cabal install it on my different projects.

nightski 13y ago

OCaml is not similar at all. OCaml for better or worse is much closer to compiled form than Haskell code. Haskell requires much more analysis and transformation than OCaml during compilation in order to achieve the performance of GHC compiled code.

papsosouid 13y ago
You are going to have to be detailed and specific if you want that statement to be taken seriously. Ocaml is very obviously quite similar to haskell. What specifically is so much more work about compiling haskell? And why does only GHC suffer from this extra work while other compilers were able to compile haskell code in reasonable time and space?
- mightybyte 13y ago
  Laziness, purity, and graph reduction--i.e. it's a completely different execution model. Funny how you demand specifics here, but "faithfully replicate the mistakes of php/mysql worst practices as interpreted by rails" is left oh so vague.
  - papsosouid 13y ago
    How is laziness making ghc slow? Completely strict code doesn't compile any faster, and writing completely lazy ocaml code doesn't compile any slower. How would purity make compilation slower? I want specifics here because it is a specific, factual claim. My opinion on frameworks was left somewhat vague as it is simply my opinion and I had no reason to think anyone wanted more specifics on it. I'm happy to be more specific if you like, what did you want to know?
    - mightybyte 13y ago
      See chrisdone's comment above. For more details on how GHC began life, check out SPJ's book: http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/ http://research.microsoft.com/en-us/um/people/simonpj/papers... You might also take a look at GRIN. Here's a quote from the GRIN paper: "For a lazy language like Haskell, compilers typically compile one module at a time. At first sight, this might appear as a good opportunity to optimize several procedures at once. However, it seems as if this does not apply very well to low level optimizations, like those presented in this paper, where the actual dynamic control flow is important... In a lazy language, a function that is local to a module in the source code might very well escape from the module at run time (if it is built into a closure) and then be called from somewhere else." I'm very interested in your thoughts on frameworks, but this isn't really the right forum. It's usually pretty easy to catch me in #snapframework on IRC.

dustingetz 13y ago

"faithfully replicate the mistakes of php/mysql worst practices as interpreted by rails" can you recommend any reading that spells out these worst practices?

papsosouid 13y ago
Unfortunately, I don't know of anything. http://database-programmer.blogspot.ca/ http://database-programmer.blogspot.ca/ is good for learning about how to use a database as a database instead of a persistent hash table, but it doesn't really address the why of it so much.