Folks, I'm going to respond to this thread in a single post.
First, let me step back and give a little of my history. I've been writing commercial software for more than 30 years. I've delivered commercial software in BASIC, Pascal, 6502 Assembly Language, 8051 Assembly language, C, Lightspeed C, C++, Objective-C, Perl, Java, C#, VisualBasic, ASP, JSP, Ruby and Scala. I've done commercial projects using a wide variety of web technologies over the years. I've also dabbled in other languages (Smalltalk, Haskell, etc.) I've been writing web frameworks since 1996 and been designing frameworks, scripting languages, and tools for developers since 1977... in fact my first professional gig as an Apple ][ based programming system that allowed FEMA (Federal Emergency Management Agency) program the sequence and timing of video images for automated display during emergencies. I've had a lot of experience building stuff for the consumption of developers... developers from the guys who have written macros and formulas in spreadsheets I've written to people using a visual programming system I built for hand-held computers (this was in 1987) to people writing web applications. I've managed projects from single person up to 30 people (I don't like managing more than 30 people). I've managed projects and coded on projects up to 700,000 lines of Java code. I have worked with teams and advised technical managers with more than 30 people, but it's been a "consigliore" role rather than actual management. I'm also a Duct Tape Coder: http://www.joelonsoftware.com/items/2009/09/23.html I believe that working code that adheres to some basic tenets is a lot more valuable that stuff like CORBA that's over-engineered to death. I started Lift because I wanted a tool to build web *applications *more easily, quickly and maintainably than any of the tools circa 2007 provided. Note the emphasis on applications. Over the years, the (fantastic) folks that have joined the Lift project are oriented towards getting stuff done and oriented towards applications. There are plenty of good *web* frameworks around, but the emphasis of these frameworks is generally wrapping the HTTP and HTML layers of an application rather than Lift's focus on business logic and abstracting away the HTTP request/response cycle. Lift is more of a child of Seaside and Web Objects (no surprise that I'm a former NextStep coder) rather than the MVC frameworks. The Lift committers generally do it for the love of build stuff to make their lives easier, being part of a cool community, and a tad bit of fame (especially for the authors of the Definitive Guide to Lift.) We prioritize code, documentation, refactoring, support, etc. based on our own needs, taking care of the community on this list, closing tickets and our collective sense of what needs to get done (and that collective sense is generally aligned.) So, first a couple of things: - I aspire to make Lift the best way to express business logic in the form of a web based application and Lift's abstractions are oriented toward the business logic pieces while hiding the HTTP plumbing. - Lift is a "best of" framework, so suggesting sticking to one language's naming conventions doesn't make a ton of sense. The Scala coding guidelines document came out of Novell's Pulse project and deserves particular attention, but is not definitive regarding Lift's coding and naming conventions. We will make the best choices and hopefully make them consistent. - Developers are coming to Lift from Java, PHP, Rails and other places. While Scala is a JVM languages, we are not going to cater to a particular crowd (e.g., OO vs. some other paradigm), but rather provide an increasingly excellent set of tools for expressing business logic in the form of a web application. - Oh, and I think that OO is a radically over-hyped concept. Scala's traits come as close as I've seen to OO's promise. But the nominal abstractions and purity that OO is supposed to give us has failed in virtually every case I've seen. Now maybe I'm a moron and always get associated with junk projects... or maybe all those guys with their GoF patterns books arguing endlessly about is-a and has-a and all that stuff rather than writing code are making up for the fact that they can't write code. Sure, the Smalltalk collections classes are very well done... as are the Scala 2.8 libraries... but these libraries require the absolute best computer scientists and engineers that have ever walked to earth to get right. With that (somewhat arrogant) set-up, here's my take on the issues raised on the thread: - "Lift invents new concepts." Yes. If you want a rehash of the same HTTP objectifications, please go use Wicket, Rails or Play. Lift borrows concepts from a variety of other frameworks and invents its own when new ground (like Comet and super-simple Ajax) dictates. - "Lift's documentation sucks." No, it doesn't. You can get 80% of Lift's concepts from the getting started guide or from HarryH's Lift slides. You can get 90%-95% of Lift's concepts from Derek, Marius and Tyler's book (which is available for free in PDF form). Sure, the material may not be presented in the style that's best for your particular learning modes, but it's there. You don't have to know the complete Lift request cycle. I documented it a few years ago and (1) it didn't stop the "how do I do this" questions and (2) people started arguing about it (like the RequestVar vs. PageVar argument on another thread.) It was a near complete waste of my time. If you have a particular goal in your application that's not answered in DGL, post it to this list and we'll help you. But more importantly, Lisp has very few concepts but it takes years to master Lisp. Java has a few more concepts and it takes years to master Java. 80% of Lift's concepts can be learned in a night. It will take years to master them all. Yeah, it'd be nice to have a "Lift Recipes" book, but there's none yet. - "Lift's wiki is out of date." Yeah. Are you volunteering to fix it? There's a tremendous amount of information that's been added to the Lift wiki(s) over the last few years. We had a wiki gardener (Xavi where are you) for a while but he drifted away. - "Lift should follow Java's naming conventions." No. Lift should make best use of the character set that Scala makes available. This means _? and _! are recommended (the underscore is required in Scala as a separator from letter/number symbols). Yes, the naming is not consistent and we're working on that. But for all the storm and fury around Lift's naming issues, there is not a single person who is taking the lead on the naming consistency issue and it's not that big of an issue from my perspective to spend the week or so that's needed to make it happen. - "OMG, Lift has markup on the model classes." Every web project that I've been involved with that's insisted in a firewall separation between model and form generation has had significant coordination problems between changes to the model and changes to the forms. Nothing in Lift requires that you use the model-generated forms. On the other hand, the model-generated forms lead to a unified authoritative location for the business logic, validation rules, field collections for a given domain element, etc. Yes, we need to do further work on grabbing the "Screen" concept from Wizard and integrating model field generation. But I've never had someone demonstrate that in practice, the dogma of "no view stuff in the model" has any practical value. - "Lift models should be composable with traits rather than putting fields in the model." We do that and someone complains that we've chosen the wrong names for the fields in the traits or other stuff. The ProtoUser, ProtoTag and ProtoExtendedSession stuff probably belongs in a separate package rather than in Mapper because these classes are the results of work that I've done on projects and I've been able to distill this stuff into classes. Now, with ProtoUser/MegaProtoUser the choice is to either put the source code with this functionality in the archetypes of in traits. I opted for traits. In practice, I wind up copying/pasting the MegaProtoUser code into my projects about 50% of the time. I'm sorry that Scala doesn't offer enough ability to subclass objects and other such, but it is what it is. - "S and LiftRules are big". Everything on S, SHtml, and LiftRules belongs there. In fact there are other pieces that belong on LiftRules that Marius and I didn't catch on our first pass through. - "Lift should be more OO" What does this mean? What could be made into something more concise or performant by making some class that you need to subclass? - "We should do a thorough code review of Lift" Go right ahead. Please do not expect me to participate. If there are specific things you want to build with Lift, we're here to help. If there enhancements that have a particular use case, we'll work on them. If you want to spend many man-months doing code a walk-through, please enhance the Lift documentation. To summarize: Most of the complaints (beyond the documentation issue) are directional differences. Nothing in this thread goes into an analysis of why other directions are better. I wish we had more people signed up to write/coordinate documentation so we could cater to a wider audience, but unless someone steps up and follows through, that's not likely to materialize. We're working on normalizing the names. Thanks, David On Thu, Dec 24, 2009 at 4:05 PM, Erkki Lindpere <[email protected]> wrote: > It took me a long time to "get" lift. For about a year I looked at > examples from time to time and tried out some basic stuff, but it just > didn't click. I found the structure to be too messy. I still do > actually. It seems that the documentation is also not well structured > enough for getting started and I had to look at examples and Lift's > source to understand how things work (thanks for putting sources in > the Maven repo BTW, I wish everyone would do that). > > After experimenting with Lift for about two days I think I get the > basic idea and I've come to a better understanding about lift's > structure by looking at the sources, I can now ignore the parts I > don't like (Mapper being one, I use JPA instead) and use the parts > that I do. > > The way the X(HT)ML processing, type-safe JavaScript/jQuery, Ajax and > Comet work is just brilliant! > > PS. I'm working (on my spare time for now) on an Ajax & Comet heavy > application that will hopefully also have a lot of runtime > customization ability through OSGi. I haven't gotten to the OSGi part > yet, because there's the hurdle of OSGifying all the jars I use and I > want to get a good understanding of Lift before I start making things > dynamic. But do you have any recommendations for OSGi framework/web > container combinations to use with Lift? I have tried SpringSource > dmServer (with the SpringSource tooling), but I don't like it much... > Maybe plain Equinox + Jetty with the ScalaModules library would be a > good combo? > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
