It's a polyglot world after all

[David Pollak]

Last week, I had a bunch of really excellent conversations with folks about Lift, Scala, fabric computing, scalable storage, etc.  One of the big take-aways from the conversation was that any system, web framework, fabric computing infrastructure, etc. cannot be Scala-only.  While Scala is a tremendously powerful and excellent language, it is too much of barrier to entry for many folks to switch to Scala just to adopt the likes of Lift.

With those ideas rumbling around in my brain, I had coffee with @KirinDave and the San Francisco BankSimple folks.  Our conversation quickly traversed 5 different languages.  The BankSimple folks are clearly top 1% developers and they are a polyglot shot... they choose the best language for the particular task.  Following the coffee, I got a a conference call with one of my clients (my first non-Scala project in over 2 years.)  During the call, it struck me light a bolt of lightening... it'll be 10+ years before the mainstream corporate developers (and they are the ones with money) adopt Scala... they're currently swallowing Ruby and having a not-great time of it.

I realized Lift had to broaden outside of Scala.

I went home and did a quick research spike on Lift to see how hard it would be to make Lift easily usable from Java.  Well, Lift is marginally usable from Java, but the code is, well, ugly Java code.  Once Java8 supports lambdas, using Lift from Java will be cleaner.

Next, I did a quick research spike in JRuby... and holy cow, with the exception of a few things (symbolic method names, singletons, implicit parameters/CanBuildFrom, and var-args) Lift is reasonably usable from JRuby (except for pattern matching... but we'll get to that issue in a minute).

I spent the last few days working on the JRuby codebase to address the above list of issues and I'm about half way done (see https://github.com/jruby/jruby/tree/scala )

I've also recruited a most awesome hard-core Ruby/Rails developers (Aaron Blohowiak http://twitter.com/#!/aaronblohowiak ) to help design the Lift Ruby APIs... because they have to be different from the Lift Scala APIs.  And where Lift uses a lot of Scala's pattern matching, we will work on a Ruby DSL to achieve the same thing, except in the Ruby Way.

To pro-actively answer some questions:

• No, Lift is not abandoning Scala... the core parts of Lift will always be written in Scala... it's my favorite language and it's a powerful language for expressing the kind of semantics that have made Lift powerful and different.
  
• Why would someone use Lift with JRuby when they can use Rails?  Lift is hands-down the best web framework available today.  It's got better semantics for Comet and Ajax than any other web framework.  It's more secure by default than most other web frameworks.  Lift-based apps scale nicely.  Lift apps are more concise than most other web apps.  Put another way, if you're a Ruby developer looking for a more secure, more scalable web framework that allows you to build more interactive apps, Lift is it.
• What other languages will Lift support? Initially, it'll be JRuby... once we get the JRuby APIs nice and clean, we'll look around for the next language to support.  Maybe it'll be mainstream Java (if we can solve API issues like pattern matching in Ruby, maybe a better answer will come along for Java).  Maybe it'll be Clojure.  But whatever the next language on the Lift polyglot tour, it'll feel native to that language (even if that means annotations in Java... gaaakkk).
• Will this derail the Lift documentation efforts?  No, just the opposite, as we work through the APIs, I plan to document them much more cleanly.

So, what needs to be done on the Lift side to support JRuby:

1. Snippets — invoking a Ruby script
2. Support for box/option (this may be as simple as making Box implement java.lang.Iterable)
   
3. S, SHtml, LiftRules
4. Boot
5. SiteMap
6. SessionVar/Vars
7. Helpers
8. CSS Selector Transforms
9. Alternative to pattern matching

The above is the list of the key parts of Lift that we have to build nice Ruby APIs for.

I look forward to broadening Lift's reach and making the power of Lift available to a broader and broader audience.  I look forward to the Lift community welcoming folks outside the core Scala community.

[work only]

Hi 

I know you want Lift to be used by more people and I do understand about business not support Scala, but once its compile its just bytecode.

I just feel a bit sad don't know why, I do hope that the documentation and video training down don't slow down.

Best Regards

Paul

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Indrajit Raychaudhuri]

On Wednesday 12 January 2011 at 10:04 AM, work only wrote:

Hi 

I know you want Lift to be used by more people and I do understand about business not support Scala, but once its compile its just bytecode.

Obviously, David can answer better, but my feeling is contrary. Broadening a framework to adapt to more language profits all and adaptation grows at faster rate.

For example, in the context of Lift Modules discussion, modules can be eventually be written either in Scala, Java or JRuby and they all work in a homogeneous environment of Lift ;) 

- Indrajit

[Indrajit Raychaudhuri]

So *this* is what had been brewing over the last week. Fantastic!

- Indrajit

[Derek Chen-Becker]

