Liftweb vs Wicket ?

1,692 views
Skip to first unread message

David Bernard

unread,
Nov 9, 2007, 5:37:28 AM11/9/07
to liftweb
Hi,

I don't want to start a war/troll, I just ask the taste/opinion
(Eelco ?) about :
scala /liftweb vs scala / wicket vs java /wicket.
In wich context do you use/prefer liftweb against wicket ?

Thanks.

Viktor Klang

unread,
Nov 9, 2007, 7:18:05 AM11/9/07
to lif...@googlegroups.com
I had a look at wicket and I'd say I'd rather get chlamydia than use it.
 
-Viktor

 

Daniel Green

unread,
Nov 9, 2007, 8:18:12 AM11/9/07
to lif...@googlegroups.com
The brevity of the Scala/Lift combination is hard to match. Although, the best thing about lift is its community. If you come to a place where you're up against the wall with a wicket limitation, all you can do is submit a feature request and hope for the best. We, on the other hand, are constantly using the ideas from our community's members to improve lift. In the time I've been on this list I don't believe I've seen any ignored issues or requests.

If you do chose lift, then let me be the first to welcome you to the community :-)

David Pollak

unread,
Nov 9, 2007, 9:56:26 AM11/9/07
to lif...@googlegroups.com
Morning,

On 11/9/07, David Bernard <dwa...@free.fr> wrote:

Hi,

I don't want to start a war/troll, I just ask the taste/opinion

Asking for information is, IMHO, not trolling.  It's hyper-important for folks to understand the strengths and weaknesses of the tools they choose to use.  I love exploring the strengths of other web frameworks and learning about how to make lift better.  There's perhaps only one web framework (Struts) that I think has no redeeming value.  All the others have things that we can learn from to improve lift.

(Eelco ?) about :
scala /liftweb vs scala / wicket vs java /wicket.
In wich context do you use/prefer liftweb against wicket ?

Wicket is hindered by Java.  There are just so many things one can do with Scala that take enough lines of Java code that it makes it impractical to use Java.  For example, present a "select" that when clicked, updates the user's birth year (in AJAX, not a form)

val years = ((currentYear - 100) to currentYear).toList.reverse.map(y => (y.toString, y.toString)) // build the pull-down of years
ajaxSelect(years, Full(user.birthYear.toString ), res => user.birthYear(toInt(res)).save)

The building of the list of years is 1 line... that'd be at least 5 in Java.  The presentation of the AJAX Select and the corresponding, stateful, callback is another line.  I've bolded the callback to make it clear how easy it is to create the callback.

Lift's OR mapper is much simpler than Hibernate (although one can use Hibernate with lift).  The value of simple is if your schema is small and easy to manage (like most Rails apps on the planet), then having a simple tool to map to your DB is the best bet.

On the other hand, the are more tools for Wicket.  There's much better documentation for Wicket.  Wicket's more mature.  Wicket APIs are changing less frequently.  There's a much larger pool of talent that you can hire with Wicket skills.  There are Wicket books.

If I had a project to do and wanted to deploy on the JVM (there are a ton of reasons to deploy on the JVM), my close second choice to lift would be Wicket.

My 2 cents.

Thanks,

David
 

Thanks.





--
lift, the secure, simple, powerful web framework
http://liftweb.net

David Bernard

unread,
Nov 9, 2007, 10:48:56 AM11/9/07
to liftweb
Thanks, for replies.

FYI, In the planned application, I'll not use RDBMS but xml files as
persistance + a basic cache, ORM features aren't important for me. I
already have a wicket prototype, but the buzz around scala, attract
me. (I started learn scala 5 days ago vs 10 years for java)

There is risk to switch, he is why I ask complementaries tastes/
opinions.

Eelco as wicket's commiter, what is your tastes (don't find it or your
blog) ?

David Pollak

unread,
Nov 9, 2007, 11:44:37 AM11/9/07
to lif...@googlegroups.com
David,

Scala has the best XML support of any language I've ever seen. If
you're doing XML, switching to Scala seems like an amazingly low risk
choice.

Thanks,

David

Eelco Hillenius

unread,
Nov 9, 2007, 1:07:59 PM11/9/07
to lif...@googlegroups.com
> > I don't want to start a war/troll, I just ask the taste/opinion
>
> Asking for information is, IMHO, not trolling. It's hyper-important for
> folks to understand the strengths and weaknesses of the tools they choose to
> use.

+1

> > (Eelco ?) about :
> > scala /liftweb vs scala / wicket vs java /wicket.
> > In wich context do you use/prefer liftweb against wicket ?
>
> Wicket is hindered by Java.

Yes. Several people of Wicket are very interested in Scala partially
because we regularly bump our heads against Java's limitations. Btw,
we're not thinking about making a port or anything like that.

There's an other side to this though, and that's tooling. I find
Scala's IDE support so far next to useless. It is great that Scala is
statically typed, but half of why static typing is great is the fact
that this makes your code easy to explore and refactor. And leveraging
Java and it's tools has been one of the driving design goals behind
Wicket (whereas most alternatives seek declarative/ dsl solutions).

> Lift's OR mapper is much simpler than Hibernate (although one can use
> Hibernate with lift). The value of simple is if your schema is small and
> easy to manage (like most Rails apps on the planet), then having a simple
> tool to map to your DB is the best bet.
>
> On the other hand, the are more tools for Wicket. There's much better
> documentation for Wicket. Wicket's more mature. Wicket APIs are changing
> less frequently.

And that's good and bad.

In my experience with a few open source projects, the early stages -
when creativity flows freely, and you don't have to spend every other
email defending why your documentation sucks - are the most exciting,
and it is when you'll have the best community quality-wise. Much like
startups vs established companies I guess. I'd say, enjoy it while it
lasts and make damn sure you're building up a great team/ community
:-)

Eelco

Eelco Hillenius

unread,
Nov 9, 2007, 1:09:12 PM11/9/07
to lif...@googlegroups.com
Well, sorry for being defensive but...

