[Seaside] Seaside Thoughts & Questions

[Daniel Drasin]

Subject:  Re: Seaside - love it!
       Date: Sun, 27 Apr 2003 19:44:10 -0400
      From:  Daniel Drasin <dan at drasin.org>
        To:   Avi Bryant <avi at beta4.com>
        CC:   julian at beta4.com
 References:  1

Be happy to put them on the seaside lists - didn't know there was one.
(link?)  Thanks for all your thoughtfull responses...

Why java?  Well, here's the deal:  I agree with your feelings about
Smalltalk versus Java.  I too have used both quite extensively and
i know that i am significantly more productive in Smalltalk.  However,
i also know that Smalltalk's day in the sun as a choice for business
applications is over (i'm sad about it, but that's life).  When i 
have a problem to solve for a customer or my employer, Smalltalk is
not an acceptable language to use - that's just the lay of the land.
Some of it is unreasonable bias, but some of it is understandable -
Smalltalk developers are fewer and more expensive, Commercial support
is very thin, etc.  The long a short is, i'm going to have a business
problem to solve - and smalltalk is often not going to be part of
that solution space.  So, since i can't have what i want, what can
i get that contains some of the same benefits.  Hence Java - maybe
.NET will fill that place eventually.

As for commercial viability of Seaside for Java - you're probably 
right.  Very hard to sell any kind of product right now, let alone
one that dictates a paradigm shift.  However, just as water eventually
finds its way downhill, i think that if this approach was available
to Java developers, the productivity boosts would eventually get
noticed and there would be a signifant user community.  (In the same
way that Cacoon, Struts, and other Servlet alternatives became 
widely adopted when developers ran into the limitations of Servlets.)
So, i'd think open source would be the way to go - open source java
is a nice because it dances on the narrow line of acceptability for
projects (apache.org has been a huge help here)

I should also add that despite java shortcomings, it also has a lot
of good things too.  These mostly have to do with the fact that there
is a lot of people developing products for it etc.  Nevertheless, we
Smalltalkers complain about the obvious shortcomings of some of the
sun APIs, but there are also some good APIs.  (JXTA, Jini, and JMS
are some of my favorites...)

So, i hope that explains the "why java question."

See below for more...

Avi Bryant wrote:
> 
> On Sat, 26 Apr 2003, Daniel Drasin wrote:
> 
> > i'm not sure i understand the comment on continuations.  Do you
> > mean that they key is to be able to "rerun" a button press from a given
> > page (after going "back") to it?  [I'm guessing this is where the value
> > of continuations comes in over just using threads to store the stack -
> > threads being transient and going away after they are resumed].  Is that
> > it?  Or is there something more to it.
> 
> No, that's it.  The other half of that comment, however, was that even if
> you did give up on continuations, at a minimum you need one (suspended)
> thread per active session, which is quite heavyweight in the Java world
> (where threads usually map directly to OS processes).

Not anymore - virtuall all implementations do OS threads all do green 
(emulated) threads.  That makes the overhead per thread
pretty lower.  Obviously OS threads are more heavyweight, but they
have advantages too.  You can choose which to use when you start 
your java app.
 
> > Assuming that's true, i would think it would be a reasonable restriction
> > to "disable" the backbutton by expiring the pages.  (This was the
> > approach i took - actually had a dispatching servlet which made sure
> > the request came in the right order and if not, reset the user to the
> > right place - seemed like the only way to achieve part2 below to
> > make things work across UI paradigms...)
> 
> Well, I agree that it's a "reasonable restriction" in the sense that it's
> the best you can do given the technology available in, say, Java, and
> given a requirement to have a lowest-common-denominator system spanning
> several UI paradigms.  However, one of the things that's so *cool* about
> web UIs is the freedom given to you by the back button, and related
> features like being able to open a link in a new window/tab and so explore
> parallel paths.  If you watch experienced web users they hit the back
> button continuously, and although you can train them not to do this for a
> particular app, you're both annoying them and lowering their productivity.
> Taking away the back button is not something to be done lightly, even if
> the requirements of UI pluggability or JVM compatibility may outweigh this
> on occasion.

Well, i see your point, however i think that we should seperate the
"go back" functionality from the "back button" as implemented by 
browsers.  The problem with the backbutton in browser is that it
makes application coding very difficult - no matter where you are
in the application, then next user request may be for any action
on any page that they've ever seen regardless of whether they've
done it already (the classic is the double charge on your visa
bill from a shopping cart app...)  I prefer to have that functionality
mediated by the application.  So that if a user goes back to a page
and tries to proceed from there, i want my application to respond 
differently that when they were on the page to begin with (the
trivial case is to expire that page and say 'sorry', but you can
handle it much more gracefully if you want - unwind all state changes
and go on as the user requests.)  

Does that make sense?  I'm not saying get rid of the back button
functionality, i'm just saying get rid of the  way that web apps 
implement it which are disasters waiting to happen.

>  > As for the syntax in java question, there are a
> couple of solutions
> > 1. deal with inner classes, not so bad once you bite the bullet and
> > get used to them (the mind can block noise out pretty well after a
> > while)
> 
> When I write Java code, I use them constantly.  But I'm sorry, they *are*
> that bad, particulary when compounded by Java's horrific type system.
> Compare:
> 
> html textInputWithValue: person age callback: [:n | person age: n].
> 
> html.textInput(new Integer(person.getAge()), new Callback() {
>   public void takeValue(Object value) {
>     person.setAge(((Integer)value).intValue());
>   }
> });
> 
> Maybe your noise filters are a lot better than mine, but I find it real
> hard to pick out the content from that mess of syntax.  And making it
> clearer by introducing temp variables also makes it longer.  Pretty soon a
> simple render() method takes two pages instead of 3 lines.