Looks like 2011 is going to be yet another wild ride (in a good way) ;)

[work only]

Yep it's good for Lift :)

Just diehard Scala supporter :)

Paul

[Joseph Stein]

How about the backend support effort? Model? Record? 10) & 11) ?

Is there any room for more help towards this?

/*
Joe Stein
http://www.linkedin.com/in/charmalloc
Twitter: @allthingshadoop
*/

[Maarten Koopmans]

My 2 cents: it's a good path, as long as it doesn't prevent Lift from
staying head and shoulders above the competition. More traction =
good, just like jRuby exists next to Ruby. As a joke... I'd call the
port lambda the ultimate at first :-)

And as an aside: I founded a start up (rightfabric) last year that
focuses on PAYG cloud backed storage fabrics for everyone, with all
code written in Scala and the web part now being done in Lift.
Rationale: sophisticated stuff needs sophisticated tools and a smart
community that is large enough (in stead of the mediocre people I
could get elsewhere). When we go private beta at the end of Q1 I'll be
sure to prioritize people here that are interested in a few GB free
online storage.

Ping if you are interested already.

Anyway, keep up the good work, also on the Scala side.

--Maarten

On Wednesday, January 12, 2011, Joseph Stein <cryp...@gmail.com> wrote:i

> How about the backend support effort? Model? Record? 10) & 11) ?
> Is there any room for more help towards this?
>
> /*
> Joe Stein
> http://www.linkedin.com/in/charmalloc
> Twitter: @allthingshadoop
> */
> On Tue, Jan 11, 2011 at 11:14 PM, David Pollak <feeder.of...@gmail.com> wrote:
> Last week, I had a bunch of really excellent conversations with folks about Lift, Scala, fabric computing, scalable storage, etc.  One of the big take-aways from the conversation was that any system, web framework, fabric computing infrastructure, etc. cannot be Scala-only.  While Scala is a tremendously powerful and excellent language, it is too much of barrier to entry for many folks to switch to Scala just to adopt the likes of Lift.
>
> With those ideas rumbling around in my brain, I had coffee with @KirinDave and the San Francisco BankSimple folks.  Our conversation quickly traversed 5 different languages.  The BankSimple folks are clearly top 1% developers and they are a polyglot shot... they choose the best language for the particular task.  Following the coffee, I got a a conference call with one of my clients (my first non-Scala project in over 2 years.)  During the call, it struck me light a bolt of lightening... it'll be 10+ years before the mainstream corporate developers (and they are the ones with money) adopt Scala... they're currently swallowing Ruby and having a not-great time of it.
>
> I realized Lift had to broaden outside of Scala.
>
> I went home and did a quick research spike on Lift to see how hard it would be to make Lift easily usable from Java.  Well, Lift is marginally usable from Java, but the code is, well, ugly Java code.  Once Java8 supports lambdas, using Lift from Java will be cleaner.
>
> Next, I did a quick research spike in JRuby... and holy cow, with the exception of a few things (symbolic method names, singletons, implicit parameters/CanBuildFrom, and var-args) Lift is reasonably usable from JRuby (except for pattern matching... but we'll get to that issue in a minute).
>
> I spent the last few days working on the JRuby codebase to address the above list of issues and I'm about half way done (see https://github.com/jruby/jruby/tree/scala )
>
> I've also recruited a most awesome hard-core Ruby/Rails developers (Aaron Blohowiak http://twitter.com/#!/aaronblohowiak ) to help design the Lift Ruby APIs... because they have to be different from the Lift Scala APIs.  And where Lift uses a lot of Scala's pattern matching, we will work on a Ruby DSL to achieve the same thing, except in the Ruby Way.
>
> To pro-actively answer some questions:
> No, Lift is not abandoning Scala... the core parts of Lift will always be written in Scala... it's my favorite language and it's a powerful language for expressing the kind of semantics that have made Lift powerful and different.
> Why would someone use Lift with JRuby when they can use Rails?  Lift is hands-down the best web framework available today.  It's got better semantics for Comet and Ajax than any other web framework.  It's more secure by default than most other web frameworks.  Lift-based apps scale nicely.  Lift apps are more concise than most other web apps.  Put another way, if you're a Ruby developer looking for a more secure, more scalable web framework that allows you to build more interactive apps, Lift is it.
>
> What other languages will Lift support? Initially, it'll be JRuby... once we get the JRuby APIs nice and clean, we'll look around for the next language to support.  Maybe it'll be mainstream Java (if we can solve API issues like pattern matching in Ruby, maybe a better answer will come along for Java).  Maybe it'll be Clojure.  But whatever the next language on the Lift polyglot tour, it'll feel native to that language (even if that means annotations in Java... gaaakkk).
>

> Will this derail the Lift documentation efforts?  No, just the opposite, as we work through the APIs, I plan to document them much more cleanly.So, what needs to be done on the Lift side to support JRuby:
> Snippets — invoking a Ruby scriptSupport for box/option (this may be as simple as making Box implement java.lang.Iterable)
> S, SHtml, LiftRulesBootSiteMapSessionVar/Vars
>
> Helpers
> CSS Selector TransformsAlternative to pattern matchingThe above is the list of the key parts of Lift that we have to build nice Ruby APIs for.

[Antonio Salazar Cardozo]

Wow. This is epic. I can't wait to see the fruits of this labor. I've slowly come to love Scala at least on the same level if not more than Ruby, but I can definitely envision a world where certain parts (maybe snippets) are a better fit for Ruby and others (e.g. actors) are a better fit for Scala.

This really is bringing Lift to the next level.

Antonio

[Mads Hartmann Jensen]

This is super exciting! Very nice start of 2011 for Lift :)

