lack of contributors
Brian Rice
water at tunes.org
Wed Apr 5 08:13:01 PDT 2006
On Apr 4, 2006, at 5:05 PM, Waldemar Kornewald wrote:
> Brian Rice wrote:
>>> I already tried to promote it. Most people shy away from complex
>>> syntax. That was the reason for my earlier mail suggesting to at
>>> least remove all this "@(... traits)" stuff and reduce the use
>>> of ugly chars like "#!@%$&`|".
>> Somehow I doubt you are introducing this to people who would find
>> Slate naturally appealing. You also have an aggressive resistance
>> to Smalltalk syntax, which is likely to be a hidden undercurrent
>> in any way that you communicate about it.
>> [...] You just don't like Smalltalk syntax. Admit it. It's
>> describable on one page of paper for Squeakers, and yet you're
>> making this big deal about it. It's a syntax that 12-year-olds
>> can learn. Don't be such a stubborn person.
>
> Oh, please stop talking about this "you don't like Smalltalk" stuff.
Fine.
> I just see that there are a few issues, but no syntax is perfect:
>
> (x < 5) /\ (x > 9) ifTrue: [...].
> vs
> (x < 5) \/ [x > 9] ifTrue: [...].
>
> and
>
> x < 5 ifTrue: [...].
> vs
> [x < 5] whileTrue: [...].
>
> I'm not suggesting to drop Smalltalk syntax. I do love the fact
> that it forms nice sentences which makes code highly readable. I
> just think that we can improve it (mostly with an IDE). I spent
> much time on thinking about alternatives, but Smalltalk has the
> best syntax I've seen. I hope that the issue is closed now.
Brackets to denote lazy / repeatable evaluation is some kind of
problem? Why?
> What I wanted to say is that the syntax *can* be described in a few
> sentences (especially if you are talking to programmers), but the
> current manual blows it up too much. This is what I wanted to fix.
> Also, I wanted to make the front page and other website content
> understandable without having studied computer science...really, a
> few years ago I would not have understood *one word* (and you were
> talking about twelve-year-olds...).
Well, yeah, again it's a REFERENCE, which means it's only there to
tell you exactly what Slate does in technical terms. You guys need to
write the tutorials.
>> Uh, that is not the purpose of the infogami, and I am not going to
>> do that. If anything, the infogami was started at least partly
>> because the wiki was unavailable. In fact, I am going to stay
>> away from it and let it be user-driven.
>
> I would have placed it on the wiki, but I still don't have access
> to tunes.org and an IBM site. My IP range (89.*) seems to be
> blocked (I switched to a new ISP...). Maybe I can get around this
> somehow.
It's not blocked by the wiki.
> Matt Revelle wrote:
>> For example, listing the pros and cons of prototyping is helpful to
>> new users, but suggesting alternative implementations on the same
>> page
>> is just going to confuse them.
>
> I just wanted a place to put suggestions on and do some planning.
> This will be removed and cleaned up after everything has been
> discussed. Later, this should become part of the website, anyway.
Even so, try to fix the technical access problem, not pollute someone
else's work.
--
-Brian
http://tunes.org/~water/brice.vcf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060405/ebeb1e66/PGP.pgp
More information about the Slate
mailing list