My Andreas Reply
Last updated at 2:40 pm UTC on 16 January 2006
Hi andreas
I was polemic, you are right. I wanted to get people react.
I wanted to know the point of view of other people. And to get reaction I
have to push hard. So thanks for your remarks they made me thinking.
I will try to get these discussions on a wiki because I like them.
> So fundamentally there is no difference whatsoever between @ and {} - both
> are parsed constructs and both have specific rules.
You are right again ;) I said it in the wrong way. is parsed as a binary
but does not have a specific parseNode.
I started to wrote a pretty printer and was really wondering why we have {}
Then I checked the code and found that I could send caseOf: to any object ;(
and I was really trying to see the benefit of this nice construct
>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+56 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?!
Right I meant purity.
So from a language design point of view what is the limit for having or not
a construct. I was really thinking that only := and ^ are the ones
necessary. Am I wrong?
Then the question stays the same why only {}? This is the same in VA and VW
why #[] for byte. But in VW community there is no freedom, you buy a stuff
and you accept it.
> 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
I'm not sure in fact.
Is there a way to express literal Array differently (by sending messages)
than #()?
With purity in mind should not be a construct something that cannot be
created or having the same runtime behavior.
Because I was wondering when I write $a and Character with: 'a'
this is different from the compiler point of view? At least in VW
the second one is evaluated at every method invocation while the first one
is stored into the method stack frame.
I would like to know if I'm wrong: if we consider the creation of object
#() and Array new are different expressions (not equivalent) because
one always create objects will the other not.
{} and Array new are the same
Character with: 'w' and $w are different
Is it not the way to distinguish what can be created the same way from
things that cannot?
>
> #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:[
> ...
> ].
We can write bad stuff with anything.
I was more into trying to getting rid of this ad-hoc, single and specific
macro-expansion. I was wondering why during the five years I program in
Smalltalk I did not need it, nor the people I know working in VW.
> 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).
Oh sure I'm not saying that we cannot write ugly code with ifTrue.
I found in C++ application a single method of 5000 (yes 4 zeros) named
create button, or a complete parser 600 lines only made with if statement.
In Smalltalk I think that the fact that the lenght of a method is limited at
least in VW is a good thing. I also saw really crazy method in objectstudio
applications based on {{}{}{}}
> #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?
Been compatible could be a concern but I do not consider that deviating is a
problem when this is needed.
> 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)
>> 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! ;-)
I respect C++ because you can redefine operator and even
- > if I'm not wrong, the goal was to allow people to express what they want,
I respect and I'm ready to pay the price of Smalltalk on the autel of purity
(where something I would like to have operators, private...). After solution
in Java are in the middle of nowhere and are stupid.
My point was just to illustrate that I can deal with no operator in
Smalltalk if this is for simplicity and/or purity. So as soon as I program
in Smalltalk I accept this fact because this design makes life simpler for
the compiler, the programmer (sometimes not the designer)...
Thanks for the time you send arguying with me.
I think that I know now why I do not like {} ;)
