[self-interest] simplicity

Michael Latta lattam at mac.com
Sun Jun 27 16:18:46 UTC 2004


On Jun 27, 2004, at 8:57 AM, Ian Woollard wrote:

> Jecel Assumpcao Jr wrote:
>
>> Normally we would be coming from the opposite direction - our first
>> attempts are much more complicated than needed. Einstein said "make
>> things as simple as possible, but no simpler".
>>
> I tend to think that that is always the way it goes. We first
> overcomplicate things, and the simplification results from spotting
> patterns.
>
> There's also the other problem- oversimplification.
>
> For example, Java forbids operator overloading, and yet the language
> itself uses it for Strings. For good expressibility for handling matrix
> multiplication or complex arithmetic it's nigh on essential.
>
> I think Self is guilty of oversimplification:
>
> a) no privacy/security
>
> b)

For the day and purpose it was designed for (1995 research) it was not 
a deficiency.  For modern times it is an issue if you want to be able 
to distribute components.  Applications are not an issue, as security 
is not a feature of applications, only components.  Even Java does not 
provide security for applications, only components.  Until such time as 
the OS hosts all user code on a VM that has security features, there is 
no security.  All we can do is make it harder to find the holes.

I would not look at Java as good language design, but it has one 
feature that is worth thinking about.  That is the ability to tag 
methods/classes with semantic tags like private, transient, 
synchronized, etc.  But, rather than having a fixed set that do a fixed 
set of things, I would like to see the language allow an extensible set 
that can be mapped to the language itself.  This would probably end up 
more like aspects in the application.  For JDK 1.5 they are adding 
"metadata" tags, which is extensible, but have no language semantics.  
They are just tags tools can use to manipulate the program after 
compilation.

>
>> I understood that to
>> mean the point of maximum joy.
>>
>>
>>
> With computer languages we are ultimately limited by the mythical man
> month concept- namely that there is no silver bullet to minimise
> software complexity and maximise productivity.
>
> I personally believe that at best with computer languages we can
> minimise the number of problems that we cause ourself, and supply
> libraries and language features for design patterns.
>
> Clearly to the extent that a language design forbids certain design
> patterns, that language has a deficiency.
>
> For example in C++ you can do things like:
>
> {
>      FileHandle f = open("/adirectory/aFile", open);
>
>     f << "I went to the zoo";
> }
>
> And the file may be automagically closed as f goes out of scope.
>
> But this is unreliable in Java/Self/Smalltalk- you don't know when the
> GC will get around to release it. I consider this to be a bug in these
> languages.

This is inly an issue if you rely on the garbage collector to close 
files (which most experienced programmers do not).  And the C case is 
far worse should you pass a pointer to "f" to another module that 
outlives the above code.  In any event this is not a language issue, 
but a library issue.

>
> This isn't apriori a question of destruction of the memory of variable
> f- if the language specification caused a special method to be invoked
> on the variable as it went out of scope then the appropriate behaviour
> could be obtained. The inefficiency may be easily optimised away by the
> compiler for the usual case of variables/objects that don't do anything
> in that case.
>
> There's lots of other things like that.
>
>> -- Jecel
>> P.S.: http://www.merlintec.com:8080/software/11 shows some of my
>> attempts to find that point, including regarding things such as
>> optional arguments and stuff
>>
>>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>




More information about the Self-interest mailing list