Sent from my iPhone

[Lukasz Kuczera]

Sounds very exciting. How about compatibility, new changes could be
harder to implement. Would it be possible to write some abstraction
layer on top of that.

> Blohowiakhttp://twitter.com/#!/aaronblohowiak) to help design the Lift

> Ruby APIs... because they have to be different from the Lift Scala APIs.
> And where Lift uses a lot of Scala's pattern matching, we will work on a
> Ruby DSL to achieve the same thing, except in the Ruby Way.
>
> To pro-actively answer some questions:
>

>    - No, Lift is not abandoning Scala... the core parts of Lift will always

>    be written in Scala... it's my favorite language and it's a powerful
>    language for expressing the kind of semantics that have made Lift powerful
>    and different.

>    - Why would someone use Lift with JRuby when they can use Rails?  Lift is

>    hands-down the best web framework available today.  It's got better
>    semantics for Comet and Ajax than any other web framework.  It's more secure
>    by default than most other web frameworks.  Lift-based apps scale nicely.
>    Lift apps are more concise than most other web apps.  Put another way, if
>    you're a Ruby developer looking for a more secure, more scalable web
>    framework that allows you to build more interactive apps, Lift is it.

>    - What other languages will Lift support? Initially, it'll be JRuby...

>    once we get the JRuby APIs nice and clean, we'll look around for the next
>    language to support.  Maybe it'll be mainstream Java (if we can solve API
>    issues like pattern matching in Ruby, maybe a better answer will come along
>    for Java).  Maybe it'll be Clojure.  But whatever the next language on the
>    Lift polyglot tour, it'll feel native to that language (even if that means
>    annotations in Java... gaaakkk).

>    - Will this derail the Lift documentation efforts?  No, just the

>    opposite, as we work through the APIs, I plan to document them much more
>    cleanly.
>
> So, what needs to be done on the Lift side to support JRuby:
>

>    1. Snippets — invoking a Ruby script
>    2. Support for box/option (this may be as simple as making Box implement
>    java.lang.Iterable)
>    3. S, SHtml, LiftRules
>    4. Boot
>    5. SiteMap
>    6. SessionVar/Vars
>    7. Helpers
>    8. CSS Selector Transforms
>    9. Alternative to pattern matching

[TylerWeir]

Increasing the user base can only help the framework mature and harden.

Huzzah!

[Rick]

I think this is great news. I've been thinking along these lines for a
while now and have been fluctuating back and forth between feeling I
need to learn Ruby and Rails but feeling the technically superior pull
of Scala and Lift. I see this as a very practical approach to
providing a way for web developers who are moving away from Java to
Ruby and Rails who will want to adopt Scala and Lift once awareness
has grown. I've been evangelizing for both ROR and Scala and Lift for
some time now and look forward to seeing how this develops. I'm
relatively new to both technologies but hope to be able to participate
as my skills improve.
Thanks David!

Rick

On Jan 11, 11:14 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Blohowiakhttp://twitter.com/#!/aaronblohowiak) to help design the Lift

> Ruby APIs... because they have to be different from the Lift Scala APIs.
> And where Lift uses a lot of Scala's pattern matching, we will work on a
> Ruby DSL to achieve the same thing, except in the Ruby Way.
>
> To pro-actively answer some questions:
>

>    - No, Lift is not abandoning Scala... the core parts of Lift will always

>    be written in Scala... it's my favorite language and it's a powerful
>    language for expressing the kind of semantics that have made Lift powerful
>    and different.

>    - Why would someone use Lift with JRuby when they can use Rails?  Lift is