On Nov 9, 2007 5:18 AM, Daniel Green <octob...@gmail.com> wrote:
> The brevity of the Scala/Lift combination is hard to match. Although, the
> best thing about lift is its community. If you come to a place where you're
> up against the wall with a wicket limitation, all you can do is submit a
> feature request and hope for the best.

? Wicket has one of the most active user lists around (more active
than any other web framework, including RoR for instance, see the
rankings on Nabble), an IRC channel where on a typical day between 30
and 70 people will hang out, including many team members, and lots of
other stuff. I believe that if you get stuck, Wicket is probably one
of the best frameworks to use.

Also, Wicket is set up pretty modularly I believe, so if there are
bits and pieces you don't like/ get stuck with, you can generally
replace them. There are three different Ajax implementations for
instance.

> We, on the other hand, are constantly
> using the ideas from our community's members to improve lift. In the time
> I've been on this list I don't believe I've seen any ignored issues or
> requests.

I don't think Wicket has that many either, but you have keep in mind
that Wicket by now is used in a ton of production systems, in articles
and books etc, so we can't just keep changing our minds about things.
That's actually a lesson to learn from Tapestry, which is like a
complete new framework every new release. Users hate that.

> If you do chose lift, then let me be the first to welcome you to the
> community :-)

It's great to see that the community is building up nicely here.

Eelco

Eelco Hillenius

unread,
Nov 9, 2007, 1:29:42 PM11/9/07
to lif...@googlegroups.com
> I don't want to start a war/troll, I just ask the taste/opinion
> (Eelco ?) about :

:-) Darn, I should have picked a nick.

> scala /liftweb vs scala / wicket vs java /wicket.

Frankly, I haven't played around enough with liftweb to know. The main
reason I'm lurking here is because I'm interested in stuff... Scala
and web frameworks being somewhere on the top of my interest list
currently.

There are a lot of things I like about Lift so far. It picks out the
things of other frameworks I personally like (statefulness,
modularization, static typing, secure by default) but (so far) it
doesn't get too crazy with others (like scaffolding, which I've
personally always found a non-issue tbh).

> In wich context do you use/prefer liftweb against wicket ?

I'd have to use it in anger first. It looks like Lift is very
expressive and flexible, and if Scala tooling (particularly support
for code navigation and refactoring) got better and there was
interoperability between Lift and Wicket (maybe in some distant
feature I could contribute to that if at all useful?) I can imagine
that we'd use Scala/ Lift for parts of the system I'm working on. But
for now I'm just lurking. :-)

Eelco

David Bernard

unread,
Nov 9, 2007, 1:58:16 PM11/9/07
to lif...@googlegroups.com
Thanks for your "long" replies.
They help me to decide, I'll continue to explore/learn scala and lift for the next 2 weeks (50%), then I'll choose.

About mailing-list:
* the wicket mailing-list is very active, and support of the wicket member very reactive, I don't know where you find time to support wicket (I'm ve got >5000 unread mails from the mailing-list),
blog,... "return of success"
* the lift mailing-list is more "human" in size, but with success...

Thank you, everyboby

Nathan

unread,
Nov 10, 2007, 1:57:18 PM11/10/07
to liftweb
David, if you have group of people coming from Java I would be worried
about the culture shock of them leaving the solid ground of Java +
whatever IDE they're accustomed to. Not only are refactoring
(occasionally) and compiled navigation (very often) useful, but a
veteran Java team is a lot more likely to run off screaming when faced
with the current state of Scala tools than, say, a group of Ruby
programmers would be. If it's just you, then I'm sure you know what
you can handle!

About the component architecture, I want to say that my recent
experience at a new job (hi Eelco!) has shown me a system so deeply
invested in its web components that, if Wicket weren't there for the
infrastructure, they absolutely would have needed to make a full
component system in-house. Obviously that's not most web apps/sites,
but if the one you're planning is to have a lot of modularity,
customization, and moving parts then I can't recommend Wicket strongly
enough. But nothing anyone can spout off should make the decision for
you. It's more about spending a few weeks using each (if the size of
the project can justify that investment) and going on instinct.

As for chlamydia I gratefully haven't had the experience, but they say
that good antibiotics will clear it right up.

Nathan

Viktor Klang

unread,
Nov 10, 2007, 2:19:51 PM11/10/07
to lif...@googlegroups.com
On Nov 10, 2007 7:57 PM, Nathan <nat...@technically.us> wrote:

David, if you have group of people coming from Java I would be worried
about the culture shock of them leaving the solid ground of Java +
whatever IDE they're accustomed to. Not only are refactoring
(occasionally) and compiled navigation (very often) useful, but a
veteran Java team is a lot more likely to run off screaming when faced
with the current state of Scala tools than, say, a group of Ruby
programmers would be. If it's just you, then I'm sure you know what
you can handle!

Java developers are so dependent on IDE features because Java is so inherently flawed that they feel insecure when facing a language with much lesser need for IDE-support.

I am strongly against creating features just because competition has them.

I think we need to just be patient and understanding of Java developers moving to Scala, step by step they will realize that they do not need crutches to be able to walk.

Best regards
-Viktor
 

Steve Jenson

unread,
Nov 10, 2007, 2:58:49 PM11/10/07
to lif...@googlegroups.com
On Nov 10, 2007 11:19 AM, Viktor Klang <viktor...@gmail.com> wrote:
> On Nov 10, 2007 7:57 PM, Nathan <nat...@technically.us> wrote:
> >
> > David, if you have group of people coming from Java I would be worried
> > about the culture shock of them leaving the solid ground of Java +
> > whatever IDE they're accustomed to. Not only are refactoring
> > (occasionally) and compiled navigation (very often) useful, but a
> > veteran Java team is a lot more likely to run off screaming when faced
> > with the current state of Scala tools than, say, a group of Ruby
> > programmers would be. If it's just you, then I'm sure you know what
> > you can handle!
>
> Java developers are so dependent on IDE features because Java is so
> inherently flawed that they feel insecure when facing a language with much
> lesser need for IDE-support.
>
> I am strongly against creating features just because competition has them.
>
> I think we need to just be patient and understanding of Java developers
> moving to Scala, step by step they will realize that they do not need
> crutches to be able to walk.

