5 ms·

Simply Lift

35 points by fogus 15y ago

xutopia 15y ago
Why are there more comments than code in the source? Is this usual to Scala?
- jimmyjazz14 15y ago
  Scala code is more verbose than Haskell or Scheme but its still pretty terse for many things, so you tend to get much more done with much less code (especially if you compare it to Java).
  - eru 15y ago
    For comparision: Read Knuth's version of the Colossal Cave adventure, if you want to see a well documented C program. http://www.literateprogramming.com/adventure.pdf http://www.literateprogramming.com/adventure.pdf
- snprbob86 15y ago
  I think that this is common to any expressive language in a business setting. Small, expressive code is easier to read/write/maintain for the person who originally created it, as it matches their brain and way of thinking. However, once you encounter an ever-changing set of people who may want to consume or modify your code, you need to give people a look into how your mind works. Narratives are often much longer than normal quick remarks in comments. Furthermore, this source is intended for educating :-)
- Xavi 15y ago
  Presumably the code snippets are meant for beginners who need/appreciate more verbose comments.
IgorPartola 15y ago
> Further, this book will not explore persistence. To me this is one of the more important parts of a web framework. Otherwise, they all provide similar features for organizing code: you link some sort of a "view" to some sort of a URL. They may add a template language, or an admin system or a caching framework. They may be event-loop based, or process based or thread based or some mixture of all of the above, but if you have no state, your code will look awesome in all of them. The big issue is "how do you deal with state?"
- igorgue 15y ago
  Maybe using Rouge? http://engineering.foursquare.com/2011/01/21/rogue-a-type-safe-scala-dsl-for-querying-mongodb/ http://engineering.foursquare.com/2011/01/21/rogue-a-type-sa... Persistence IMHO doesn't have to be a very important feature in a framework, since a good one should be able to be pluggable. I use Django, but in some projects I don't use their ORM (or any ORM).
- dkarl 15y ago
  Why should a web framework be tied to a persistence framework? Serious question.
  - jshen 15y ago
    I don't think it should be tied to a specific one, but it should have an api/adapter. Rails 3 is a good example of how I think it should be done. One advantage, I get form helpers that automatically know how to deal with models, display errors, etc.
- squidsoup 15y ago
  Lift actually provides two ORMs, Mapper and Record with support for JPA.
- aaronblohowiak 15y ago
  Your view is not a simple string template in Lift. In most frameworks, you handle the controller first, gather all your data and pass it to a string template. In Lift, the View is parsed and then all (there are frequently many) of the required "controllers" are invoked to fulfill the view. This is somewhat, kind-of, almost like custom tags in JSP, but about a thousand times keener, because it is all parallelized and so forth. Because of this, Lift can do things like trivially bind html to changing Actors (in the erlang sense) so that when the Actor changes, the html changes in all the browsers that viewed it. Supporting this all is non-trivial. "Persistence" usually boils down to serialize, deserialize and transactions... which are ultimately not unique to Lift, so I don't see a huge need to focus on it.
jorangreef 15y ago
I spent a few minutes trying to figure out what Lift is but didn't get enough information scent from the introduction to persevere. I did pick up that Lift is not too interested in solving any persistence problems. For what I'm working on (multiplayer, offline/online web application) persistence has taken the most work to get right. It has to be done at the framework level. An offline web app has to deal with synchronization (backporting of data, client-side data loss or corruption, client-side clock issues, GBs of data per user, multiple users sharing the same data), client-side and server-side migrations (code, data, schema), browser-side database (indexing, memory usage) etc. Partition-tolerant persistence is almost exactly what I'd want a web app framework (as opposed to web site framework) to be tackling. I'm not aware of any frameworks (including Backbone, Lift, Rails etc.) that do.
- jonprins 15y ago
  Lift does do a lot of persistence, it just seems that this intro didn't touch on it much: http://www.assembla.com/spaces/liftweb/wiki/Mapper http://www.assembla.com/spaces/liftweb/wiki/Mapper http://www.assembla.com/spaces/liftweb/wiki/Persistence_Alternatives http://www.assembla.com/spaces/liftweb/wiki/Persistence_Alte...
PaulHoule 15y ago
It looks like less than half of the tutorial is written, it's mostly an outline. I saw something about guids halfway through the article which scares the pants off of me. Guids are a major part of the evil of Windows programming; the proliferation of opaque identifiers makes it hard to understand what you're looking at. Worse than that, some programmers are tempted to make up their own guids rather than making them the way you're supposed to make them... I eventually quit working at a place where there was this old guy who'd start screaming and turn red because I told him that var guid=new Guid("0000-..."); was't a guid because it wasn't globally unique. Guids certainly have a place in distributed systems, but oversized keys can really destroy the performance of a database, quite literally by a factor of 5 or more. They're great for hardware vendors that want to sell you an oversized machine, great for expensive enterprise apps and clunky intranets where you can complain about a page taking 20 seconds to load but but nobody listens, but not acceptable for internet apps that have to compete for time and attention.
- aaronblohowiak 15y ago
  UUIDs have great characteristics as well: they don't leak information about the size of your data (or the rate it changes,) they are easily masked, you can have clients generate stable ids (which you hint at in distributed systems.) The db performance degradations you mention are highly implementation-dependent.
- sross 15y ago
  It's also worth noting that GUIDs in this case have nothing to do with persistence but rather with associating urls with behaviour in much the same way as the fnids you'll see on various urls (like flag) on hacker news.