>    hands-down the best web framework available today.  It's got better
>    semantics for Comet and Ajax than any other web framework.  It's more secure
>    by default than most other web frameworks.  Lift-based apps scale nicely.
>    Lift apps are more concise than most other web apps.  Put another way, if
>    you're a Ruby developer looking for a more secure, more scalable web
>    framework that allows you to build more interactive apps, Lift is it.

>    - What other languages will Lift support? Initially, it'll be JRuby...

>    once we get the JRuby APIs nice and clean, we'll look around for the next
>    language to support.  Maybe it'll be mainstream Java (if we can solve API
>    issues like pattern matching in Ruby, maybe a better answer will come along
>    for Java).  Maybe it'll be Clojure.  But whatever the next language on the
>    Lift polyglot tour, it'll feel native to that language (even if that means
>    annotations in Java... gaaakkk).

>    - Will this derail the Lift documentation efforts?  No, just the

>    opposite, as we work through the APIs, I plan to document them much more
>    cleanly.
>
> So, what needs to be done on the Lift side to support JRuby:
>

>    1. Snippets — invoking a Ruby script
>    2. Support for box/option (this may be as simple as making Box implement
>    java.lang.Iterable)

>    3. S, SHtml, LiftRules
>    4. Boot
>    5. SiteMap
>    6. SessionVar/Vars
>    7. Helpers
>    8. CSS Selector Transforms

>    9. Alternative to pattern matching

[Marius Danciu]

I've read this and it's weed that I can't form an opinion on this for myself. I understand that are obviously some good benefits for some "market" out there but I have the feeling that there will be great caveats and compromises into supporting these languages. I think one of the main reasons for Lift's popularity and power is Scala itselft. But this aspect won't diminish whatsoever.

Br's,
Marius

[Esko Luontola]

On Jan 12, 6:14 am, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> During the
> call, it struck me light a bolt of lightening... it'll be 10+ years before
> the mainstream corporate developers (and they are the ones with money) adopt
> Scala... they're currently swallowing Ruby and having a not-great time of
> it.
>
> I realized Lift had to broaden outside of Scala.

Sounds like you're onto something.

Recently I had similar thoughts about my Scala-based testing framework
(https://github.com/orfjackal/specsy) that it would make sense for it
to be usable from any JVM language. Groovy, JRuby and Clojure support
should be easy because they have closures, but figuring out an equally
expressive syntax for Java was a much harder problem.

Below is an example of what the testing framework currently looks like
in Scala and the most feasible draft of how the same could be
expressed in Java. I think that in Java nested anonymous inner classes
could be used as an alternative to closures (Scala's mutable local
variable in closure vs. Java's field in anonymous inner class).

StackSpec example in Scala:
https://github.com/orfjackal/specsy/blob/41530a8560e2d2285628ed20681c1cf2056b1af0/src/test/scala/net/orfjackal/specsy/examples/StackSpec.scala

StackSpec example in Java:
https://github.com/orfjackal/specsy/blob/41530a8560e2d2285628ed20681c1cf2056b1af0/src/test/java/net/orfjackal/specsy/examples/JavaStackSpecDraft2.java

I wrote about it more at http://groups.google.com/group/specsy/browse_thread/thread/64744ace02d5e66d

[Andy Czerwonka]

Hmnn... I'm not sure how I feel about this one.  I dare to say good and bad.  Good, because making Lift more accessible is great.  The more people the better. Bad for two reasons. Firstly, Ruby is on a steady and sharp popularity decline since 2009 and I don't see that changing anytime soon, while Scala is on the incline, so I really don't see the point. Secondly, effort could be used for much more important aspects of Lift.

Just because you can doesn't mean you should.  Just my 2 cents.

[work only]

Hi

The Java Posse on last podcast said that 2011 is the year of Scala, judging by Java One!

I do see Scala more and more on the web and do believe that Scala will be big in 2011 :)

Paul :)

On Wed, Jan 12, 2011 at 2:13 PM, Andy Czerwonka <andy.cz...@gmail.com> wrote:

Hmnn... I'm not sure how I feel about this one.  I dare to say good and bad.  Good, because making Lift more accessible is great.  The more people the better. Bad for two reasons. Firstly, Ruby is on a steady and sharp popularity decline since 2009 and I don't see that changing anytime soon, while Scala is on the incline, so I really don't see the point. Secondly, effort could be used for much more important aspects of Lift.

Just because you can doesn't mean you should.  Just my 2 cents.

--

[therac25]

I would have thought that most Lift users came to Lift in the first
place, because they wanted to use Scala for web development (I know I
did). At the moment I feel Lift is still far behind Django or Rails in
terms of documentation, tutorials available and general beginner-
friendliness. I also feel that trying to woo Rubyists away from Rails
is a waste of time, you might have more luck with Java though...