agreed.  It's gross and annoying, but it's survivable.

> > 2. preparser.  This is becoming a popular java solution (xDoclet an
> > JAspect are good examples).
> 
> Been there, done that:
> http://www.cs.ubc.ca/labs/spl/projects/elide/
> 
> But adding an extra step to the already tedious edit/compile/run cycle is
> a pain, and these tools tend to get in the way of incremental compilation
> in any form, and they make debugging much harder, and...

Definately true on the debugging.  But if you're in the java world, 
that's life.  Large ant (read "make") scripts are the norm, so adding
one more line would be business as usual for java programmers.

> 
> > 3. java api.  Something along the lines of S-Expr could handle most
> > cases, i'd think.
> 
> Not sure what you mean by this one...
> 
> > 1. is probably the way to start (easiest), but 2. is probably the
> > right long term approach (which could of course be combined with
> > a solution to the continuation issue - since you could rewrite all
> > method calls...)
> 
> Yeah, Shriram Krishnamurti had a very interesting paper that rewrote Java
> code to get continuations, basically so he could add a back button to
> Swing apps (the subtitle was "Growing GUIs on Trees").

I'll have to check that out.  But i still think that all application
navigation should be mediated by the application (see above).


> > At any rate, the big benefit i've found in seaside is the avoidance
> > of request/response.  I think it would be a big hit in the java
> > space too.  Maybe someday...
> 
> Well, it's still an open question, and I do think every once in a while
> about trying to take what I've learned from Seaside and building a Java
> web framework - I do believe that I could do something that would blow all
> of the current frameworks out of the water.  What I'm certain of, however,
> is that *for me*, it would be a much less productive system than what I
> already have in Squeak.  Moving to the JVM and especially to Java as a
> language would be a collosal step down in almost every area I care about -
> so why expend any effort on a project that wouldn't increase my
> productivity?  The only possible justifications would be if it was either
> a viable commercial product or a high enough visibility open source
> project to bring some peripheral benefit.  I don't think the first is
> realistic these days, particularly given how saturated the "market" of
> Java web frameworks is, and I don't think I believe enough in Java as a
> platform to pull the second off (and besides, the niche Smalltalk market
> works out fairly well from a consulting point of view).
> 
> So ok, I've probably made it more clear than necessary why I'm not that
> interested in bringing this work to Java (unless, of course, someone were
> to pay me directly to do so).  Ignoring technical feasiblity, why does it
> appeal to you?

I definately understand your take.  If i'm doing my own projects, 
Smalltalk's very comfortable.

> > As for your comment on method names being an indirection, that
> > is absolutely correct.  However, in seaside those blocks can
> > contain arbitrary code and they are in a context to directly
> > refer to elements of the UI (rather than indirectly through
> > a mapping layer).  (That's the difference between refering to
> > the element with a tag and calling the method directly from
> > the block - getting rid of the context).
> 
> True.  But this sounds like a "the developer might shoot himself in the
> foot" problem.  Context is only harmful if misused; otherwise it's quite
> useful.

I've found that removing sharp edges is an important part of having
a framework.  But there's more to it than that.  The design i was
suggesting takes the binding out of code (embedded in the method
call in the context) and puts it into data (in a binding object).
Good pattern in general, but in this particular case its particularly
important because it can be introspected.  It's really just the 
Builder pattern in the end (which i've generally found preferable to
using straight code commands).
 
> > This indirection is key if you consider the distinction between
> > application intention and implementation.  Take the example of
> > a form, that you want to tell the user that they forgot to
> > enter some information.  You'd want to tell the UI element
> > (some sort of text element) to highlight itself.
> >
> >       (UI elementNamed: #textfield) highlight.
> >
> > In HTML, this would probably mean put a red *, next to it, in a
> > windows application, you'd have the widget flash.  Of course,
> > this abstraction could be implemented in a lot of ways - add the
> > "common" api to all UI elements, create wrappers, etc.  But the
> > key is the separation of application intention from UI implemenation
> > (which is what i was getting at).
> 
> Sure.  But this has nothing to do (AFAICT) with using named tags for
> elements.  In the example above, the text field could have its
> "highlighted"  property linked on creation to a #textFieldShouldHighlight
> method.  What I've learned (slowly - earlier versions of Seaside worked
> much like you describe) is that it's almost always more flexible and
> certainly more efficient to use the late binding mechanism built into
> Smalltalk - the message send - rather than to constantly invent new ones.
> Exactly how you apply this piece of advice differs from situation to
> situation, but it invariably leads to a better design in the long
> run, IMO.
> 
> > Be happy to - i'll clean it up a bit first ;-)  I'm not really happy
> > about how i had to hook into the system to get the information, so an
> > suggestions are welcome.  Also, i just threw some ideas into it in terms
> > of how to capture information, how long to hold on to it, etc. So again,
> > feedback always good.
> 
> Great, I look forward to seeing it.
> 
> By the way, why isn't this dicussion taking place on the Seaside list?
> There might well be some good comments from others as well.
> 
> Avi


-- 
	Daniel Drasin				
	dan at drasin.org				8612 Long Meadow Ct.
	(410)-461-6168				Columbia, MD, 21045