4 ms·

I've been learning Haskell on the side for a while and was hoping for something more after reading the title, but the post pretty much just points out a few pre

by danneu 15y ago

I've been learning Haskell on the side for a while and was hoping for something more after reading the title, but the post pretty much just points out a few preferences that OP has. I spend very little time in Rails hung up on any of the issues expressed. With some experience with frameworks like Express/Noir/Sinatra, I find that Rails is productive for me because of (A) convention and (B) getting common things done with terse code like `belongs_to :forum, counter_cache: true, touch: true`, and (C) not having to write glue code for basic things. This quote... > In addition, there is also very little “convention” with Snap. It enforces nothing, which has the consequence (in addition to allowing you to make a mess!) of having the whole application conforming to exactly how you think it should be organized. ...is precisely the deal breaker for me. If OP thinks it's hard to add/edit Rails code because it's spread out, then a lack of convention suddenly isn't a very compelling scenario for productivity. At least you know where to look. I've been in a Node.js kick recently, consuming a lot of Express-stack repos on Github of smart people, and the experience is baffling. Deciding where to put code in my application just isn't a problem I want to solve when I'm trying to write a non-trivial, non-single-paged application.

deleted 15y ago
[deleted]
carterschonwald 15y ago
I'm slightly confused by this. Is it not the case with rails that many of the .rb files are generated via rails? I think you're over thinking / pessimizing what happens with haskell code. 1) for any self contained project (library or executable) in haskell, the directory structure determines the module names. if you're wondering how the functions imported from the Foo.Bar module are implemented you simply go to the subdir #root/Foo/Bar.hs 2) Types. when you're writing use case specific code, you are going to define use case specific types, and they will be declared. More over, it is good practice to give explicit type ascriptions to haskell code to make sure that it does in fact have the type you expect. This means that you can jump into a module and by also recursively looking at its imports (and you know where those are in the fs), you can figure out exactly whats going on. 3) cabal-install (cabal), and your project specific project.cabal file make life great. Why? the foo.cabal file will tell you which module has the Main function if you're making an executable, what other packages (and their versions) your code might be importing, which language extensions are enabled, etc. Point being, there are no need for "framework specific conventions" of the sort you're concerned about because those problems are solved by Haskell specific conventions :)
- regularfry 15y ago
  Firstly: no, it should not be the case that many of the .rb files are generated via rails. Or at least, it shouldn't be. Generators are a crutch. Secondly: the sort of conventions you're talking about in Haskell modules also exist in Ruby. They just aren't enforced by the compiler, and because Rails is an application framework rather than a library, it has its own set of completely different conventions which make sense for application code. This is a double-edged sword. On the one hand you get a convention which makes more sense for the specific type of application Rails assumes you're building; on the other you are encouraged to write code which may end up difficult to extract out of the application you're writing, and may be less well-designed because of it.
- danneu 15y ago
  I mean to specify higher level design conventions, as in the structuring decisions you'd have to make in a non-trivial app. For instance, my experience with Express. The popular Peepcode screencast makes a Django'esque `apps` directory and modularizes the granular components of the entire app. Other people make an `app` directory and model the familiar Rails MVC. Some people contain controller logic in the router. Some people export routes from smaller files into app.js under a `//routes` comment. Sometimes the connection to the database is bootstrapped when the server starts in app.js. Sometimes the database is accessed from each model. Sometimes the database is accessed from each route. And you're guaranteed to have to dig into every required file to see how they exposed its API. Did they module.exports the entire object? Or did they individually export each public method? See, I'm not criticizing unopinionated frameworks. They're for people that are opinionated and want to write the code that glues their opinionated structure together. Or for apps small enough to get by without deliberated structure. But in a discussion about productivity, perhaps there's something to be said when people with experience making non-trivial apps have corroborated conventions and practices for a community to share.