Personally, I'd rather see Lift become more accessible, with a
smoother learning curve, a quick way to get started, (without having
to figure out out first what Maven and SBT do, which IDE works well,
which version of Lift and which learning resources to pick...), some
nice tutorial (a small blog app a la Rails... the pocket change app is
close but it's not in quick-tutorial format)

Anyway my 2 cents

Emmanuel



On Jan 12, 5:14 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Blohowiakhttp://twitter.com/#!/aaronblohowiak) to help design the Lift

> Ruby APIs... because they have to be different from the Lift Scala APIs.
> And where Lift uses a lot of Scala's pattern matching, we will work on a
> Ruby DSL to achieve the same thing, except in the Ruby Way.
>
> To pro-actively answer some questions:
>

>    - No, Lift is not abandoning Scala... the core parts of Lift will always

>    be written in Scala... it's my favorite language and it's a powerful
>    language for expressing the kind of semantics that have made Lift powerful
>    and different.

>    - Why would someone use Lift with JRuby when they can use Rails?  Lift is

>    hands-down the best web framework available today.  It's got better
>    semantics for Comet and Ajax than any other web framework.  It's more secure
>    by default than most other web frameworks.  Lift-based apps scale nicely.
>    Lift apps are more concise than most other web apps.  Put another way, if
>    you're a Ruby developer looking for a more secure, more scalable web
>    framework that allows you to build more interactive apps, Lift is it.

>    - What other languages will Lift support? Initially, it'll be JRuby...

>    once we get the JRuby APIs nice and clean, we'll look around for the next
>    language to support.  Maybe it'll be mainstream Java (if we can solve API
>    issues like pattern matching in Ruby, maybe a better answer will come along
>    for Java).  Maybe it'll be Clojure.  But whatever the next language on the
>    Lift polyglot tour, it'll feel native to that language (even if that means
>    annotations in Java... gaaakkk).

>    - Will this derail the Lift documentation efforts?  No, just the

>    opposite, as we work through the APIs, I plan to document them much more
>    cleanly.
>
> So, what needs to be done on the Lift side to support JRuby:
>

>    1. Snippets — invoking a Ruby script
>    2. Support for box/option (this may be as simple as making Box implement
>    java.lang.Iterable)

>    3. S, SHtml, LiftRules
>    4. Boot
>    5. SiteMap
>    6. SessionVar/Vars
>    7. Helpers
>    8. CSS Selector Transforms

>    9. Alternative to pattern matching

[Philippe Jean]

2011/1/13 therac25 <th3r...@googlemail.com>

I would have thought that most Lift users came to Lift in the first
place, because they wanted to use Scala for web development (I know I
did).

I think it's the same for everybody.

 

At the moment I feel Lift is still far behind Django or Rails in
terms of documentation, tutorials available and general beginner-
friendliness.

Lift's community does a great job on that and needs to continue.

 

I also feel that trying to woo Rubyists away from Rails
is a waste of time, you might have more luck with Java though...

True, the ruby ecosystem is very large and really loved by Rubyists.

I think will should have the same. Why Sbaz it's not our RubyGems ?

Personally, I'd rather see Lift become more accessible, with a
smoother learning curve, a quick way to get started,

Obtain Lift, Lift's module, Lifty, ...  from Sbaz should be a good approach to start quickly.

 

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--

Philippe Jean

[Andy Czerwonka]

I agree.  I'm actually baffled as to why Lift would want to extend its footprint into the Ruby community.  Strategically, it makes little sense.

[work only]

I think Philippe is 100% right!

I'm changing my mind again, I think adding jRuby is wrong.

I came to Lift because of Scala.

Need to make Lift more accessible, I think 2011 will be Scala year, so why spend time on Ruby.

Paul

[Donald McLean]

I have to thoroughly agree with this.

Except that there is not need to use Maven or SBT (Ant still works
just fine, even if it isn't quite so glamorous) and though the IDEA
plugin is still a little rough, it isn't bad.

Donald

[Andy Czerwonka]

As you can see from my post above, I 100% agree.  I think this Ruby experiment is more about "when can, so we will" versus "we should".  Building documentation and tools is not as fun and sexy as solving technical problems - we can all agree to that if we're developers - but the mileage we'd get  in terms of solving the accessibility problem is much higher.

[S?ren Bramer Schmidt]

It is very difficult to determine current and future usage of a language.

First: The indeed job index disagrees http://www.indeed.com/jobtrends?q=%22ruby%22,+%22python%22,+scala&l=

Second: Even if the Tiobe index is a reasonable measure, Ruby is still 10 times as "popular" as Scala http://www.tiobe.com/index.php/paperinfo/tpci/

Exposing Lift to the many talented ruby developers will increase the influx of ideas and feature requests as well as bring on board more people to write tutorials and the likes.

Hopefully David and the rest of the comitters will be able to work with, be inspired by an learn a thing or two from some of the bright people at the ror core team.

Onwards and upwards :-)

