On Mar 6, 9:35 am, David Pollak <feeder.of.the.be...@gmail.com> wrote: > Back when I was doing Rails, the state of Rails' documentation was not > materially different from the current state of Lift's documentation with the > exception of DHH's awesome book (which is my all time favorite tech book). > Most of the online documentation was weak or non-existent.
This is true, but *getting started* was extremely easy. A few very non- intimidating commands and you were up & running and making quick edits that appeared in real time. Once you started to dig a little deeper you ran into the problems you describe but by that point the fish was already on the hook. > This is one of the things I wanted to do differently with Lift. I didn't > want to "market" it. I wanted to build solid technology that addressed > serious needs including security, highly interactive apps, and scalability. I started working with Lisp & other functional languages about 10 years ago and it's been frustrating to watch inferior languages like Ruby and Python sail past them in popularity over that time. I think a lot of this has to do with a naivety in the functional programming community that solving the "hard" problems is what matters and that people will naturally & logically adopt tools that do this. Unfortunately, it appears that the opposite is much more often then case and that people choose easy & fashionable first. Essentially it's worse is better all over again: http://www.jwz.org/doc/worse-is-better.html Maybe by the time you've taken that simple Rails site and make it secure, stable and scalable you've worked a lot harder than you would have had to if you started in Lift, but I suspect a lot of people aren't going to be enticed enough by the initial experience to find this out. > One of the problems I found with new Rails apps was that they were ugly and > unstyled. We adopted Blueprint CSS as a default for Lift projects so at > least they looked clean. I agree with this. The out-of-the-box site you get with Lift is pretty nice once you get it running. > While I'm not sure I 100% agree with Tim's "6 million dollar man" argument > about PDF, PDF is common and useful... Scribd (which is definitely in the > hip-cool-kids side of street) is built on PDF. PDF is great if you're making an ebook. It loses on every other score. I have to download it each time it's updated. I can't link into it from other sites. Copying and pasting code from PDF is problematic. It's a pain on a lot of mobile platforms. I and every other hacker I know groans when we see a link to Scribd. > Okay... sorry... but this is a gratuitous swipe. Ugly == Not Easy to Use. > Nope. Sorry. I don't buy this. It's because of this - it suggests that the people behind the docs don't have either the time or the inclination to attend to the little details, which implies that other details might also be overlooked. If making attractive & easy to read introductory materials isn't a priority for the developers, maybe they also don't care about making the rest of the experience pleasant. > We are not in the build tool business. When we started with Lift, the > options were Ant and Maven. You can read this list for the occasional > anti-Maven flare-up. I stand by the decision. Maybe it is the best option now. I've been out of the Java world too long to know. From what I've seen of sbt it looks like an improvement so I'm glad to hear you're planning to adopt it later. > The second point is dead wrong. Every Rails job I worked on required > tremendous configuration pain. On my most recent Rails-related job (this > was 18 months ago), I spent a day configuring my machine with the right Gems > and the right versions of the right Gems. I haven't found this to be the case at all. I build a new ruby into a separate install prefix and gem install rails and I'm ready to go. I certainly don't have to deal with anything approaching the complexity and inscrutability of a 152 line pom.xml. > Actually, most new sites I come across are XHTML 1.1. With the actual doctype declared? With all the content that gets inserted/slurped into pages from all kinds of sources I've only ever seen this as an extra source of non-wellformed fragility. > So, for prototypes, put your HTML literals in your code. When the team is > big enough to divide the work, go through and pull out the literals into > template files. Yeah, this violates a little of the "a prototype is > shippable" that I was talking about above, but you can also start with "best > practices" in terms of the templating. I think you should make this case a little more explicitly in the docs. > I do 50% of my coding with Emacs and my fingers do the right thing. Those > using TextMate or an IDE don't worry at all. I already hate having to navigate 3 directory levels in rails, even with ido mode. Three *more* tabs to each file doesn't sound like fun. > Yeah. Scala is statically typed. The model defines the schema. You're > complaining about adding a few characters to a file to identify a model/DB > table that's in active use. So, but this is not a legitimate complaint. >From somebody that's used to just dropping a file in app/models and having everything work it's very much a legitimate complaint. The biggest questions a Rails/Django coder coming to Lift is going to have is this - "How much extra work am I going to have to do to keep the compiler happy in order to reap the benefits of static typing?" In this particular case it sounds like pure housekeeping. > > We work through the next few instructions to come to the creation of > > TD.scala only to be greeted by a *19* line file header: > > If you've got a better way to do it, let me know. I've been asking the > Scala folks for a unified import facility for 3+ years. In Scala 2.8, there > are package objects that will mitigate some of the import pain. I'm way too much of a Scala noob to have any concrete suggestions to make but this is definitely one area where the Scala implementors could help out what appears to currently be one of their flagship success projects. Anyway, thanks for taking the time to consider my post and respond in detail. I think for now & I'm going to adopt a wait & see approach but I do want to thank you for all the work you've put into Lift. I'd really like to see a serious functional web platform take off. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
