I think I understand David's point about letting Lift sell itself for now, rather than pushing for more widespread adoption, until the right time comes At the same time I would like to mention that it seems to me (not based on any experience) than Jonathan Mawson has very good marketing sense / common sense. I think that with David's direction, if Jonathan is interested he could contribute a lot with his suggestions and helping implement them. For example, revising the "selling points" in a way that David and Jonathan agree on could be very valuable. I'm sure that if he puts his mind to it, he will have a lot of ideas that are good for Lift.
On Sat, Mar 6, 2010 at 8:28 PM, David Pollak <[email protected]>wrote: > > > On Sat, Mar 6, 2010 at 12:13 PM, cageface <[email protected]> wrote: > >> On Mar 6, 9:35 am, David Pollak <[email protected]> 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 [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]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > -- 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.