Not to start anything but, in my experience, people who are too afraid to leave
their IDEs aren't much good in a pinch.

I choose scala and lift because they give me a serious advantage ala
'Beating the Averages'[1].

Steve
[1]: http://www.paulgraham.com/avg.html

Eelco Hillenius

unread,
Nov 10, 2007, 3:29:57 PM11/10/07
to lif...@googlegroups.com
> Not to start anything but, in my experience, people who are too afraid to leave
> their IDEs aren't much good in a pinch.

It's not about being afraid, nor is it about having shiny wizards and
drag and drop goodies like IDE bashers commonly imagine. It is about
the productivity boost you get from navigating through code quickly,
things like code completion (saves key strokes and typos and it makes
it easier to explore code), refactoring, documentation hoovers, etc.

I find it amusing that people argue for strong typing, test first
programming etc, but with the same breath diss other tools (IDEs)
which sole purpose it is to make programmers more productive. I think
you beat the average by taking the whole enchilada into account...
language, tooling, process, etc.

Eelco

Eelco Hillenius

unread,
Nov 10, 2007, 3:37:59 PM11/10/07
to lif...@googlegroups.com
> Java developers are so dependent on IDE features because Java is so
> inherently flawed that they feel insecure when facing a language with much
> lesser need for IDE-support.

Scala is in lesser need of say refactoring tools, incremental
compilation and code completion for instance? Nonsense; 'need' is
subjective, but I think it is safe to say that such tools would
increase productivity quite a bit.

I'm always wondering where such hostility comes from. Is Smalltalk
flawed because tooling plays an important role? IDEs aren't exactly a
new idea.

> I am strongly against creating features just because competition has them.

Yeah, that's the worst reason to adopt new features. Unfortunately
something that happens quite a bit with Java frameworks. It doesn't
mean though that you have to reject anything that competition has just
for the sake of it.

Eelco

Nathan

unread,
Nov 10, 2007, 4:20:46 PM11/10/07
to liftweb
>Not to start anything but, in my experience, people who are too afraid to leave
>their IDEs aren't much good in a pinch.

Whether they are or not, sometimes those are the people you have to
work with. I'm not trying to say what's better, or ideal. I just
thought it might be relevant to D.B.'s decision. Plus I refuse to be
started. ;) "Tooling" just doesn't get me going as an argument.

Nathan

Randall R Schulz

unread,
Nov 10, 2007, 4:30:21 PM11/10/07
to lif...@googlegroups.com
On Saturday 10 November 2007 11:58, Steve Jenson wrote:
> ...
>
> Not to start anything ...

Hmm...

> ... but, in my experience, people who are too

> afraid to leave their IDEs aren't much good in a pinch.

What sort of "pinch" would that be? Would you say the same about a
machinist who was reluctant to work without a lathe? A carpenter
without a saw? A microbiologist without a microscope? A electrical
engineer without an oscilloscope? A gardener without a trowel?

Tools are what distinguish intelligence from its absence. Professionals
are those who know well how to use the tools of their profession as
well as the capabilities and limits of those tools.

Eschewing tools to prove your tough just shows you're foolish.


> ...


Randall Schulz

David Pollak

unread,
Nov 10, 2007, 4:32:19 PM11/10/07
to lif...@googlegroups.com
On 11/10/07, Steve Jenson <ste...@gmail.com> wrote:

On Nov 10, 2007 11:19 AM, Viktor Klang <viktor...@gmail.com> wrote:
> On Nov 10, 2007 7:57 PM, Nathan <nat...@technically.us > wrote:
> >
> > David, if you have group of people coming from Java I would be worried
> > about the culture shock of them leaving the solid ground of Java +
> > whatever IDE they're accustomed to. Not only are refactoring
> > (occasionally) and compiled navigation (very often) useful, but a
> > veteran Java team is a lot more likely to run off screaming when faced
> > with the current state of Scala tools than, say, a group of Ruby
> > programmers would be. If it's just you, then I'm sure you know what
> > you can handle!
>
> Java developers are so dependent on IDE features because Java is so
> inherently flawed that they feel insecure when facing a language with much
> lesser need for IDE-support.
>
> I am strongly against creating features just because competition has them.
>
> I think we need to just be patient and understanding of Java developers
> moving to Scala, step by step they will realize that they do not need
> crutches to be able to walk.

Not to start anything but, in my experience, people who are too afraid to leave
their IDEs aren't much good in a pinch.

I totally agree with this.  I pretty much fire anybody who can't write code without an IDE.  Someone who can't be productive with vi/emacs is worthless (using up budget, management time, equity, and air) and probably shouldn't be coding for a living.

