Stephane,
First of all, if you're making a pretty polemic proposal (I think not only I found your "examples" of {{}} etc. to be polemic and your last message just dumped more oil on the fire) then you shouldn't be surprised to get responses in a similar tone. Having said that, let me point out a few issues that you seem to be overlooking (note that I'm *not* trying to be polemic here, all of the examples I'm giving you are true to the point):
[Re: Difference between @ and {}]
There is a big different @ is a message not a parsed construct with specific rules!!!!!
Sorry, but that's wrong. @ (and all binary operators) are just that: Parsed constructs with specific rules. From a point of purety we don't need them. We could just write: (1 add: 2) times: (3 add: 4) and get exactly the same result that we get today from (1+2) * (3+4). So fundamentally there is no difference whatsoever between @ and {} - both are parsed constructs and both have specific rules.
[Re: Use of {}]
The construct is useful and widely used.
Widely in which code???? Where? more than OrderedCollection?
Counting all the references to OC comes up to 720 (on my system; your milage may vary) - and very many of them are used in a form that would not be equivalent to {}. Whereas the cumulative references to {} (note that you have to add all of the #braceWith: variants as well as #braceStream:) come out to 692. So the answer to "more than OrderedCollection?" is, yes, for constructing an immediate collection of Objects, {} is in fact more used than OrderedCollection. Again, I'm not trying to be polemic here - these are facts that you can count for yourself.
[Re: Looking for simplicity]
I thought that Smalltalk was looking for simplicity.
Simplicity and purety are two different things. "Simple" can mean different things to different people. Originally, Smalltalk was intended to be a language for kids (but, alas!, how far away has it gotten) and I don't think that kids who learn in school that 4+5*6 equals 34 will find it simple that Smalltalk evaluates this to 54. They might find it pure if they can comprehend the reasoning behind it ... but simple?!
[Re: The price we pay]
I like the simplicity of Smalltalk and I'm ready to pay the price to use convention for expressing private, dealing with operator by hand....
I think that is the real point. What price are we willing to pay. As I've said above (and as has been pointed out by other posters) we could theoretically live without a lot of constructs, including binary operators, $ for character creation, #() for literal array creation, etc. But we're simply unwilling to pay that price because we've got used to the convenience these expressions give us. If that is so, then your message comes down to two problematic points
#1: The ability to write horrible constructs That's certainly an issue but I don't think it's as bad as you're making it. Briefly glancing over some of the 672 methods that use brace construction I couldn't find any that used it in a truly ugly way. Which means that most people using the construct use it in the way it should be used. Ugly code can be written with many syntactical constructs, including, for instance: (a := b > 5 ifTrue:["doSomeThing"]) ifNotNil:[ ... ]. I find the above at least as ugly as some of your examples (note that the hidden ifFalse: branch will in fact evaluate to nil and the assignment in the expression doesn't help readibility either).
#2: Not being ANSI compatible Again, certainly an issue but for people who wish to write stuff that ports easily over to other dialects, they're not required to use this construct. As you have pointed out, there are alternatives and if one wishes to write easily portable code then he or she just has to pay the price. If not ... why pay it?
Cheers, - Andreas
PS. One last note which might be considered a bit polemic so it comes only after the actual message:
Having operators is useful too, I would like to have operators too because I prefer to type 2 + 3 * 6 than 2 + (3 * 6) and because this is MATH and MATH are right!
I hope you see my point.
If your point is that we should not have appropriate operator precedences, then I don't see it. I find absolutely nothing wrong with them. There are plenty of language (Prolog, for example) dealing with operator precedence pretty well and at the same time not restricting people to use only built-in operators. So actually I agree - I want operator precedences too! ;-)