[David Pollak]

On Thu, Jan 13, 2011 at 9:07 AM, Donald McLean <dmcl...@gmail.com> wrote:

I have to thoroughly agree with this.

And you can keep using Lift with Scala.  Lift is written in Scala and the Scala APIs will always be excellent.  There's no cost to you or anyone using Scala because there will be other language bindings.

The choice of JRuby is the choice that I made and it's the investment that I'm going to make.  If someone else wants to make the investment in other language bindings (design, implementation, support), I welcome the discussion, but saying "that's a bad decision" without stepping up with an alternative doesn't help anyone.
 

Lift is not in the IDE business nor is it in the build tool business.  All you need to get started with Lift is Java, zip or tar and a text editor.  The learning curve for sbt is "sbt clean", "sbt update", "sbt jetty-run", "sbt jetty-stop" and "sbt package"  That's it.  Complaining that it's hard is not valuable or even credible.

We've got a number of tutorials (Pocket Change, To do, Lift's getting started and chapters 2-4 of Simply Lift).
 

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@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
Blog: http://goodstuff.im
Surf the harmonics

[Derek Chen-Becker]

Also, it appears the David will be working with the JRuby team (Charles) to add/strengthen functionality in JRuby to make using Lift from JRuby as clean as possible. I think that the maintenance of any JRuby-specific code in Lift is going to be minimal because for the most part a lot of things are common (the whole JVM thing).

Derek

On Thu, Jan 13, 2011 at 11:09 AM, Maarten Koopmans <maarten....@gmail.com> wrote:

On Thu, Jan 13, 2011 at 6:26 PM, David Pollak <feeder.of...@gmail.com> wrote:

On Thu, Jan 13, 2011 at 9:07 AM, Donald McLean <dmcl...@gmail.com> wrote:

I have to thoroughly agree with this.

And you can keep using Lift with Scala.  Lift is written in Scala and the Scala APIs will always be excellent.  There's no cost to you or anyone using Scala because there will be other language bindings.

The choice of JRuby is the choice that I made and it's the investment that I'm going to make.  If someone else wants to make the investment in other language bindings (design, implementation, support), I welcome the discussion, but saying "that's a bad decision" without stepping up with an alternative doesn't help anyone.

I think the fear of people here is that it will slow Lift's core development down, because language bindings take energy to build and maintain. By itself that's a viable alternative (opinion) that I don't share. The way I see it, Lift is pretty feature-complete with the HTML5 support and CSS selectors - the rest is maturing. Which includes language bindings.

What would scare me is if David and the core team would say that they would put Lift on hold for a rewrite in [.....] But that's not the case at all! This is an excellent opportunity to broaden and strengthen the community.

As for documentation - it's pretty good, especially when you use Lift in Action, the WIki, Simply Lift and Exploring Lift side by side. With that and the speedy replies on this list, I haven't had much problems.

--Maarten

[Donald McLean]

The books are pretty good, admittedly.

The ScalaDoc, I have found, is rife with missing information that has
consistently rendered it nearly useless (at least to me anyway).

Donald

[Derek Chen-Becker]

I know it's little consolation, but every time I touch the code I try to work on ScalaDocs as well.

--

[Andy Czerwonka]

It's subjective to be sure.  The 10-times comes from Ruby having a killer app, Rails.  I'd like to see how many non-Rails Ruby developers there are.  I'm guessing just a little more than zero.  Lift could be that for Scala, but not if we're do muddy the water.

I'm not convinced that if we're to venture into supporting an alternative language Ruby is it.

[Aaron Blohowiak]

I share the desire to use tools that "just work", and have easy-to-
follow documentation about how to get things done. My first public
contribution to Lift was a copy+paste set of instructions for getting
Lift up and running on OSX: http://bit.ly/gEianf (This should work on
any *nix with java installed.) I posted this before the current
(false-dichotomy) discussion of tools/documentation "vs" jruby
discussion took off on this list.

A great deal of my feedback to DPP so far has been with omissions and
non-obvious parts of the ramp-up to getting started with Lift, which
would only be complicated by adding another language into the mix.
Getting this down to as few obvious steps as responsibly possible is
one of my concerns. I'm familiar with ruby's rvm/rubygems, python's
virtualenv/pip, and node's nave/npm. Bringing this experience to
scala/sbt, I hope to also bring some of the niceties that I've picked
up along the way.

- Aaron

[Antonio Salazar Cardozo]

It really sounds like you've got different goals. It seems like David's goal is to build the best web framework out there and have people use it, not to increase Scala's mindshare. The mindshare of Scala is relevant only insofar as it increases who uses Lift, in this scenario.