Folks may point out that I primarily use Eclipse for my development.  That's true, but I can (and frequently do, especially for large scale refactoring and code beautification) use emacs.  Also, the benefits of Eclipse' incremental compilation combined with JavaRebel ( http://www.zeroturnaround.com/javarebel/) make for a very nice "change code, reload page" development experience.  One of these days, I'll write some code that watches file changes and kicks off fsc on the changed files, but today's not that day.

However, Nathan's right in that there are a lot of these "I can't code without method name completion and automatic refactoring" people making a living calling themselves programmers.  Over the long term, lift is going to have to cater to them.  Over the long term, lift and Scala are going to have to be as IDE friendly as anything else out there.  I suspect that there'll be some cool Scala/Eclipse-related news in the upcoming months.

In the near term, I'm expecting that lift's target market is the Java developers looking for something better group... many of which are going over and using Rails.  I hope to keep them on the JVM and closer to Java than JRuby via lift.  I'm also working on positioning for lift that's related to creating online collaborative applications... something that's very hard for any framework to do well... buy easier when you've got solid Comet support and internal plumbing for messaging (Actors.)

Thanks,

David
 

I choose scala and lift because they give me a serious advantage ala
'Beating the Averages'[1].

Steve
[1]: http://www.paulgraham.com/avg.html

Steve Jenson

unread,
Nov 10, 2007, 4:46:03 PM11/10/07
to lif...@googlegroups.com
I wasn't dissing IDEs. I own a copy of IntelliJ. I was dissing bad programmers.

Daniel Green

unread,
Nov 10, 2007, 4:52:21 PM11/10/07
to lif...@googlegroups.com
> It is about the productivity boost you get from navigating through code quickly,
> things like code completion (saves key strokes and typos and it makes
> it easier to explore code), refactoring, documentation hoovers, etc.
In my experience, the major time sink is having developers who,
although they do not fully understand the system, get by with command
completion until there are so many holes in the ship that they can't
bucket the water fast enough.

Yes, a sculpture's beauty may have minimal correlation with the
quality of tools used, and you should always use the right tool for
the right job, /but/ a sculpture made from and by horse dung, will not
brave the test of time.

David Pollak

unread,
Nov 10, 2007, 4:54:13 PM11/10/07
to lif...@googlegroups.com

I read this after I made my previous post.  I agree that a good IDE is a productivity boost.  The question for me in choosing team members is not the ceiling (it should be as high as possible and folks should have the tools and systems that maximize their effectiveness), but the floor.

Right now, the floor for Scala and lift is pretty high.  In the long run, that floor has to get pushed down.  In the mean time, folks like me and Steve would rather be coding with people we can count on to be able to build a fire without a windproof lighter and fire paste (see http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html)

Thanks,

David


Eelco

http://liftweb.net

Daniel Green

unread,
Nov 10, 2007, 5:01:03 PM11/10/07
to lif...@googlegroups.com
> I wasn't dissing IDEs. I own a copy of IntelliJ. I was dissing bad programmers.
>
I got you. I also, as I'm sure others do, think that certain languages
force you to be that "bad programmer" or at least write "bad" code. I
wont throw any names about as this thread is already digressing.

To jump back on topic, I don't think that IDEs should even be in the
Lift/Scala vs Wicket/Java discussion as in both you still have
* The frills: code completion, syntax highlighting, and auto indentation
* Breakpoints, debuggers, profilers, etc.

However, with Lift/Scala, debugging can be a bit easier as, if in
doubt, you can open up an interpreter with the classpath set to your
project and manually manipulate your webapp.

David Bernard

unread,
Nov 10, 2007, 5:08:35 PM11/10/07
to lif...@googlegroups.com
Thank you everyboby about the precisions and risk with tools :)
Hi already fight with the buggy eclipse plugin (sometime highlight, sometime not,...)
Currently completion isn't important => learn/browse the api
I juste finish the rewrite of the maven-scala-plugin (in java).

About the project, I'm alone and the goal of the project have some similarity with thoses of David Pollak (same target, ~ project assistant).

David Pollak

unread,
Nov 10, 2007, 5:11:47 PM11/10/07
to lif...@googlegroups.com
On 11/9/07, Eelco Hillenius <eelco.h...@gmail.com> wrote:

In my experience with a few open source projects, the early stages -
when creativity flows freely, and you don't have to spend every other
email defending why your documentation sucks - are the most exciting,
and it is when you'll have the best community quality-wise. Much like
startups vs established companies I guess. I'd say, enjoy it while it
lasts and make damn sure you're building up a great team/ community
:-)

Community is an interesting thing.

I think that communities are like gardens... they result from the original seeds and the ongoing tending.

I don't think that the Rails community will ever be a nice place to hang.  It was started with a bunch of seeds that are very loud and it's never quieted down (except for the occasional choke-chain yank when the more rabid in the community go overboard [ e.g., the Rails vs. Seaside flamewars.])

The Squeak and Seaside communities are very nice places to hang.  People are warm, helpful, inviting, and respectful (and they tend to ignore those who are not.)

The Scala community has many of the same attributes of the Squeak community.  There's a nice blend of academic and business members.  There's healthy debate that's oriented towards learning and improving Scala.

The lift community inherits much of the Scala community's goodness.

I am working hard to plant the seeds of welcoming all people into the community (welcome Yariv... I've been lurking on the Erlyweb list for so long... it's good to see you in the lift list)... of active debate... of putting thoughts on the table... of listening to lots of perspectives... of working towards the goal of making lift better... of hearing people out... of disagreeing with ideas while preserving the respect for the holders of those ideas... of analysis before conclusion... of being the kind of place that will attribute smart, caring, exciting folks.

From what I've seen of the Wicket community, it fosters many of the same ideals.  The jQuery community does as well.  The folks who started those communities and the folks that tend the communities have keep the environment nice for the everyone.

I hope in one year, two years, five years... and more... that the lift community continues to grow in a way that tends to the seeds I've planted.

Thanks,

David

Eelco

http://liftweb.net

David Pollak

unread,
Nov 10, 2007, 5:31:57 PM11/10/07
to lif...@googlegroups.com
On 11/10/07, Randall R Schulz <rsc...@sonic.net> wrote:

On Saturday 10 November 2007 11:58, Steve Jenson wrote:
> ...
>
> Not to start anything ...

Hmm...

> ... but, in my experience, people who are too
> afraid to leave their IDEs aren't much good in a pinch.

What sort of "pinch" would that be? Would you say the same about a
machinist who was reluctant to work without a lathe? A carpenter
without a saw? A microbiologist without a microscope? A electrical
engineer without an oscilloscope? A gardener without a trowel?

Sorry... can't let this one go...

It's the difference between the builder that takes a day off because his nail-gun is broken and the builder who picks up a hammer and keeps banging.  Which would you rather work with?

It's the surveyor who can't get the job done because the GPS signal is being blocked by trees and the surveyor who gets out his calculator and figures out the triangles.

The folks that can't do it without the most advanced tools are not the ones you trust in a pinch.  The folks who can do it when the tools are limited are, in my experience, the ones who can make best use of all the tools are their disposal.  They also have the motivation and the dedication to stick it out.

Tools are what distinguish intelligence from its absence. Professionals
are those who know well how to use the tools of their profession as
well as the capabilities and limits of those tools.

