On Sat, Mar 6, 2010 at 12:13 PM, cageface <milese...@gmail.com> wrote:
> 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. Apparently you used Rails in a different era from me. Rails and Ruby and Gem were not native on OS X (it became part of the OS in 10.4). One had to be a serious guru to build and install the basic Ruby system. Even using RedHat and RPMs, it was a good 2 hours to get Ruby and Gem and Rails installed. Back in 2005-2006 Ruby and Rails were not easy to get started with. Once that was done, yes, the initial Rails project was easy to create... a tad easier than Tim's 1 line Maven command, but not that much easier. > A few very non- > intimidating commands and you were up & running and making quick edits > that appeared in real time. Yep. There is a difference between a statically compiled language and a dynamic one. There is a difference between keeping a fair amount of state around and not. There are costs and benefits with each. While I would like to make Lift easier to be "change and reload" out of the box, in general, if that is the barrier to adoption for a certain segment, then so be it. > 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. > So, the key thing is what's the flash to bang. Yes, these days, the flash to bang with Rails is fast. Maybe we should have built the real time chat stuff as the first project. http://liftweb.blip.tv/file/2033658/ It's faster flash to bang. But, I disagree with the assertion that the flash to bang for Lift is long. Yeah, if someone is going to spend 2 minutes with Lift, we probably won't make a case. If someone spends enough time to see the Ajax features of Lift (especially coming from the Java frameworks, but even coming from Rails), we get a substantial number of folks who are hooked like http://groups.google.com/group/liftweb/browse_thread/thread/136d2accec22f300?hl=en("Lift is so complex but once you wrap your head around it is so easy :D ") > > > 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. > A big part of gaining long term adoption of any technology is timing the chasm crossing such that when the chasm is crossed, there is long term sustainability. DHH promoted Rails too early in my opinion. VeriSign adopted Rails for some projects and after deploying those projects and then paying Zed Shaw to write Mongrel, VeriSign dumped Rails. Had Rails been lower visibility, the Rails community would not have suffered through this embarrassment followed by the Twitter embarrassment. To this day, even though Rails has high visibility and is more stable than it used to be, it is still tarred on the corporate side with the "doesn't scale" moniker. This has opened the doors for Grails. Another failing of Rails is the community. The Rails community is a significant detractor to adoption outside of the young hip kids. What we have in Lift is very solid technology, an excellent community, tremendous committers, and an increasing number of very high profile projects built on Lift. These are very solid, very defensible assets. But I'd rather try to cross the chasm and actively promote Lift and Scala to the broader community when we know what community we're promoting to (hip Web 2.0+ kids, Enterprisy folks, ???), what the real value proposition is, and when we have a revenue model that is not based on selling out to the likes of Sun or VMWare. As an aside, I've been getting calls from VCs lately about investing in Lift & Scala. Some of them just want to bet on a horse and some of them have been actively working with me, Martin and others to figure out what Lift and Scala look like across the chasm. But right now, Lift is a community, committers and excellent technology for building secure, maintainable, highly interactive web sites. When it's time to build a business around Lift and Scala, you will see some excellent marketing. > > 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. > It depends on what people set out to build and it depends on what their mind set is. The way you come across is "whatever isn't Rails is bad and everything that is Maven is bad." It will never be my goal to convince folks with that kind of mind set to use Lift. In the Enterprise, security is a huge concern. Having security as a default is a huge selling point on its own. Especially when the time to get started with Lift is less than a day and the time to get started with Rails is about a day. You did not discuss Lift's Ajax stuff in your review. Instead of having to change 2 or 3 files for each Ajax request as in Rails, you only need change 1. This was not lost on HarryH when he selected Lift for FourSquare. See page 11 of his preso for an excellent 5 line reason why: http://docs.google.com/present/view?id=dcbpz3ck_24f3v83ggz So, yes, there are things that are going to be more concise in Rails. But there are also things that are more concise in Lift. About 50% of the Rails folks who come onto the Lift list stay. The other half don't. That's a perfectly fine ratio for right now. > > > > 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. > At this point, I see this as a feature. Anyone who is going to evaluate Lift purely on the looks of the HTML on the getting started guide, is not likely to fit into the community. This may seem like a jerky thing to say and may seem like it feeds into your concern about the anti-marketing functional language folks. It's not. I'd prefer people who will do some substantive evaluation of Lift... maybe spend a whole day on it rather than simply looking at the docs and say, "these guys can't make it pretty... they must be morons." When it's time to cross the chasm, then we'll make things prettier, but for now it's just not a priority. > > 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. > You can use HTML 4 with Lift, but the templates must all be well formed XML documents. There are reasons for using XHTML... the non-IE browsers are more uniform in their rendering of XHTML. But Lift does not mandate it... it just defaults to XHTML. > > > > 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. > There's always a balance between "magic" and explict work on the part of the developers. I tend to avoid magic when it comes to Schemifier... the last thing people want is unexpected stuff showing up in their RDBMS. > > 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. > Thanks, David > > -- > 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<liftweb%2bunsubscr...@googlegroups.com> > . > 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 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.
