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.
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.
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) ?
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
+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
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
:-) 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
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
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
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!
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
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
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
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
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
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
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.
Eelco
http://liftweb.net
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.
About the project, I'm alone and the goal of the project have some similarity with thoses of David Pollak (same target, ~ project assistant).
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
http://liftweb.net
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
http://liftweb.net
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
> > 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
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
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)
Cheers,
Derek
Cheers,
Derek
http://liftweb.net
+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?
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
Huy
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();
}
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.
Hi :)
The Erlang/ErlyWeb community is nice as well :)
Yariv
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
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 :)
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