That's exactly right.  And the really excellent professionals are the ones that can tell you the history of their tools and what other kinds of tools lost out and why (I have a friend in construction and he can tell you the complete history of all kinds of earth moving equipment... he's the guy I want running the huge excavator because he know how dirty moves... he knows the difference between dry dirt and wet dirt... he knows to look at the weather reports months back if he's digging deep because the moisture on the surface is different from the moisture 3 or 4 feet down, etc.  And, when his big machines are not available, he can do it with small machines, it just takes longer.)

Eschewing tools to prove your tough just shows you're foolish.

I didn't hear Steve eschewing tools.  Working with Steve for a while has shown me the skills he has a variety of tools.  What I heard him say was that people who are ineffective without the best and most advanced tools are less reliable than those who can use the tools at their disposal.

Okay... it might finally be out of my system.

Thanks,

David

> ...


Randall Schulz


http://liftweb.net

Randall R Schulz

unread,
Nov 10, 2007, 6:30:49 PM11/10/07
to lif...@googlegroups.com
On Saturday 10 November 2007 14:31, David Pollak wrote:
> On 11/10/07, Randall R Schulz <rsc...@sonic.net> wrote:
> > On Saturday 10 November 2007 11:58, Steve Jenson wrote:
> > > ...
> > >
> > > Not to start anything ...
> >
> > Hmm...
> >
> > > ... but, in my experience, people who are too
> > > afraid to leave their IDEs aren't much good in a pinch.
> >
> > What sort of "pinch" would that be? Would you say the same about a
> > machinist who was reluctant to work without a lathe? A carpenter
> > without a saw? A microbiologist without a microscope? A electrical
> > engineer without an oscilloscope? A gardener without a trowel?
>
> Sorry... can't let this one go...
>
> It's the difference between the builder that takes a day off because
> his nail-gun is broken and the builder who picks up a hammer and
> keeps banging. Which would you rather work with?

The analogy is false. That's what I'm trying to convey.


> It's the surveyor who can't get the job done because the GPS signal
> is being blocked by trees and the surveyor who gets out his
> calculator and figures out the triangles.

And which of these is an apt analogy for what happens in software
development? GPS could (in principle) fail. Power tools can (and do)
break. But software has no analogy or counterpart for this class of
failure. What kind of error could fell an IDE but not Emacs or Vi? And
should such a failure exist, would it not demand resolution before work
continued?


> The folks that can't do it without the most advanced tools are not
> the ones you trust in a pinch.

