wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kirk Israel" <k...@kisrael.com>
Subject Re: best practice for a header component with links defined by the page
Date Sat, 01 Sep 2007 11:48:09 GMT
On 8/31/07, Scott Swank <scott.swank@gmail.com> wrote:
> I will not argue against Lisp.  The paucity of Lisp/Scheme/Haskell
> within professional software development is criminal.  That is why,
> for example, we will be seeing continuations in Java 7.

Heh, even though the idea goes so far, that reminds me of the hint of
Lisp that lives in Perl's list/array syntax, i.e. $foo =
That then reminds me of an odd syntax asymmetry in mostly all (I think
"Algol-derived", though I may be getting that wrong, in practice I
tend to think of it as "C-derived") languages: functions take multiple
arguments but return a single value... sometimes I wish I could do
something like Perl's

($foo,$bar,$baz) = func();
sub func{
 return (1,2,3);
in Java. Maybe though my reluctance to, say, write a class the solely
exists as a bundler / wrapper class for the multiple values I would
want to return ties into my lack of grace in turning to inner
classes... one-off classes feels a bit like "needlessly multiplying
entities", and while as Igor points out reusable-ness is at best a
happy by-product of good OO, it's so often touted and taught as a
benefit that I have trouble shaking that feeling.

I confess, with the academic Lisp I've had, I have a hard time
grasping how you would do many simple tasks within the paradigm (and
not shoehorning the mentality of other languages into the syntax.) I'm
always worried I'll end up with something like my brief academic stint
with Prolog, the assigment was, given basic parent/child relationship
definitions, construct rules for determining grandparent/aunt/uncles
etc. The core of it was easy enough, but the best the professor (whom
I admire greatly) could come up with to weed out duplicates was an
ungainly, procedural-looking hack.

To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

View raw message