Newbie questions about Squeak and Seaside

>> Hi,
>> 1. I have an idea for a web application that involves a lot of custom
>> text processing logic. Is Squeak an acceptable environment for
>> implementing a real full-blown application? How is its performance  
>> for
>> common tasks compared to, say, Python, Ruby, and Common Lisp? Do I
>> need to shell out for VisualWorks or something in order to get
>> real-world work done?
>
> Well yes , for us at least.
>
> We use Squeak/Seaside in a commercial setting and the speed is  
> adequate.

>  You will have to try it out for your situation and see how it  
> performs. The biggest performance problem we have come across is  
> the speed of WeakArrays. We ended up working around the problem but  
> depending on your Seaside application you may not run into the  
> problem at all.
>
>>
>> 2. Do you always just edit one method at a time? Isn't that annoying
>> to have to click around so much? Do you always edit new stuff by
>> working on one method at a time in the debugger/browser?
>>
>
> I , personally,  like the default Squeak browser but there are  
> others. Have you looked at Whisker?
> http://www.mindspring.com/~dway/smalltalk/whisker.html
>
> The "one method at a time" approach makes it easier for me to find  
> what I need with minimal effort.
>
>> 3. I was playing with the counter example in Seaside and it appears
>> that continuation expiration is 600 seconds by default. Is the only
>> way to have user sessions last longer to simply increase the
>> expiration time? How do you do this for a real-world application?
>
> You session will expire after 600 sec of inactivity. Not simply  
> after 600 seconds. You are not this first person to have this  
> misconception. Maybe that config field should have a more  
> descriptive label ?
>
>
>>
>> 4. Do you people ever find forcing everything to be object-
>> oriented to
>> be restrictive? I think sometimes it would be as annoying as not
>> having any OO functionality in the language at all. I also think
>> having tons of 7-line methods is weird and unwieldy.
>>
>
> Again I like it. It was one of the big draws for me. Breaking  
> things into least common denominator bits allows for maxim reuse  
> and in the long term you will end up doing less work and not  
> reimplementing the same ting over and over.
>
> If you need something that feels more like a function you can use  
> the class side of the appropriate class (click on Class in the  
> object. Then you can ...
>
>     result := SomeObject doSomethingWith: anotherSometing
>
> Although in most cases you would most likely be better off doing
>
> result := anotherSometing withSomething: SomeObject.
>
> In either case I would suggest you give the OO nature of Smalltalk  
> a chance.
>
>> 5. Is Squeak good for building things where functional languages do
>> pretty well? Things like compilers and interpreters.
>
> I have not experience with building compilers and interpreters in  
> Smalltalk so someone else might be better suited to answer this  
> questions but I will give it a shot.
>
> I am not sure you would want to build a compiler in Smalltalk/
> Squeak unless you were targeting the Squeak VM. As far as  
> interpreters go I would see no reason why Squeak would do a fine job.
>
>>
>> I think the debugging and browsing tools are totally amazing (they
>> blow away everything else I've used, including SLIME for Common
>> Lisp/Emacs) but the actual editing itself sucks: I miss my Emacs
>> keyboard shortcuts terribly . The reason I'm learning Squeak is
>> because of Seaside, not the goofy "it's for
>> children"/games/multimedia/mouse gunk.
>
> I personally feel the games/multimedia/mouse "gunk" works to Squeak  
> detriment in the business world. I know the immediate visceral  
> reaction to Squeak by my colleges has been "you can't do anything  
> serious with that" and while I think I have proven them wrong the  
> initial hurtle took some time to overcome.
>
> I think Seaside it Squeak's chance to make it into the mainstream  
> but the interface could be a little more professional looking.
>
> Will
>
>>
>> Warren
>> _______________________________________________
>> Seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Rather than writing new OR mappers, you might look into GLORP.  The  
> community has been unusually active lately and lots of good  
> improvements have been made.
>
> On Thursday, August 24, 2006, at 11:30AM, William Harford  
> <[hidden email]> wrote:
>
>>
>> On Aug 24, 2006, at 1:05 PM, stephane ducasse wrote:
>>
>>>>
>>>> We use Squeak/Seaside in a commercial setting and the speed is
>>>> adequate.
>>>
>>> Can you tell us more?
>>
>> Sure.
>>
>> The page loads are around one second. My goal is to half that by the
>> end of the year but there are a lot of hurtles to overcome before I
>> can do that.
>>
>> The slowest part of the application is data access. I currently use a
>> OR mapping library that was written in a hurry (by me) and
>> unfortunately it suffers from poor design and kludgy code. You are
>> welcome to take a look at it but I ask that you don't hold it against
>> me :-) http://squeaksource.com/IOSPersistent.html .
>>
>> I have written another OR library, called REServe, that takes some of
>> the concepts I liked from IOSPersistent and implements them in a
>> much, much, much nicer fashion. Giving the developer better control
>> over how things are stored, cleaner code, the database is abstracted,
>> Smalltalk enumeration of the database,  PostgreSQL is supported, and
>> much more. I am convinced that the new library has a future and will
>> be releasing it to the public in the next couple weeks.
>>
>> If you are interested in having a look at REServe let me know. The
>> main reason for not releasing it yet it incomplete documentation and
>> tests.
>>
>> The current MySQL drivers for Squeak do not use Unix domain sockets.
>> I have not looked into Squeak support for Unix sockets on squeak but
>> if the MySQL drivers could be modified to access the server via Unix
>> sockets that would give our application a speed boost. Any
>> volunteers :-)
>>
>> WeakArray ; What can I say that has not already been said. I fear
>> that the implementation details of WeakReferences are currently over
>> my head and I would need a bit of education before I attempted making
>> finalization faster. I would really like to see this improved because
>> I currently have to work around the problem.
>>
>> I changed SeasidePlatformSupport #weakDictionaryOfSize: to read
>>
>>    ^ IdentityDictionary new: aNumber
>>
>> This means that our sessions grow until they are ended. It's not
>> ideal but it works.
>>
>> Instead of triggering the cleanup of expired sessions every n new
>> session/requests (I can't remember which) I run a reaper process that
>> checks every so often and cleans things up.
>>
>> We run a document management application and as such we create a lot
>> of WADocumentHandlers for thumbnails. WADocumentHandlers where not
>> getting cleaned up until we cleared all Seaside caches and for our
>> situation that was not reasonable. I changed WADocumentHandler so be
>> a sub instance of WAExpiringHandler and have it expire after a couple
>> hours (except for css files) and that seamed to keep our image size
>> down.
>>
>> Our image will get up to about 300MB. It runs on a server with 4G of
>> ram so for us thats acceptable.
>>
>> Our usage might not be typical. During the day we have 3-12 people
>> working in the application doing data entry as fast as the
>> application will go. Touching all parts of the application.
>>
>> Another thing we did that greatly improved speed pair down some of
>> the component creation.
>> Because components are not cleared after they are no longer
>> referenced because of the above changes creating > 12 components on
>> each page view was to much. To work around it I ask each model
>> #canRender. If #canRender answers true I send the model
>> #renderContentOn: html caller: parentComponet. The model can then
>> render it's self with out registering a component. While this is not
>> ideal it gets the job done.
>>
>> There are other things but thats all I can remember for now.
>>
>>
>>> Is the application visible on the web?
>>
>> The application is not public. If you are in the Toronto, ON or
>> Orlando, FL area I will be more than happy to demo the application
>> for you.
>>
>>>
>>>> At one point I did port my application to VisualWorks and the
>>>> speed was much improved but the price we were quoted was
>>>> unacceptable ($130,000/year).
>>>
>>> Indeed you were making money apparently or the sales were doing
>>> something wrong.
>>> you have also dolphin smalltalk :)
>>
>> We run on Linux and it's essential to our operations. I don't see
>> that changing anytime soon so unfortunately Dolphin is out of the
>> question.
>>
>> The VW sales person quoted me on number of expected users. She offer
>> no other quote even after I pressed for it. In fact she seemed almost
>> uninterested in our business. The price was 135 and that was that.
>>
>> Personally I would like to see Squeak become an industrial strength
>> platform. There is a lot of work to be done but there is also a
>> growing interest. I might be biased but the future looks bright for
>> Squeak to me.
>>
>> Enough of my rambling.
>> Will
>>
>> _______________________________________________
>> Seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>