That's that word again. What are these "pinches?" Why should
extraordinary circumstances (the "pinch") dictate the people we choose
for our teams? Unless I misunderstand the notion of "pinch" (namely,
that it's an rare or extreme circumstance), it's _not_ that basis for
choosing the members of a software development team. I'm peeved by the
common tendency to rely on extreme circumstances (the "pinch") to
dictate the criteria by which we choose our software engineers. Design
and coding require are and thoughtfulness, not snap judgements.

As an aside, I wonder if you would want to use CPUs or other chips that
were released or developed under these "pinch" situations? I would not.
It's a recipe for failure.


> The folks who can do it when the
> tools are limited are, in my experience, the ones who can make best
> use of all the tools are their disposal. They also have the
> motivation and the dedication to stick it out.

I don't see any connection between reliance on tools and determination.
I, too, find that a key ingredient in success is sheer determination.
Determination and resourcefulness. But one must also have the
meta-level ability to examine whether one's determined efforts might be
futile and to conclude, when appropriate, that a reappraisal, detour or
new approach should be adopted.

I guess what I'd look for is a person who uses the sophisticated
capabilities of, say, an IDE to its fullest but who also knows when a
simpler tool (grep, strace, netstat or ps, e.g.) is the appropriate
one. But note, this is not the same thing as rejecting someone who has
an overall reliance on an IDE.

And as another, rather abstract, aside, I note, too, that there's a big
difference between the synthetic (IDE or editor, e.g.) and the analytic
(debugger, e.g.) tools.

But to denigrate IDEs or those who rely upon them is foolish.


> > Tools are what distinguish intelligence from its absence.
> > Professionals are those who know well how to use the tools of their
> > profession as well as the capabilities and limits of those tools.
>
> That's exactly right. And the really excellent professionals are the
> ones that can tell you the history of their tools and what other
> kinds of tools lost out and why

And how does that knowledge relate to one's ability to perform their
duties? Does it help me to know that once upon a time the field names
in C language structs all resided in a single namespace and that there
could be only one offset associated with a given field name, regardless
of how many structs contained a field with that name? I don't think so.


> (I have a friend in construction and
> he can tell you the complete history of all kinds of earth moving
> equipment... he's the guy I want running the huge excavator because
> he know how dirty moves... he knows the difference between dry dirt
> and wet dirt... he knows to look at the weather reports months back
> if he's digging deep because the moisture on the surface is different
> from the moisture 3 or 4 feet down, etc. And, when his big machines
> are not available, he can do it with small machines, it just takes
> longer.)

Yes. Dirt as metaphor for software...

As humans, we're drawn to metaphors from the physical realm, but
software _is not physical_. It's dangerous to use fluidic, mechanical
or even electrical analogies when reasoning about software or the
process of creating software. It simply is not subject to the same kind
of processes, especially failure modes. (Though through an fluke of
linguistics, software is, in fact, 100%, purely mechanistic.)


While I rail at the "my way or the highway" attitude of so many IDEs
(or, to be more precise, their developers), I find them indispensable
aids to development.

If only they didn't think that everyone hated typing...


> ...
>
> David


Randall Schulz

Steve Jenson

unread,
Nov 10, 2007, 7:40:32 PM11/10/07
to lif...@googlegroups.com
On Nov 10, 2007 3:30 PM, Randall R Schulz <rsc...@sonic.net> wrote:

> > It's the surveyor who can't get the job done because the GPS signal
> > is being blocked by trees and the surveyor who gets out his
> > calculator and figures out the triangles.
>
> And which of these is an apt analogy for what happens in software
> development? GPS could (in principle) fail. Power tools can (and do)
> break. But software has no analogy or counterpart for this class of
> failure. What kind of error could fell an IDE but not Emacs or Vi? And
> should such a failure exist, would it not demand resolution before work
> continued?

Ok, I started this with my stupid comment so I hope I can finish it
with a better one.

Advanced tools are fine. If there was a good scala debugger, I would use
it and I would encourage other people to use it and I would write wiki docs
on how to use it with lift. I would never begrudge anyone using tools
they like and that work well for them.

I'll use an example instead of an analogy.

When I worked at Google, we had a complicated system of network shares
and caches (like many rapidly growing companies do). When a network
glitch would occur, all the IDEs would freeze (mine included) as they had
files open on these shares. Emacs would freeze too, trying to use the
network TAGS files.

These problems would occur with the worst timing: trying to fix the live site,
for instance. Thankfully we could just fire up emacs -q (or vim or
what-have-you) and keep working. There was no equivalent for our IDEs.
There was no way to tell them to not touch the network shares.
If any of my coworkers were the type who couldn't manually perform a
build or VCS branch/merge this would have been a big problem in
these pinches.

> > The folks that can't do it without the most advanced tools are not
> > the ones you trust in a pinch.
>
> That's that word again. What are these "pinches?" Why should
> extraordinary circumstances (the "pinch") dictate the people we choose
> for our teams?

It's not that you want a single oddball event to dictate who you hire, it's that
you want extraordinary people when you are working in an extraordinary
environment. Companies like Google and most startups live from one
extraordinary moment to the next and you need people who are as dynamic
as the environment but who can keep a level head and still produce
quality work.

> I guess what I'd look for is a person who uses the sophisticated
> capabilities of, say, an IDE to its fullest but who also knows when a
> simpler tool (grep, strace, netstat or ps, e.g.) is the appropriate
> one. But note, this is not the same thing as rejecting someone who has
> an overall reliance on an IDE.

I think you nailed it on the head.

> But to denigrate IDEs or those who rely upon them is foolish.

I agree and it wasn't my intention. Sorry for all this everybody.

Best,
Steve

Randall R Schulz

unread,
Nov 10, 2007, 9:01:50 PM11/10/07
to lif...@googlegroups.com
On Saturday 10 November 2007 16:40, Steve Jenson wrote:
> ...

>
> Ok, I started this with my stupid comment so I hope I can finish it
> with a better one.
>
> ...

>
> I'll use an example instead of an analogy.
>
> When I worked at Google, we had a complicated system of network
> shares and caches (like many rapidly growing companies do). When a
> network glitch would occur, all the IDEs would freeze (mine included)
> as they had files open on these shares. Emacs would freeze too,
> trying to use the network TAGS files.

And does such a glitch compromise your deployed systems? Obviously not,
or Google's services would be far less reliable than they are.


> These problems would occur with the worst timing: trying to fix the
> live site, for instance. Thankfully we could just fire up emacs -q
> (or vim or what-have-you) and keep working. There was no equivalent
> for our IDEs. There was no way to tell them to not touch the network
> shares. If any of my coworkers were the type who couldn't manually
> perform a build or VCS branch/merge this would have been a big
> problem in these pinches.
>
> > > The folks that can't do it without the most advanced tools are
> > > not the ones you trust in a pinch.

But tell me, is this about software engineering, or is it about system
maintenance? Should I hire software engineers who not only can design
and implement software systems, but who can (and will) also accommodate
these unpredictable failure events? Are you willing to tell your
candidates that they must take a beeper or a cell phone to bed with
them, since a problem in the systems for which they're responsible
(whether it's a hardware problem, a problem in software they didn't
write or something else beyond their control) might demand an immediate
response from them?

Why is this sort of thing a criterion for software engineers?

And if we're just talking about a problem in the IT infrastructure in
the office where the engineer works, why should these individuals be
responsible for problems that originate outside their purview?

Basically, I think this is just a manifestation of developer machismo.


> > There's that word again. What are these "pinches?" Why should


> > extraordinary circumstances (the "pinch") dictate the people we
> > choose for our teams?
>
> It's not that you want a single oddball event to dictate who you
> hire, it's that you want extraordinary people when you are working in
> an extraordinary environment.

Right. "All the children are above average."

Oh, god. Are you one of those Libertarians? Heaven help us...


> Companies like Google and most startups
> live from one extraordinary moment to the next and you need people
> who are as dynamic as the environment but who can keep a level head
> and still produce quality work.

And what does this have to do with choice of tool?


> ...
>
> Best,
> Steve


Randall Schulz

Contact 42

unread,
Nov 11, 2007, 12:11:39 AM11/11/07
to lif...@googlegroups.com

> Java developers are so dependent on IDE features because Java is so
> inherently flawed that they feel insecure when facing a language with
> much lesser need for IDE-support.
I love vi.....but when programming java, I am most productive in
eclipse. Not knowing the java API's off by heart or all the class/method
names of your current code base does not make you a worthless programmer.

No language needs an IDE, but dissing developers dependence on helpful
IDE's sounds a bit defensive. I was planning on retorting with a "at
least we have one"...but I don't feel totally in the "we".

Once again, I love vi. I actually use the vi plugin with eclipse, but i
would not use vi standalone (even with the java plugins) to code a java
project if i had the choice. It's not about the IDE, it's about
productivity. It's about getting what's in your head down into code as
quickly and as efficiently as possible.

Just another opinion.

Huy (another interested lurker)

Derek Chen-Becker

unread,
Nov 11, 2007, 12:29:56 AM11/11/07
to lif...@googlegroups.com
David Pollak wrote:
> I totally agree with this. I pretty much fire anybody who can't write
> code without an IDE. Someone who can't be productive with vi/emacs is
> worthless (using up budget, management time, equity, and air) and
> probably shouldn't be coding for a living.
Ouch. I've done a fair amount of coding with Emacs but I'd have to say
I'm definitely more productive in Eclipse. Code completion seems to be
the whipping boy for this thread; I can see that it can be a crutch, but
at the same time I use it a lot because it saves me from my fast but
often unprecise tpying. It's also useful for me because I do a lot of
jumping around between languages and sometimes it's hard to remember the
exact method/function name that a given language uses (was that
startsWith or beginsWith?). I'd like to think I'm a decent code
craftsman but perhaps my reliance on these tools is what keeps me from
being a great coder. In any case, the discussions on the list have been
very enlightening (and somewhat intimidating) and I hope to be able to
contribute more as I become more familiar with lift and Scala.

Cheers,

Derek


David Pollak

unread,
Nov 11, 2007, 12:57:42 AM11/11/07
to lif...@googlegroups.com


Derek,

Just to be clear, I'm not complaining about people who use IDEs.  I think that's fine.  I use them too.  I'm complaining about people who cannot code without them.

It's not an issue of faster or slower, it's an issue of not being able to code at all without an IDE that has code completion.  At this point, the Scala plugin doesn't have code completion, so anyone who can code Scala with Eclipse, emacs, vi, or whatever, doesn't fall into the category of "not being able to code Scala without code completion."

I have not questions about your skills.  You ask enough questions to indicate that you can analyze problems and write code.

I was doing a consulting contract a year and a half ago.  I was assigned a corporate coder at a well respected company to do a skills transfer to.  I was doing my prototyping in Ruby.  I was transferring the code and skills to the developer.  I bought him a copy of the Pickax book as a Ruby reference.  The code that I was writing was all small stuff (around 100 LoC per deliverable.)  The only Ruby classes it used were Array and Hash.  The developer was unable to modify the Ruby code (he could read it, he just couldn't change it.)  After pushing on the issue, he said "there's no code completion for Ruby, so I don't know what the methods are."  There are about 30 methods total on Array and Hash, so it's not a big memorization task, but he was being honest that he was unable to use the language because he didn't have the tool support he needed.  He was considered above average at his company, but he was unable to write a program beyond filling in blanks in a template that someone handed him.  That's not programming.

Just as a way to drive home the point about this developer (and the prototype that he represents) he and I went through the task of converting all the Ruby code to Java.  At one point, his task was to write a method that would take an object that implemented an interface and a file name, open the file, and call a method on the object for each line in the file.  His "readline" method looked like:

private String readLine() {
  String line = file.readLine();
  if (line == null) return "** END OF FILE **";
  return line
}

So in the loop, he was testing readLine() for equality with "** END OF FILE **"  I asked him why he did it that way.  He answered "I don't want any null pointer exceptions."

That's the level of folks I'm talking about.  I'm very certain that everyone who has posted to this list has better programming skills.

Thanks,

David


Cheers,

Derek




http://liftweb.net

davidrupp

unread,
Nov 11, 2007, 1:34:17 AM11/11/07
to liftweb
> I hope to keep them on the JVM

+1

> and closer to Java than JRuby

+0.5. "Close to Java" is not a particular goal of mine. But I've
contributed some code to the JRuby project, and it's (the project, not
my code; okay -- maybe both) not pretty. Don't get me wrong, I think
what the JRuby team is accomplishing is impressive, but they're
handicapped by implementing on top of Java. I have actually thought it
would be fun to do an implementation of Ruby in Scala, but I'm not
sure there's much point, ultimately. It would certainly be easier,
since Scala has native support for Ruby-ish constructs. But then I
figure, why not just use Scala?

Derek Chen-Becker

unread,
Nov 11, 2007, 8:00:16 PM11/11/07
to lif...@googlegroups.com
David Pollak wrote:
> Just as a way to drive home the point about this developer (and the
> prototype that he represents) he and I went through the task of
> converting all the Ruby code to Java. At one point, his task was to
> write a method that would take an object that implemented an interface
> and a file name, open the file, and call a method on the object for
> each line in the file. His "readline" method looked like:
>
> private String readLine() {
> String line = file.readLine();
> if (line == null) return "** END OF FILE **";
> return line
> }
>
> So in the loop, he was testing readLine() for equality with "** END OF
> FILE **" I asked him why he did it that way. He answered "I don't
> want any null pointer exceptions."
Wow. I guess I've never run into someone who was that lost. I'd want to
fire that guy, too... Most of the people at my company that I'd like to
fire have a different flavor of ignorance; one dev couldn't understand
why Hibernate wasn't working in this code (simplified):

public Customer getCustomerByPhone(String phoneNumber) {
Query customerQuery = session.createNamedQuery("customerByPhone");
customerQuery.executeQuery();

return new Customer();
}

And she did it *with* code completion. I guess now that I think about
it, I can see the big flaw in code completion that you and others have
implied: it allows someone with no understanding of the *concepts* to
still write code that compiles.

Cheers,

Derek

Contact 42

unread,
Nov 11, 2007, 9:48:13 PM11/11/07
to lif...@googlegroups.com
But to blame that on code completion ? you might as well blame java, or
the compiler, or the manager who hired the programmer, or the university
that taught the programmer.

Huy

Viktor Klang

unread,
Nov 12, 2007, 3:33:26 AM11/12/07
to lif...@googlegroups.com
On 11/12/07, Derek Chen-Becker <dchen...@gmail.com> wrote:

David Pollak wrote:
> Just as a way to drive home the point about this developer (and the
> prototype that he represents) he and I went through the task of
> converting all the Ruby code to Java.  At one point, his task was to
> write a method that would take an object that implemented an interface
> and a file name, open the file, and call a method on the object for
> each line in the file.  His "readline" method looked like:
>
> private String readLine() {
>   String line = file.readLine();
>   if (line == null) return "** END OF FILE **";
>   return line
> }
>
> So in the loop, he was testing readLine() for equality with "** END OF
> FILE **"  I asked him why he did it that way.  He answered "I don't
> want any null pointer exceptions."
Wow. I guess I've never run into someone who was that lost. I'd want to
fire that guy, too... Most of the people at my company that I'd like to
fire have a different flavor of ignorance; one dev couldn't understand
why Hibernate wasn't working in this code (simplified):

public Customer getCustomerByPhone(String phoneNumber) {
   Query customerQuery = session.createNamedQuery("customerByPhone");
   customerQuery.executeQuery ();

   return new Customer();
}
 
My eyes! The pain!

David Pollak

unread,
Nov 12, 2007, 12:57:07 AM11/12/07
to lif...@googlegroups.com
On 11/11/07, Derek Chen-Becker <dchen...@gmail.com> wrote:

I guess now that I think about
it, I can see the big flaw in code completion that you and others have
implied: it allows someone with no understanding of the *concepts* to
still write code that compiles.

I think this is a very good way of framing the issue.

It also, circles back to the TDD discussion because if you have tests that define the expected results of the code, it's a check that the combination of the person and the tool is doing the right thing.

 

Yariv Sadan

unread,
Nov 14, 2007, 2:36:10 AM11/14/07
to lif...@googlegroups.com

Hi :)

