Scala+Lift Philosophical Question

[efleming969]

Most questions in the group are technical and I apologize if this is
not appropriate, but I I'm curious about how members are justifying
their use of Scala+Lift vs. a traditional Java architecture. I
understand if you are creating applications for your own business or
personal use, but what about employee or consulting work (if any).

I'm currently a one man consultant and would like to do more work with
Scala and Lift but it seems high risk for my client to have an
application built with newer and practically unknown technologies like
these.

Any thoughts?

[Viktor Klang]

High risk? High risk of what?
Compared to doing it in Java?

I always say that the thing of uttermost importance is to stay competitive in the market,
and if you want to stay competitive, you'll have to be daring.

Using Scala+Lift over Java/Struts2/JSF/whatnot most likely means less than half time-to-market.
And that means lower development-costs, better ROI and more possibilities.
But I guess that's nothing compared to feeling really secure. So perhaps they should go for COBOL + COBOL On Cogs. ;)

Cheers,
Viktor

--
Viktor Klang
Senior Systems Analyst

[Warren Henning]

On Tue, Oct 21, 2008 at 5:50 PM, efleming969 <eflem...@gmail.com> wrote:
> but it seems high risk for my client to have an
> application built with newer and practically unknown technologies like
> these.

I'm kind of a Lift outsider but this isn't all that Lift-specific in
my view, it's a more general concern about using new technology that
hasn't gained much traction yet, which is something I have experience
with.

I think I understand where you're coming from. It's always scary to
venture into the unknown. Using new technologies, you can feel as if
very quickly after "hello world" you hit a dirt road and you're on
your own to work things out. However:

1. If you think about it, in a typical web application, the web
framework will only be a small part. The rest (the application server,
database, DNS server, load balancers, spam filters, ...) are still the
same. I for one think your choice of relational database, for
instance, is of far greater consequence than the web framework(s) you
choose.

2. David Pollak is one of the most experienced, intelligent guys in
the industry. He is ideally suited to the task of writing a web
framework.

As I see it, Lift takes proven infrastructure and integrates it using
ideas derived from years and years of hard-won, real-world experience.

Also, doesn't a good test suite help things a lot? If Lift doesn't
work the way it ought to, your tests should be able to expose that in
a meaningful way.

From your perspective, at the present time probably the biggest thing
to be aware of is that the Lift API is not finalized and breaking
changes happen more often than they do with mature projects.

Warren

[Marius]

You guys both have very valid points.

Lift is still stabilizing API's for a month or two (AFAIK) till 1.0
which is to be a pre-alpha or maybe alpha release? (this needs TBD)

I can imagine that from adoption part there is still a lot of
reluctance especially in Java space because:

1. People need to learn Scala (I'm so glad that more and more people
are willing to)
2. People need to learn Lift and I tend to think that this is a quite
fast process comparing to other frameworks even if Lift's
documentation is kind of lacking in many respects.
3. From versioning perspective not being yet an Alpha/Beta/GA (you
name it) may be a question mark as things are not fully stable yet
(I'm referring to API's). In reality if people are willing to dig in
they will find outstanding things.

Still with all these "caveats" I would choose Lift over any other Java
web framework anytime. Selling this to companies or even corporates to
adopt it over the oversold (Spring, Struts, JSF etc) it very tough.
But regardless, more and more commercial applications are written in
Lift (AFAIK).

My 2 cents ...

Br's,
Marius

On Oct 22, 12:37 pm, "Warren Henning" <warren.henn...@gmail.com>
wrote:

[Tim Perrett]

Interesting thread.

Having done both emplyed work and freelance consultancy I agree
totally with Marius in sense that selling in the idea of XYZ
technology to enterprise is one of the most difficult things we face,
as there are some very deep set processes in the enterprise
environment (Microsoft, SAP et al) and a lot of reluctancy to touch
OSS in general.

Companies usually tackle this in one of two ways:

1) Outsource the entire project to a 3rd party (dev, hosting etc) so
then they just need it to work and fulfil the spec and not worry about
organizational issues that may hinder the implementation of XYZ
technology in there business. A classic of this is Ruby... it runs
like crap on windows, and like it or not, M$ have a massive market
share of infrastructure and deployment hardware in the enterprise
environment so outsourcing the implementation and deployment makes
sense and the organization still get quicker ROI of the shorter dev
time.

2) A drawn out internal wrangle / argument that is costly in both time
and finances

