Also, someone was lamenting GitHub's flat wiki. Assembla has a more advanced wiki system but David said it's not worthwhile to move unless someone will take on the role of managing the wiki.
On Sat, Mar 6, 2010 at 10:44 PM, Naftoli Gugenheim <[email protected]>wrote: > 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.