The Erlang/ErlyWeb community is nice as well :)

Yariv

Yariv Sadan

unread,
Nov 14, 2007, 2:39:13 AM11/14/07
to lif...@googlegroups.com


I think this is a great direction and this is one of the primary
reasons I was interested in using Erlang as a backend language for
webapps. Please dont take this as though I'm trying to start a
language war -- I'm just here to exchange ideas -- but from what I
know about Scala (which admittedly isn't much) I think it is missing a
few features that make Erlang really good for real-time apps (please
correct me if I'm wrong):

- Mnesia. You can store all session information in Mnesia, which is
transactional, distributed, runtime-configurable, and very fast.
Mnesia makes it possible to scale Erlang cluster by simply "adding
more boxes" and without changing code.
- Per-process heaps/garbage collection. This prevents freezing
processes for a long time during garbage collection sweeps. The folks
at Ericsson figured out this was necessary for soft real-time
performance.
- Hot code swapping. You don't want to lost client connections when
upgrading your code.
- Immutability. You never have to worry about synchronization issues.

Btw, did you know Vimagi lets you paint with your friends on a shared
canvas in real time? :)

One last note -- I'd rather use a good language with a bad IDE than a
bad language with a good IDE :)

Cheers,
Yariv

Alex Boisvert

unread,
Nov 14, 2007, 8:33:47 AM11/14/07
to lif...@googlegroups.com
Hi Yariv,