Simply Lift

35 points by fogus 15y ago

xutopia 15y ago

Why are there more comments than code in the source? Is this usual to Scala?

jimmyjazz14 15y ago
Scala code is more verbose than Haskell or Scheme but its still pretty terse for many things, so you tend to get much more done with much less code (especially if you compare it to Java).
- eru 15y ago
  For comparision: Read Knuth's version of the Colossal Cave adventure, if you want to see a well documented C program. http://www.literateprogramming.com/adventure.pdf http://www.literateprogramming.com/adventure.pdf
snprbob86 15y ago
I think that this is common to any expressive language in a business setting. Small, expressive code is easier to read/write/maintain for the person who originally created it, as it matches their brain and way of thinking. However, once you encounter an ever-changing set of people who may want to consume or modify your code, you need to give people a look into how your mind works. Narratives are often much longer than normal quick remarks in comments. Furthermore, this source is intended for educating :-)
Xavi 15y ago
Presumably the code snippets are meant for beginners who need/appreciate more verbose comments.

IgorPartola 15y ago

> Further, this book will not explore persistence. To me this is one of the more important parts of a web framework. Otherwise, they all provide similar features for organizing code: you link some sort of a "view" to some sort of a URL. They may add a template language, or an admin system or a caching framework. They may be event-loop based, or process based or thread based or some mixture of all of the above, but if you have no state, your code will look awesome in all of them. The big issue is "how do you deal with state?"

igorgue 15y ago
Maybe using Rouge? http://engineering.foursquare.com/2011/01/21/rogue-a-type-safe-scala-dsl-for-querying-mongodb/ http://engineering.foursquare.com/2011/01/21/rogue-a-type-sa... Persistence IMHO doesn't have to be a very important feature in a framework, since a good one should be able to be pluggable. I use Django, but in some projects I don't use their ORM (or any ORM).
dkarl 15y ago
Why should a web framework be tied to a persistence framework? Serious question.
- jshen 15y ago
  I don't think it should be tied to a specific one, but it should have an api/adapter. Rails 3 is a good example of how I think it should be done. One advantage, I get form helpers that automatically know how to deal with models, display errors, etc.
squidsoup 15y ago
Lift actually provides two ORMs, Mapper and Record with support for JPA.
aaronblohowiak 15y ago
Your view is not a simple string template in Lift. In most frameworks, you handle the controller first, gather all your data and pass it to a string template. In Lift, the View is parsed and then all (there are frequently many) of the required "controllers" are invoked to fulfill the view. This is somewhat, kind-of, almost like custom tags in JSP, but about a thousand times keener, because it is all parallelized and so forth. Because of this, Lift can do things like trivially bind html to changing Actors (in the erlang sense) so that when the Actor changes, the html changes in all the browsers that viewed it. Supporting this all is non-trivial. "Persistence" usually boils down to serialize, deserialize and transactions... which are ultimately not unique to Lift, so I don't see a huge need to focus on it.

jorangreef 15y ago

I spent a few minutes trying to figure out what Lift is but didn't get enough information scent from the introduction to persevere. I did pick up that Lift is not too interested in solving any persistence problems. For what I'm working on (multiplayer, offline/online web application) persistence has taken the most work to get right. It has to be done at the framework level. An offline web app has to deal with synchronization (backporting of data, client-side data loss or corruption, client-side clock issues, GBs of data per user, multiple users sharing the same data), client-side and server-side migrations (code, data, schema), browser-side database (indexing, memory usage) etc. Partition-tolerant persistence is almost exactly what I'd want a web app framework (as opposed to web site framework) to be tackling. I'm not aware of any frameworks (including Backbone, Lift, Rails etc.) that do.

jonprins 15y ago
Lift does do a lot of persistence, it just seems that this intro didn't touch on it much: http://www.assembla.com/spaces/liftweb/wiki/Mapper http://www.assembla.com/spaces/liftweb/wiki/Mapper http://www.assembla.com/spaces/liftweb/wiki/Persistence_Alternatives http://www.assembla.com/spaces/liftweb/wiki/Persistence_Alte...

PaulHoule 15y ago

It looks like less than half of the tutorial is written, it's mostly an outline. I saw something about guids halfway through the article which scares the pants off of me. Guids are a major part of the evil of Windows programming; the proliferation of opaque identifiers makes it hard to understand what you're looking at. Worse than that, some programmers are tempted to make up their own guids rather than making them the way you're supposed to make them... I eventually quit working at a place where there was this old guy who'd start screaming and turn red because I told him that var guid=new Guid("0000-..."); was't a guid because it wasn't globally unique. Guids certainly have a place in distributed systems, but oversized keys can really destroy the performance of a database, quite literally by a factor of 5 or more. They're great for hardware vendors that want to sell you an oversized machine, great for expensive enterprise apps and clunky intranets where you can complain about a page taking 20 seconds to load but but nobody listens, but not acceptable for internet apps that have to compete for time and attention.

aaronblohowiak 15y ago
UUIDs have great characteristics as well: they don't leak information about the size of your data (or the rate it changes,) they are easily masked, you can have clients generate stable ids (which you hint at in distributed systems.) The db performance degradations you mention are highly implementation-dependent.
sross 15y ago
It's also worth noting that GUIDs in this case have nothing to do with persistence but rather with associating urls with behaviour in much the same way as the fnids you'll see on various urls (like flag) on hacker news.