Antonio

[Виталий]

Maybe just make another framevork
Call it Jrift or Jruby on Scala.
David, please do not kill the uniqueness of the lift

[Andy Czerwonka]

Oh, I don't know if we have different goals.  I too want Lift to be the best.  We just disagree that adding JRuby gets us closer to that goal.  

Either way, David is doing it so I think this conversation is moot.  The answer will come out in time and I could very well be proven wrong.  What I expect what will happen is that we'll bring on some Rails folks who want to be on the JVM, they'll post a bunch of issues in Assembla only because Lift is different than Rails, the issues will be rightly ignored, some people will convert and some people will go back to Rails, and we'll be back to where we are today.  Experiment over.

[Andy Czerwonka]

The only reason I brought up the Rails is because it's directly responsible for the Ruby mindshare.  Without Rails, Ruby is nowhere near as popular as it is.  Like Rails, Lift makes something real, something other than "Hello World', accessible to Scala newbies.

[therac25]

I guess it depends on the type of users you want to reach out to.
At the moment, Lift is for power-users, who don't mind diving into the
framework's source to figure things out.

Average-Jims, like me, get a lot more-mileage from tutorials/docs with
examples a la Django, than from auto-generated documentation a la
scaladoc.
We can get started fairly quickly and delve into hot waters (it
happens inevitably) later on.

I am mentioning Django, because I tried selling Scala/Lift to team
mates for a web site we are redoing from scratch.
I guess it was a bit of stretch because the team does not have a lot
of experience.
Anyway, they freaked out when they saw the docs.
In the end we went for Django/Python

Emmanuel



On Jan 14, 6:26 am, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> On Thu, Jan 13, 2011 at 9:07 AM, Donald McLean <dmclea...@gmail.com> wrote:
> > I have to thoroughly agree with this.
>
> And you can keep using Lift with Scala.  Lift is written in Scala and the
> Scala APIs will always be excellent.  There's no cost to you or anyone using
> Scala because there will be other language bindings.
>
> The choice of JRuby is the choice that I made and it's the investment that
> I'm going to make.  If someone else wants to make the investment in other
> language bindings (design, implementation, support), I welcome the
> discussion, but saying "that's a bad decision" without stepping up with an
> alternative doesn't help anyone.
>
>
>
>
>
> > Except that there is not need to use Maven or SBT (Ant still works
> > just fine, even if it isn't quite so glamorous) and though the IDEA
> > plugin is still a little rough, it isn't bad.
>
> > Donald
>

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[Gordon Leland Hempton]

I am just getting started using lift on a project of mine, but thought I would chime in on this thread. The main reason I decided to explore lift was because of Scala and the potential for a framework to take advantage of Scala's advanced language features. If instead Lift were marketed to me as a Rails alternative that is fully compatible with Ruby I don't think I would have chosen it...

Cheers,
Gordon

To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

[localgod]

Been thinking about this for a day or so and so far haven't been able
to come up with anything that takes out the bad taste I got in my
mouth when first reading this.

Lift is stable and fully-featured enough to use for large production
sites. The community is growing, not shrinking, and has been large
enough to be over the critical threshold for a very long time now.

I have a small and growing team building various products on Lift. My
experience so far has been that it is not at all hard to take any
decent developer and get them up to speed on enough Scala and Lift for
them to productive and can be done in a very short time-frame. The
current range of tutorials and documentation is a little lacking in
certain areas but improving all the time and Lift is becoming much
more accessible.

Personally, I prefer working with smart people and am happy for Scala
to be a quality filter (http://martin.kleppmann.com/2009/09/18/the-
python-paradox-is-now-the-scala-paradox.html). That said, I can't
imagine any good developer who wouldn't be able to pick up the combo
easily, given a few pointers and feedback here and there. As many
people have said, it seems harder than it is.

Scala itself is more and more stable as a platform these days too (and
still extremely powerful, flexible and concise). Add to this the
increasing accessibility of Lift, the proliferation of great and
upcoming books, the growing general interest in Scala and the awesome
new features in recent Lift versions and now is really the *perfect*
time to push the wonderful Scala/Lift combination, not dilute it. As
others have mentioned, Scala is, for many, Lift's biggest selling
point. I have no trouble at all selling Scala and Lift in their
present states to investors and customers - the few little slides we
include on this stuff in our sales pitches makes them very happy to be
working with us.

From another angle, I don't want JRuby code anywhere near my Lift
projects and Rails developers are almost the last place I would
consider looking for new hires, in both cases for a number of
legitimate reasons. If we can't find people who already know a little
Scala, and so far we haven't had this problem, ideally instead I want
people who already know something about the Java ecosystem and, while
we're on it, who also know about more than one way to make web apps.
If you really want to branch out to larger audiences, why not dumb
some aspects down for Java or Groovy devs? If the numbers are your
selling point here, Java and PHP devs are targets that eclipse the
Rails community hundreds of times over and clearly Python devs vastly
outnumber Ruby devs too.

It doesn't make any sense to me to commit a lot of otherwise
potentially useful man hours to developing tools of questionable
utility purely in order to be able to market your obscure, fringe
framework based on an obscure, fringe language to users of another
obscure, fringe framework based on another obscure, fringe language
(relatively speaking). Especially if one is doing so just to impress
a bunch of misguided, lost individuals (fan-boys) who mistakenly
believe their framework of choice is god's gift to the web and who are
suspiciously overly-defensive of said framework. IMO, this doesn't
help people who are managing and running Lift projects in any
meaningful way. Rails has a bit of old buzz but nothing else
particularly useful - like the iPhone, people like to talk about it
and there are some minor innovations there but it really only has a
tiny share of the market.

"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." So far the unreasonable
strategy has worked well here for DPP. It seems that this move is
running in the opposite direction. I hope that it turns out to be
helpful to the cause if it does take off but I have worried and
continue to worry that DPP just wants to be a more professional
version of DHH and this exercise does not reassure me. If you want to
save enterprise Rails and Ruby people from their sub-optimal platform
and language, making yours work like theirs is not the way and just
seems to impose their problems on us - people who are otherwise
unblighted by those issues. To save themselves, these people need to
learn a new way - and the Scala/Lift way is a pretty damn fine way as
it is.

If you really want Lift to gain more market share ramp up the
marketing and make more noise about it. It is certainly, undeniably
worthy of great renoun and the title of "world's best web framework".
Send out the minions and recruit your own pandering fan-boys; this
seems to be the proven path. (Unfortunately most of the community
here are probably too mature for pandering. ;)) Make it blantantly
obvious on the Lift homepage that Lift is the only framework in the
world worth considering for any project on anything, ever. Sell it as
the one true path. Just remember to be Fair and Balanced when
emphasizing the obvious truths to the otherwise unenlightened...

