[Seaside] A new critical blog discussing Seaside - Comment my blog

stephane ducasse stephane.ducasse at free.fr
Sat Apr 18 17:42:13 UTC 2009


On Apr 18, 2009, at 6:57 PM, Sebastian Heidbrink wrote:

> Hi Stef!
>> Just a side remark: seaside code quality is not equal to squeak-one.
>> So pay attention not to generalize too fast.
> It wasn't my intention to generalize.
> I'm no Smalltalk-Guru, but I think that I had very good Smalltalk  
> tutors past years. Many advices they gave me can be found in the two  
> books, which I always have around me. "Smalltalk with Style" and  
> "Smalltalk Patterns"... :-)
> I'm an absolute VASmalltalk (Visual Age) Guy and there are some  
> things, which I am missing in Squeak.

Me too :)

> Or let me better say, which I prefer and made my first steps in  
> Squeak quite hard. Most important thing was the possibility to  
> define methods public and private.

How do you do that in VA?
Because in squeak you could and the method was pvt....

> That makes life a lot easier when it comes to writing core or  
> framework classes, that need to be used by others. It helps me a lot  
> to hide class specific coding from coding that may be used by  
> others. Newbiees are much faster able to find out what the class  
> does or should do. When you start with a basic Squeak image you are  
> not really aware of public and private methods...
> But that doesn't lead me to blameing all Squeak or especially  
> Seaside to be bullsh..... they are different somehow to codings that  
> VW and VA users are used to. But the reason of that is the basis.
> It is a fact that many squeak codings usually access instance  
> variables directly, what makes some coding hard to read and to  
> understand.
> It's a fact, that coding conventions are more agressively assured in  
> industrial projects, than in open source projects, due to the fact,  
> that a lot more people get involved in those projects and those  
> projects may be overworked a lot more than commercial, critical  
> applications or frameworks.
> On the other hand I love to browse Squeak projects just because it  
> is often a good way, seeing other coding styles and algorithms,  
> where i can teach my self further.
> Even in Visual Age there are also a lot of classes, which don't  
> actually use accessors. But as Avi mentioned, these codings are  
> mainly old core classes and they have their root in early Smalltalk.  
> I have no idea, whether these codings are different to late 90'ies  
> coding due to performance reasons, or just a different philosophie  
> at that time.

In 1990 there was a dogmas about accessor.

> Anyhow, since I am programming Smalltalk, I read a lot discussions  
> about which coding style is better and which is not, but I never saw  
> a publication which made a performance test on different  
> implementation styles.

In VW and VA accessors should have nearly no impact since the jit  
should do a good job.

> I guess that one also has to keep in mind, that every SmalltalkVM  
> has it's own strength and weakness.
> Getting all this together in the SeasideCore might be impossible.
> But as far as I know the Seaside Team, they absolutely have an open  
> ear for improvements.
> Having other ideas/priorities and just limited sparetime for  
> following those improvments, is no arrogance.
>
>>
>> I know it since we are cleaning squeak in pharo http://www.pharo-project.org
>> there is still a lot of work but everyday this is getting better.
>> We already have a lot more tests than most of smalltalk  
>> distributions. :)
>> We will run SmallLint on all our packages...
>
> I use pharo and really appreciate your effords!
>
> Sebastian
>
>
>
> 	
> 		
> ___________________________________________________________ Der  
> frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>



More information about the seaside mailing list