See comments below.


On 11/13/07, Yariv Sadan <yar...@gmail.com> wrote:
Please dont take this as though I'm trying to start a
language war -- I'm just here to exchange ideas -- but from what I
know about Scala (which admittedly isn't much) I think it is missing a
few features that make Erlang really good for real-time apps (please
correct me if I'm wrong):

- Mnesia. You can store all session information in Mnesia, which is
transactional, distributed, runtime-configurable, and very fast.
Mnesia makes it possible to scale Erlang cluster by simply "adding
more boxes" and without changing code.

In the Java world, the servlet container is responsible for session persistence and distribution.   So first and foremost this isn't a language issue as much as a runtime feature.   Most commercial and open-source J2EE application servers do a very good job at replicating sessions to transparently fail-over when one of the nodes goes AWOL.  To pick a specific solution, I'm very thrilled by Terracotta Sessions.   It's a drop-in solution for clustering on Tomcat/Jetty.

While I think Mnesia is very good (I've used it) and I like the language integration with Erlang, I think overall there are more alternatives in the Java/Scala world to fit different environments and needs.   This being said, I would welcome a Mnesia equivalent written in Scala!

- Per-process heaps/garbage collection. This prevents freezing
processes for a long time during garbage collection sweeps. The folks
at Ericsson figured out this was necessary for soft real-time
performance.

I'm not an expert on the topic but the JVM has had a state-of-the-art concurrent garbage collector for some time, reducing the freeze times to minimal amounts.  I would tend to think that network latency and instantaneous bandwidth availability are greater concerns than GC freeze in real-world deployments, although I don't have any measurements/statistics to back this up.

- Hot code swapping. You don't want to lost client connections when
upgrading your code.

Hot-code swapping is possible via JPDA and now the (much better) JavaRebel product.

- Immutability. You never have to worry about synchronization issues.

This is a design choice that Scala leaves up to you, and I think that's a good thing.  You can mix and match mutable and immutable objects, and use whichever you find better for the job.   Interestingly Scala walked this line very nicely and did not make trade-offs to favor on side over the other.    For instance, you can use case classes, restrict yourself to using vals instead of vars, and use the actors library to achieve code that's strikingly close to the Erlang model, yet sometimes more flexible and succinct thanks to object-orientation, implicit conversions, and other Scala language features.    Language-wise, the only thing we're really missing at this point is something comparable your smerl library for meta-programming in Scala :)

Btw, did you know Vimagi lets you paint with your friends on a shared
canvas in real time? :)

Yes, it's very, very cool and I think the Lift community would welcome a friendly faceoff where we could implement and compare the same application written in both Scala/Lift and Erlang/ErlyWeb.    I'm sure we would both benefit from this exercise, if only to understand the respective design goals and tradeoffs of each approach.


One last note -- I'd rather use a good language with a bad IDE than a
bad language with a good IDE :)

I believe most Scala early adopters share your feeling.  The good news is the Scala IDE situation is improving and we'll soon have an updated Eclipse plugin that will kicks some serious language *ss!     I'll leave the world-domination and sharks with laser comments to Viktor ;)

cheers,
alex

David Pollak

unread,
Nov 14, 2007, 9:04:44 AM11/14/07
to lif...@googlegroups.com
On Nov 13, 2007 11:39 PM, Yariv Sadan <yar...@gmail.com> wrote:
>
>
> Please dont take this as though I'm trying to start a
> language war -- I'm just here to exchange ideas -- but from what I
> know about Scala (which admittedly isn't much) I think it is missing a
> few features that make Erlang really good for real-time apps (please
> correct me if I'm wrong):

Thanks for sharing your thoughts and perspectives. And I really
appreciate it that you're spending the time on the lift list.

I look forward to sharing strategies with you and Alex (the author of
HaPPs) so we can all make the "functional web frameworks" better.

Just one thing...

>
> Btw, did you know Vimagi lets you paint with your friends on a shared
> canvas in real time? :)

Next time you pimp your application, please include a URL! :-)
http://vimagi.com/

Thanks,

David

Reply all
Reply to author
Forward
0 new messages