[Mads Hartmann Jensen]

I might have a project coming up which would be a great fit Lift but unfortunately the the company isn't comfortable with Lift because there are VERY few scala developers in Denmark at the moment. So we may have to do it in RoR.

Now, if Lift supported jruby they would get the comfort of knowing they can find new developers if needed and I still get to use Lift (through jruby) and the concepts I love (view-first, designer friendly templates, comet, sitemap, box, etc.)

[Andy Czerwonka]

The language should not be the barrier.  When I wanted to do a Rails project, I learn Ruby.  They can do the same.. learn Scala to use Lift.

[Mads Hartmann Jensen]

This is also my personal opinion - I love learning new things - but you have to recognize that it isn't necessary how most companies think. Training developers is a hassle which takes times and money.

On Jan 14, 2011, at 5:54 PM, Andy Czerwonka wrote:

> The language should not be the barrier. When I wanted to do a Rails project, I learn Ruby. They can do the same.. learn Scala to use Lift.
>

[Andy Czerwonka]

Fair.  I, personally, only hire developers that want to learn new things and can do it on their own.  I find that training only helps once someone has taken the initiative themselves anyway.

[Andy Czerwonka]

[Maarten Koopmans]

I think the 'sides' are clear, shall we stop this thread?

--Maarten

On Friday, January 14, 2011, Andy Czerwonka <andy.cz...@gmail.com> wrote:
> Fair.  I, personally, only hire developers that want to learn new things and can do it on their own.  I find that training only helps once someone has taken the initiative themselves anyway.
>
>
>

[Mads Hartmann Jensen]

Yeah, Probably a good idea ;)

[Andy Czerwonka]

Agreed.

[David Pollak]

On Thu, Jan 13, 2011 at 10:28 AM, Donald McLean <dmcl...@gmail.com> wrote:

The books are pretty good, admittedly.

The ScalaDoc, I have found, is rife with missing information that has
consistently rendered it nearly useless (at least to me anyway).

As I pointed out in the original post, the ScalaDocs and general documentation will benefit by doing additional language bindings.  As we go through the APIs and decide to either use them or build JRuby alternatives, we will add ScalaDocs and I will update Simply Lift.
 

Donald

On Thu, Jan 13, 2011 at 1:09 PM, Maarten Koopmans

<maarten....@gmail.com> wrote:
>

> As for documentation - it's pretty good, especially when you use Lift in
> Action, the WIki, Simply Lift and Exploring Lift side by side. With that and
> the speedy replies on this list, I haven't had much problems.

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.