zopa 15y ago
I think you've stated the main Snap vs. Yesod distinction in Haskell-land: "here are some tools" versus "do this." There's advantages to each approach, and luckily there are solid Haskell frameworks for both.
- joeyh 15y ago
  Maybe Sorta. Most of Yesod is also reusable libraries, for example I've used Hamlet to generate HTML without using any of the rest of Yesod.
  - zopa 15y ago
    Sure, but if you want a Preferred Way, like the OC seems to, Yesod's your huckleberry. Right? Or is that not so?
    - mightybyte 15y ago
      That depends on one's definition of Preferred. And there is most definitely not a single one, even within the Haskell community.

by danneu 15y ago

deleted 15y ago

[deleted]

carterschonwald 15y ago

I'm slightly confused by this. Is it not the case with rails that many of the .rb files are generated via rails? I think you're over thinking / pessimizing what happens with haskell code. 1) for any self contained project (library or executable) in haskell, the directory structure determines the module names. if you're wondering how the functions imported from the Foo.Bar module are implemented you simply go to the subdir #root/Foo/Bar.hs 2) Types. when you're writing use case specific code, you are going to define use case specific types, and they will be declared. More over, it is good practice to give explicit type ascriptions to haskell code to make sure that it does in fact have the type you expect. This means that you can jump into a module and by also recursively looking at its imports (and you know where those are in the fs), you can figure out exactly whats going on. 3) cabal-install (cabal), and your project specific project.cabal file make life great. Why? the foo.cabal file will tell you which module has the Main function if you're making an executable, what other packages (and their versions) your code might be importing, which language extensions are enabled, etc. Point being, there are no need for "framework specific conventions" of the sort you're concerned about because those problems are solved by Haskell specific conventions :)

regularfry 15y ago
Firstly: no, it should not be the case that many of the .rb files are generated via rails. Or at least, it shouldn't be. Generators are a crutch. Secondly: the sort of conventions you're talking about in Haskell modules also exist in Ruby. They just aren't enforced by the compiler, and because Rails is an application framework rather than a library, it has its own set of completely different conventions which make sense for application code. This is a double-edged sword. On the one hand you get a convention which makes more sense for the specific type of application Rails assumes you're building; on the other you are encouraged to write code which may end up difficult to extract out of the application you're writing, and may be less well-designed because of it.
danneu 15y ago
I mean to specify higher level design conventions, as in the structuring decisions you'd have to make in a non-trivial app. For instance, my experience with Express. The popular Peepcode screencast makes a Django'esque `apps` directory and modularizes the granular components of the entire app. Other people make an `app` directory and model the familiar Rails MVC. Some people contain controller logic in the router. Some people export routes from smaller files into app.js under a `//routes` comment. Sometimes the connection to the database is bootstrapped when the server starts in app.js. Sometimes the database is accessed from each model. Sometimes the database is accessed from each route. And you're guaranteed to have to dig into every required file to see how they exposed its API. Did they module.exports the entire object? Or did they individually export each public method? See, I'm not criticizing unopinionated frameworks. They're for people that are opinionated and want to write the code that glues their opinionated structure together. Or for apps small enough to get by without deliberated structure. But in a discussion about productivity, perhaps there's something to be said when people with experience making non-trivial apps have corroborated conventions and practices for a community to share.

zopa 15y ago

I think you've stated the main Snap vs. Yesod distinction in Haskell-land: "here are some tools" versus "do this." There's advantages to each approach, and luckily there are solid Haskell frameworks for both.

joeyh 15y ago
Maybe Sorta. Most of Yesod is also reusable libraries, for example I've used Hamlet to generate HTML without using any of the rest of Yesod.
- zopa 15y ago
  Sure, but if you want a Preferred Way, like the OC seems to, Yesod's your huckleberry. Right? Or is that not so?
  - mightybyte 15y ago
    That depends on one's definition of Preferred. And there is most definitely not a single one, even within the Haskell community.