Seaside on Squeak
Locked
12
12
 
|
Right, I see your concern. I'd argue that's a bad _use_ of
continuations! You can think of a (delimited) continuation as being some chunk of the call stack: a chunk that you may execute multiple times. So if the chunk of stack that you have says "set this mutex" and you run it three times, it'll set that mutex three times. If you throw the continuation away, that mutex never gets set. So this ends up being a discussion about side effectful code versus purely functional code: sincecontinuations means taking "take this bit of code, and run it 0 or more times" you naturally need to be careful of changing the state of things. You see the same when you use a continuation and a DynamicVariable (class name because I'm talking about the implementation details), where you end up with the DynamicVariable having an unexpected value. (In fact it's worse with continuations + DynamicVariable: they _cannot_ work sensibly together, which is why I've been pushing people towards my Control library, or to the #on:do: + #resume: idiom, both of which yield _delimited_ dynamic variables, which _do_ play nicely with everything.) frank On 15 January 2014 19:09, Chris Muller <[hidden email]> wrote: > I was talking about class Continuation and how its used in the context > of Seaside. In that context, I have observed, for example, a critical > block being entered prior to snipping a Continuation off the stack (to > be resumed later), thus leaving Mutex's on the stack stuck in their > wait state, and blocking subsequent requests. > > On Wed, Jan 15, 2014 at 11:23 AM, Frank Shearar <[hidden email]> wrote: >> No they don't. Continuations have nothing to with mutexes at all. I'm >> not sure that we're talking about the same thing when we say >> "continuation". >> >> When _I_ say "continuation" I mean, effectively, the call stack: it's >> the thing to which the result of the current activation record will >> return a result. You can thus consider a _delimited_ continuation as a >> chunk of stack. #on:do: delimits the stack using a primitive (19?). An >> _undelimited_ continuation is the entire call stack from the very >> beginning of a program. thisContext + all its senders is the closest >> we have to such a thing in Smalltalk: since all call stacks eventually >> hit nil, they're all delimited by _something_. >> >> And we use continuations _all the time_ in Smalltalk, or things that >> may be trivially expressed in delimited continuations: from a CS >> perspective delimited continuations and resumable exceptions are >> equivalent, in the sense that each may implement the other. >> >> frank >> >> On 15 January 2014 16:30, Chris Muller <[hidden email]> wrote: >>> Continuations are also bad because they leave Mutex's in their wait >>> state. That, alone, is a show-stopper for me for using continuations. >>> >>> On Wed, Jan 15, 2014 at 10:14 AM, Frank Shearar <[hidden email]> wrote: >>>> Yes, I know. But that just means that implementing a bad idea (modal >>>> dialogs) with some random piece of tech (continuations) is a bad idea. >>>> >>>> I thought you meant that continuations _implied_ something negative >>>> about UI design by their very nature. But it sounds like that's not >>>> what you meant. Which is good :). >>>> >>>> frank >>>> >>>> On 15 January 2014 15:56, Chris Muller <[hidden email]> wrote: >>>>> Frank, by my limited knowledge, the call: / answer API of Seaside used >>>>> a Continuation to allow a modal component to be rendered on top of >>>>> other components until #answer: is sent by one of the callbacks. That >>>>> provides stateless web-apps the ability to do desktop-like modal >>>>> "dialog" boxes that can return values to the calling component. >>>>> >>>>> On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <[hidden email]> wrote: >>>>>> On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote: >>>>>>>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote: >>>>>>>>> > Meh. Don't worry about it. Seaside is obsolete anyway. >>>>>>>>> >>>>>>>>> Really? I haven’t taken any interest in web development in ages; what’s >>>>>>>>> the replacement for Seaside? >>>>>>>> >>>>>>>> >>>>>>>> It's not that there's a replacement. It's more that the problem it solves >>>>>>>> isn't a problem anymore. Continuations were a brilliant way to manage apps >>>>>>>> that were basically dynamically generated web pages connected via links and >>>>>>>> forms. But Javascript runtimes have gotten way, way faster, more robust and >>>>>>>> more standardized in the last 10 years. Modern web apps are more of a >>>>>>>> client-server model: the UI rendering and interface logic is all done in >>>>>>>> Javascript running in the browser, and it communicates with the server by >>>>>>>> shuttling JSON back and forth over HTTP. In that sort of a system, >>>>>>>> continuations don't provide any benefit, and the drawbacks start to become >>>>>>>> significant. >>>>>>> >>>>>>> Continuations were never good for UI design anyway. Modal. >>>>>> >>>>>> I don't understand - what does UI modal-ness got to do with with >>>>>> continuations? (Or: the whole of Squeak is fundamentally built on >>>>>> continuations (Process, ContextPart).) >>>>>> >>>>>> frank >>>>>> >>>>> >> > |
|
|
In reply to this post by Chris Muller-3
On Wed, Jan 15, 2014 at 2:09 PM, Chris Muller <[hidden email]> wrote: I was talking about class Continuation and how its used in the context Well, that's a bug, but it's not a fundamental problem with continuations. |
|
|
In reply to this post by Colin Putney-3
Hi Göran, Colin: Can you elaborate a bit more what do you mean with "modern web* replacement for Seaside? I really have not found yet the utility of a tool as Amber, and I'm very interested in learn about what new ways of development Amber make more easy.
Thanks. 2014/1/15 Colin Putney <[hidden email]>
Saludos / Regards,
Germán Arduino www.arduinosoftware.com |
|
|
On Mon, Jan 20, 2014 at 6:55 PM, Germán Arduino <[hidden email]> wrote:
Well, a typical Seaside application is largely components. They render bits of HTML and handle callbacks triggered by the user's actions. They're UI; Seaside doesn't concern its self with model objects or persistence.
Amber does the same sort of thing. You have a tree of components that render HTML programatically, and react to user gestures. But instead of handling HTTP requests and producing responses, an Amber app runs in the browser. It updates the DOM directly and handles DOM events without a round-trip to the server. That allows the app to be much more responsive and eliminates the need for modal interfaces that Chris complained about. In that sense it's "modern."
On the other hand, I don't use Amber, personally. I don't mind writing Javascript directly, and I like to be able to use the really amazing Javascript frameworks that are out there—e.g. Angular or React. Also, performance matters on the web, and it's particularly difficult to get good frame rates on mobile browsers, so I find the layer of indirection that compile-to-Javascript introduces just gets in my way when it comes time to debug and optimize.
So I'd say that Amber is useful if you'd rather write Smalltalk than Javascript, or if you want to stick with the Seaside UI paradigm of components rendering and callbacks (although see React.js for a really neat take on that.) By moving the UI to the client-side it can produce better, more responsive interfaces, and compiling to Javascript is a common strategy these days. (See Dart, CoffeeScript, Emscripten, ClojureScript, Elm, GWT, etc). So it's not "obsolete" like Seaside. On the other hand, it doesn't feel "cutting edge" to me in the way that Seaside did when it was new and shiny. It's more about making web development comfortable for Smalltalkers.
Colin |
|
|
Thanks for you reply Colin!
2014/1/20 Colin Putney <[hidden email]>
Ah ok! I agree.
Yes, it's clear enough now, I agree with this vision. Anyway, moving all these stuff to the client is the new way to make the things, I know, but we still need to solve other important things, as persistence for example, and develop a complete system, involving different products (as SmalltalkHub for example that use Pharo, Mongo in the backend) sound a bit complicated to my work preferences. Cheers. Germán. |
|
|
In reply to this post by Chris Muller-3
Tim wrote:
>On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote: >> Meh. Don't worry about it. Seaside is obsolete anyway. > >Really? I haven’t taken any interest in web development in ages; what’s the replacement for Seaside? There is none. Client side javascript development is horrible. Nothing available that can be expected to have a significant market share 5 years from now. Stephan |
|
|
On Wed, Jan 22, 2014 at 8:02 AM, Stephan Eggermont <[hidden email]> wrote:
> Tim wrote: >>Really? I haven’t taken any interest in web development in ages; what’s the replacement for Seaside? > > There is none. Client side javascript development is horrible. Nothing available that can be expected > to have a significant market share 5 years from now. That's to be expected. Smalltalk is an obscure language from the 80s. It doesn't, and won't, have significant marketshare in any market. |
|
|
I am not a Seaside expert--and I am activelly trying to move away from web-development. If I may throw out a bit of advocacy here. I used to made my living doing "middleware" work in web development ( I still do some freelance PHP work to pay the bills). My specialty is getting data from the database to the web page for the designers to use, back through the business layer and to the database. I have used PHP and its frameworks: Zend, CodeIgniter, Java and its frameworks (which are pretty good) and the Microsoft stack (which I hate) By far the easiest to use for complex applications in that "middleware" stack is Seaside components. All you do is get a robust definition of what the use-case is and the application pretty much writes itself. Development time and maintenance are greatly reduced. I do see the trend towards Javascript by the young-uns out there--most developers do think in Algol afterall--which is fine, but it is really repeating the 70's all over again. It get's boring--same coding style, same frameworks to manage the short-comings..just blah. Once you "get" how to think in a non-algol language, there really is no going back--except for system level stuff near the metal where C is king. Jut my 2 cents. tty. On Wed, Jan 22, 2014 at 8:02 AM, Stephan Eggermont <[hidden email]> wrote: |
|
|
In reply to this post by Chris Muller-3
Colin wrote:
>That's to be expected. Smalltalk is an obscure language from the 80s. >It doesn't, and won't, have significant marketshare in any market. I was not thinking of smalltalk based javascript solutions. It’s the frameworks like angular, react I was referring to. Stephan |
Amber FTW! (Re: [squeak-dev] Re: Seaside on Squeak)
|
|
In reply to this post by tty
On 01/22/2014 03:51 PM, gettimothy wrote:
> I am not a Seaside expert--and I am activelly trying to move away from > web-development. > > If I may throw out a bit of advocacy here. > > I used to made my living doing "middleware" work in web development ( I > still do some freelance PHP work to pay the bills). > My specialty is getting data from the database to the web page for the > designers to use, back through the business layer and to the database. > > I have used PHP and its frameworks: Zend, CodeIgniter, Java and its > frameworks (which are pretty good) and the Microsoft stack (which I hate) > By far the easiest to use for complex applications in that "middleware" > stack is Seaside components. All you do is get a robust definition of what > the use-case is and the application pretty much writes itself. > Development time and maintenance are greatly reduced. > > I do see the trend towards Javascript by the young-uns out there--most > developers do think in Algol afterall--which is fine, but it is really > repeating the 70's all over again. > It get's boring--same coding style, same frameworks to manage the > short-comings..just blah. I am sounding like a broken record but: http://www.amber-lang.net As Colin has already said - writing a HTML5 app in Amber is very, very similar to how you write a Seaside app. You have proper components that can nest etc. You have a canvas that looks and behaves very much like in Seaside - although it actually operates directly on the DOM. And Amber is Smalltalk. You have browser, workspace, inspectors and even a debugger. But its not an interpreter - its a full compiling Smalltalk. Best way to see this if you have 2 minutes: 1. Go to www.smalltalkhub.com using Chrome. 2. Press ctrl-shift-j to get Javascript console. 3. Write "smalltalk.Browser._open();" and execute that. 4. Close javascript console and enjoy the Amber IDE (the old one though, the new Helios IDE is much slicker). 5. Click on the "Hub-Amber-Widgets-Users" package in the left side list. 6. Find ShLoginWidget class, look at the code. ...and yes, you can edit the method, save it, and see the effect immediately in the app! Just like Smalltalk. regards, Göran PS. You can use javascript libraries relatively transparently from Amber, no glue needed. As you may see jQuery is used in the Amber IDE without a single line of glue code. |
|
|
Thanks. If I ever delve back into web-work, I will give it consideration. cheers. tty On 01/22/2014 03:51 PM, gettimothy wrote: |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |