

A simple image hosting site written in Haskell - ostochast
http://bitbucket.org/ostochast/imgcons

======
djacobs
The next language on my "Languages to learn" list is Haskell. I'm a big
Clojure & Lisp fan, and Haskell seems like it would be an amazing study in
contrast with the Lisp family I'm thrilled by.

However, this makes me cringe a little:

    
    
      +++ thediv ! [identifier "gallery"] 
          << (thediv ! [theclass "screenshots"]
          << ulist << 
             (li << anchor ! [href ("view.fcgi?file=" ++ first)]
    

As far as I know, Haskell doesn't a code-as-data philosophy. (Right?) I think
that there are a lot of pure Lisp HTML alternatives, and they work because
Lisp is at the same time declarative and functional. S-expressions are concise
and almost look like CSS. But Haskell code doesn't seem like such a great
replacement. There's too much syntax, and, in my opinion, that gets in the way
of understanding-at-a-glance.

Is this style common in Haskell Web development?

~~~
jmillikin

      > Is this style common in Haskell Web development?
    

Not at all; the author is quite obviously inexperienced in using Haskell, and
is using some weird old crufty library to create HTML.

The two most common template libraries are Heist[1] and Hamlet[2]. Heist uses
Rails/Django-style external template files, while Hamlet embeds markup
directly into the Haskell source code using quasiquotation.

[1] <http://snapframework.com/docs/tutorials/heist>

[2] <http://www.yesodweb.com/book/templates>

Even if one wanted to represent markup as Haskell types, there's no reason it
needs to be as ugly as in that example. A really basic version might be:

    
    
      div [("id", "gallery")] $ do
        div [("class", "screenshots")] mzero
        ul [] $ do
          li [] $ do
            a [("href", "view.fcgi?file=" ++ first)] mzero

~~~
lobster_johnson
Anything like HAML for Haskell? I looked at the tutorials you linked to, and
Heist and Hamlet looks like very poor substitutes. Hamlet seems inspired by
HAML, but they seemed to have missed the point.

Here's the equivalent HAML:

    
    
        #gallery
          .screenshots
          ul
            li
              a{"href" => "view.fcgi?file=#{first}"}
    

HAML is super clean, and there's essentially no redundant syntax; in other
words, if you type something, it's because it's necessary. There's no fat.

~~~
barkmadley
actually the attribute syntax leaves a lot to be desired in terms of
redundancy. First you have to quote the attributes (or put a : in front of
them?), yuck. you need to use the => operator which is two times too big, and
whats with the unnecessary outer braces?

non-idiomatic hamlet isn't far from that haml snippet (note you would never
put bits of urls in the template as strings, instead you provide a url
rendering function which converts the @{} bits into url strings):

    
    
        <#gallery
          <.screenshots
          <ul
            <li
              <a href=@{View first}
    

idiomatic hamlet is much more focused on being a cleaner html for designers
than it is trying to be a haml clone.

~~~
lobster_johnson
> actually the attribute syntax leaves a lot to be desired in terms of
> redundancy.

I agree. Considering that you can assign 'id' and 'class' through the main
syntax, I don't think it's too bad. Attribute values are Ruby strings, so the
quotes work for me. With Ruby 1.9 you should, in theory, be able to use the
new improved hash syntax:

    
    
        a{href: "/ding"}
    

...but I don't know if HAML has implemented it.

Edit: HAML actually supports a different, simpler syntax for attributes:

    
    
        %a(href="/ding")
    

> idiomatic hamlet is much more focused on being a cleaner html for designers
> than it is trying to be a haml clone.

I know that some companies work that way. We let our designers learn HAML (and
SASS) instead. That way they can contribute to the projects as first-class
citizens. HAML is simple enough that a designer can even work with
conditionals and loops.

------
Peaker
myfromJust has a too specific type, and really should just be inlined as:

    
    
      fromMaybe ""
    

checkInputFile encodes a no-result as a "no" string. This is a very un-
Haskelly thing to do (Use a Maybe String, instead).

Use of C's if syntax is a bit weird, too. No need for these extra parens.

getRandomName weirdly uses getStdGen/newStdGen instead of just making a random
generator directly.

basename is (incorrectly) duplicating standard library behavior.

saveFile uses fromJust, will crash at runtime.