One of the nice things about Lift is that it runs on standard java web
infrastructure so there is no extra stuff needed for deployment. It
runs on the JVM so its easily cross-platform - i have lift apps
running on OSX for Dev, windows and linux for deployment.

Lift really does rock - the bottom line right now is that its not yet
at 1.0, but rails had a pretty-widespread take-up between 0.9 and 1.2;
I see the same pattern happening here. A great feature set, pragmatic
design, and some awesome modules right out of the box. There will
always be people who want to use what they know (otherwise we'd have
killed off perl years ago), but there are an equal number of people
(and therefore companies) who want to explore the edgy new technology.
IMO, its about having balance in your toolset.

Cheers

Tim

[efleming969]

Wow, thanks for the feedback.

I should have been more clear as to what I meant by "High Risk". I'm
not concerned so much with Lift's technical merit, but rather the risk
of personnel. If I get hit by the "proverbial bus" then my client/
employer will have a difficult time completing/maintaining the project
due to skill set alone.

I agree with the points about infrastructure and Scala/Lift's cross-
platform capabilities. I would not use it otherwise. I also agree
that Lift rocks and is a viable alternative to traditional Java
approaches.

That being said. I do have my client's best interest in mind and I
think using Scala and Lift is somewhat selfish on my part. I guess
I'll have to be on the lookout for buses :-)

[Viktor Klang]

On Wed, Oct 22, 2008 at 4:30 PM, efleming969 <eflem...@gmail.com> wrote:

Wow, thanks for the feedback.

I should have been more clear as to what I meant by "High Risk".  I'm
not concerned so much with Lift's technical merit, but rather the risk
of personnel.  If I get hit by the "proverbial bus" then my client/
employer will have a difficult time completing/maintaining the project
due to skill set alone.

I think it's naïve to think that you can swap-in and swap-out "programmers" like they were generic building blocks.
I've been building enterprise systems using Java for 7 years now, and my experience is that the only time
you can exchange one programmer for another is if someone writes the spec and the programmer "just puts the letters into the file".
And trust me, no programmer worth paying for would work under those terms.

So, to sum up what I mean: 1 star developer with tools of his/her choice > 100 Java Joes with Struts 1 and EJB2
Also, the star developer doesn't cost 100 times more or takes 100 times longer to finish the task.

Also, the quality of the code (maintainability and defect ratio) is better with the star developer.

So, to sum up. No it's not as easy to find a "generic" developer, but using outdated technology with sub-par developers is not a good path to take. :)

This is, of course, my very personal opinion, and may be considered as the ravings of a madman...

Cheers,
Viktor
 

[Tim Perrett]

+1 Viktor. In troubled economic times such as these, its in the
business interest to run as efficiently as possible - in short, more
productive programmers... what you said is bang on.

Cheers, Tim

[Erik Engbrecht]

I think you need to be able to quantify the risk versus reward for your clients.  You should also be able to tell them how you mitigate some of that risk.  For example, a lot of custom software is delivered in a half-baked state.  If you deliver a half-baked product, and then move on to the next project, critical issues could go unaddressed for months while your client searches for another Scala developer (or other developer of sufficient caliber to learn Scala).

 

I don't think I'd recommend Scala/Lift for a project with less than three full or near full time developers.  That's pretty small, but it eliminates an amazingly large number of projects.  I would expect one of them to be sufficiently skilled (and motivated) to be able to contribute patches to the Scala library and to Lift.  I would also expect that person, and one additional, to be very good at mentoring.  The third would just need to be smart and open minded.

 

If anyone finds assembling teams like this easy, I would like the contact information for your recruiter, so he can find me some people, too.

 

Having multple people mitigates the bus risk.  Hiring really good people can take months, so you basically have to always have someone in the wings.  Having someone who can fix underlying problems in the library and framework mitigates (but does not eliminate) the "new technology" risk.

 

Given a team like that, I think they could achieve great, great things with Scala and Lift.  I think it would be significantly lower risk than a comparable Java or .NET project, especially one done with a mediocre team (or the common hero + legion of Java Joes).

 

