4 ms·

The real amazing part of Seaside is how is uses continuations to turn the http request/response cycle inside-out. HAML doesn't appear to do anything like that,

The real amazing part of Seaside is how is uses continuations to turn the http request/response cycle inside-out. HAML doesn't appear to do anything like that, so comparing it to Seaside seems misguided.

giles_bowkett 18y ago
is it really? have you built anything in seaside?
- jstraszheim 18y ago
  Nothing big. I've played around with it.
- astrec 18y ago
  didn't i see a see a screen grab of news.yc redirected to localhost on your box? off the wagon? ;)
dfox 18y ago
Continuation magic of this kind is interesting and useful but only when you don't want to use anything outside the Smalltalk VM (for example some database), when you start to communicate with something external to VM you have only moved problem to different place and probably made it harder to solve. There is reason why call/cc is sometimes called "functional goto". But apart from continuations seaside also provides system to abstract out HTML generation, that not only changes syntax of HTML but also has support for building page from tree of prepared components (like you would construct desktop application). And this HAML thing only seems to change syntax of HTML and not add any similar capability, so comparing it to Seaside probably is misguided.
hboon 18y ago
Doesn't look like HAML is as readable as Seaside HTML building, maybe it just takes getting used to. The beauty of Seaside is now less in continuations, but more of reusable code and components. (I have always used and read the term reusable as within a project, not necessary as libraries).
jon_dahl 18y ago
I'm pretty sure the article was just trying to compare HAML to a small part of Seaside. ("Seaside packs a lot of ideas into one framework. One innovation [ed. not The primary innovation]: you don't write HTML.") I think the real point wasn't even that Seaside's HTML generation is smart/powerful/fun. It's this: I enjoy programming in Seaside because when I'm programming in Seaside, I'm programming. I'm not wrestling with markup; that's for computers to do. I get the same pleasure out of using HAML.
- jamesbritt 18y ago
  " I'm programming. I'm not wrestling with markup; that's for computers to do. I get the same pleasure out of using HAML." Anecdotal counterpoint: I'm one of those who has the opposite experience with Haml. It's a constant fight. OTOH, XML/HTML is stupid easy; my editor takes care of the annoying parts, and I never fight with cryptic errors. It's easy to cut-n-paste for assorted sources, and use WYSIWYG editors if and when I want to. I think I could live with Haml (I'm sort of compelled to deal with it since I took over an abandoned Rails project) if it did not use significant indentation. It works ok for small chunks of text, utter pain when there's much nesting going on. The application of the description "terse" is quite on the money. It's not a feature.
- mattmcknight 18y ago
  It's worse than using Builder for XML templates. Builder rocks- it is much more concise and comprehensible. http://builder.rubyforge.org/ http://builder.rubyforge.org/ xml.form { xml.label "zipcode" xml.input :type => 'text', :name => "zipcode' xml.input :type => 'submit' }

giles_bowkett 18y ago

is it really? have you built anything in seaside?

jstraszheim 18y ago
Nothing big. I've played around with it.
astrec 18y ago
didn't i see a see a screen grab of news.yc redirected to localhost on your box? off the wagon? ;)

dfox 18y ago

Continuation magic of this kind is interesting and useful but only when you don't want to use anything outside the Smalltalk VM (for example some database), when you start to communicate with something external to VM you have only moved problem to different place and probably made it harder to solve. There is reason why call/cc is sometimes called "functional goto". But apart from continuations seaside also provides system to abstract out HTML generation, that not only changes syntax of HTML but also has support for building page from tree of prepared components (like you would construct desktop application). And this HAML thing only seems to change syntax of HTML and not add any similar capability, so comparing it to Seaside probably is misguided.

hboon 18y ago

Doesn't look like HAML is as readable as Seaside HTML building, maybe it just takes getting used to. The beauty of Seaside is now less in continuations, but more of reusable code and components. (I have always used and read the term reusable as within a project, not necessary as libraries).

jon_dahl 18y ago

I'm pretty sure the article was just trying to compare HAML to a small part of Seaside. ("Seaside packs a lot of ideas into one framework. One innovation [ed. not The primary innovation]: you don't write HTML.") I think the real point wasn't even that Seaside's HTML generation is smart/powerful/fun. It's this: I enjoy programming in Seaside because when I'm programming in Seaside, I'm programming. I'm not wrestling with markup; that's for computers to do. I get the same pleasure out of using HAML.

jamesbritt 18y ago
" I'm programming. I'm not wrestling with markup; that's for computers to do. I get the same pleasure out of using HAML." Anecdotal counterpoint: I'm one of those who has the opposite experience with Haml. It's a constant fight. OTOH, XML/HTML is stupid easy; my editor takes care of the annoying parts, and I never fight with cryptic errors. It's easy to cut-n-paste for assorted sources, and use WYSIWYG editors if and when I want to. I think I could live with Haml (I'm sort of compelled to deal with it since I took over an abandoned Rails project) if it did not use significant indentation. It works ok for small chunks of text, utter pain when there's much nesting going on. The application of the description "terse" is quite on the money. It's not a feature.
mattmcknight 18y ago
It's worse than using Builder for XML templates. Builder rocks- it is much more concise and comprehensible. http://builder.rubyforge.org/ http://builder.rubyforge.org/ xml.form { xml.label "zipcode" xml.input :type => 'text', :name => "zipcode' xml.input :type => 'submit' }