I think scaling up a large team with Scala would be hard due to recruiting and training, but as a language I think (don't know) the Scala is probably one of the best languages out there for large scale development.  But I don' t think it is quite mature enough yet.

--
http://erikengbrecht.blogspot.com/

[Josh Suereth]

I'd also like to say you should pick a technology that meets your goals.  Lift/Grails/Django/Rails/Seam/JSF/Spring/Struts (etc..) have their own quirks and if you try to deviate too far from the "paradigm", you'll run into them quickly. 

For me, (so far) Lift is really amazing at doing quick ajaxy websites that have multiple components on each page.  If you're programming one of these style websites, you start to realize the power right away (big win with the CometActors). 

I would argue if your application needs to be developed quickly, and you want to do *anything* with Comet, Lift is the only way to go.  It took me a day to read enough documentation and play around before I had a working Comet-based widget in my pages.  It would have taken (much) less time if I hadn't been trying to communicate with EJBs on my app server.

Anyway, after coming from Grails, Spring and raw Servlets + ExtJS,  I'd like to say this: "Make sure your framework/tools help you do your work, and that can only be determined by you!"   Web frameworks are not interchangeable.  Find one that suits your needs.  Lift provides a new perspective and a lot of power, but if you deviate from its design too far you will run into quirks (like any other framework).  I think lift has a good "stretch" factor, which is another reason why I've chosen it for my current assignment.


Anyway, hope that helps from someone who's just started using Lift for production code.
-Josh

[Marius]

+1

Let's not forget that Scala is growing more and more may Java people
are looking for alternative maybe because they are bored of anonymous
classes, dubious oversold design patterns, stereotypes and coding
cliches. Of course a language purely by its existence do not solve
these problems BUT Scala provides fantastic ways and really innovative
paradigms ... this will attracts passionate programmers. A while ago I
was reading some articles from Joel on Software (http://
www.joelonsoftware.com/) about perils of Java schools ... I guess most
of you read it as well. I think there is some fundamental truth ...
many Java programmers (if I may call them so) learned some <Java
syntax> without understanding the core of the language and most
importantly the platform (i.e. class loading, concurrency problems, gc
not to mention the very language specification) ... so many things are
simple with Java and makes people just not to think anymore ... Scala
on the other hand "forces" you to think really hard sometimes to solve
problems extremely elegantly ... again these kinds of thing really
attract good programmers ... but of course it will take time.

At the beginning Lift was an excuse for me to learn Scala .. nowadays
it's much much more then that. I love it that almost every-time I'm
coding in Scala I learn new things ... how cool can this be!

Br's,
Marius

[David Pollak]

I force all my clients to use Lift and Scala. :-)

My experience with bringing other people onto Lift and Scala projects is pretty positive.  Anyone who is polyglot (speaks Java + Ruby, C# + Java, Ruby + JavaScript, etc.) seems to be just fine with Scala.  The folks who only speak Java seem not to do so well with Scala.

Lift requires throwing away some assumptions... but so does Rails, TurboGears, etc.  But, once you get into the Lift paradigm, you should be very productive.

So... what are the risks to your client?

• You get hit by a bus?  Arrange with Tyler or me or Viktor or someone else on the list to be your backup.  I'm the backup for a number of Scala projects.  I get one call saying "If so and so disappears, can you take over the project?" and that's that.  In 18 months of saying "I'll be the backup" I've never been called on.
• You have to bring other people onto the project?  It's not different than any other project with a new framework.  There's little risk in choose Ruby or Grails... there's a similar low risk with choosing Lift.

Folks in the SAP community chose Lift for the ESME project.  If they're doing Lift and Scala, why should your client worry?  The folks at Twitter love Scala and say so publicly.  If the hipster Web 2.0 folks are using Scala, you gotta figure there'll be a bunch of Scala lovers popping up in Web 2.0 land.

My biased thoughts.

Thanks,

David
 

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Warren Henning]

On Thu, Oct 23, 2008 at 2:43 PM, David Pollak
<feeder.of...@gmail.com> wrote:
> The folks at Twitter love Scala and say so publicly.

Off-topic: are you at liberty to discuss the extent of Scala usage at
Twitter? What, if anything, can you tell us?

Did they replace Rails with Scala/Lift?! :D

Warren

[David Pollak]

On Thu, Oct 23, 2008 at 2:47 PM, Warren Henning <warren....@gmail.com> wrote:

On Thu, Oct 23, 2008 at 2:43 PM, David Pollak
<feeder.of...@gmail.com> wrote:
> The folks at Twitter love Scala and say so publicly.

Off-topic: are you at liberty to discuss the extent of Scala usage at
Twitter? What, if anything, can you tell us?

http://groups.google.com/group/scala-base/web/TwitterOct2008.pdf
 

Did they replace Rails with Scala/Lift?! :D

Warren