smalltalk evolution

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

smalltalk evolution

Kamil Tomsik
What's current state of squeak evolution?

I do get the idea of squeak as independent-smalltalk,
which CAN evolve without being fully compatible with the rest of st world
(which is IMHO the only way to deliver better language)

I've read few dozens of interesting proposals in here
(like prototypes and dropping array literals)

And while both being pretty interesting I would really like
to see smalltalk with [1 . 2 . 3] asArray syntax instead of ugly
and IMHO useless #(1 2 3)

Syntax should be further discussed, yes, at least because [1, 2, 3]
looks much better, but what's the chance of adopting something like this?

What's the chance of saying: "guys, we made mistake, #(1 2 3) have really
no advantage over blocks (except of performance), so let's drop it, let's
simplify the language, let's make it even easier to learn for newcomers."

Is something like this "part of plan"? Or is really the "make a new fork if
you consider it useful" the only way to go?

Because writing meta-program for transforming existing code shouldn't be
so hard. Also "dropping" something could be just part of "changelog", even  
with
appropriate convertor for legacy code. And I doubt that new fork could  
make it
through without massive marketing. Even squeak is poorly known.

Please do not take it as offense, ST is one of best languages I've ever  
encountered,
but every language can be even better, and we should try.

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Igor Stasenko
2011/5/31 [hidden email] <[hidden email]>:

> What's current state of squeak evolution?
>
> I do get the idea of squeak as independent-smalltalk,
> which CAN evolve without being fully compatible with the rest of st world
> (which is IMHO the only way to deliver better language)
>
> I've read few dozens of interesting proposals in here
> (like prototypes and dropping array literals)
>
> And while both being pretty interesting I would really like
> to see smalltalk with [1 . 2 . 3] asArray syntax instead of ugly
> and IMHO useless #(1 2 3)
>
why useless?
the #(1 2 3) are evaluated at compile time and then stored into
method's literals array.
While anything like
[ 1. 2. 3. ] asArray
will be evaluated at run time.
perhaps you meant another "useless" syntax, which is:
{ 1. 2. 3. }

which is equivalent to:
Array with: 1 with: 2 with: 3
?

> Syntax should be further discussed, yes, at least because [1, 2, 3]
> looks much better, but what's the chance of adopting something like this?
>

just try to evaluate
1,2,3
in workspace and you will see why this is not good idea.

> What's the chance of saying: "guys, we made mistake, #(1 2 3) have really
> no advantage over blocks (except of performance), so let's drop it, let's
> simplify the language, let's make it even easier to learn for newcomers."
>
[1. 2. 3.]
is not a literal.
it is a sequence of expressions, which should be evaluated when you
send #value to block, and there could be anything like:

[ self foo. self bar. self baz ]

now, how you propose to turn it into array literal?


> Is something like this "part of plan"? Or is really the "make a new fork if
> you consider it useful" the only way to go?
>
> Because writing meta-program for transforming existing code shouldn't be
> so hard. Also "dropping" something could be just part of "changelog", even
> with
> appropriate convertor for legacy code. And I doubt that new fork could make
> it
> through without massive marketing. Even squeak is poorly known.
>

Well, i don't think that changing the way how you represent array
literals could drastically change a smalltalk to make it more
appropriate for (put your favorite here).
I think you looking in wrong direction, because what is really makes a
difference is availability of modern and robust solutions and killer
apps, which makes your
language preferable to others.
I don't see how changing the syntax of array literals will make it
easier for appearance a new killer app.

> Please do not take it as offense, ST is one of best languages I've ever
> encountered,
> but every language can be even better, and we should try.
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Kamil Tomsik
It's not my idea, it was just interesting and I'd be glad to
see some evolution (even pink plane) of squeak. I do not
propose anything - but array literals just stink, they're
another concept, which IMHO could be implemented in the very
same way as control operators were.

My question was not about array literals, it was about
evolution of squeak - if something like this is at least planned?

Because I couldn't find any "long-process-plan".

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Kamil Tomsik
In reply to this post by Igor Stasenko
Sorry, I forgot about uselessness of array literals.

I simply don't see any use-case in which I'd like to
evaluate something in compile-time, it's feels to me
like another form of static state.

Are there any (major) advantages of array literals?
Something which couldn't be done without them?

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Frank Shearar-3
2011/5/31 [hidden email] <[hidden email]>:
> Sorry, I forgot about uselessness of array literals.
>
> I simply don't see any use-case in which I'd like to
> evaluate something in compile-time, it's feels to me
> like another form of static state.
>
> Are there any (major) advantages of array literals?
> Something which couldn't be done without them?

Yes: express array literals concisely, without having to mentally
strip out multiple occurences of "with:".

I use array literals all the time in my tests (of the {} variety), and
it makes (in my opinion at least) for much more readable tests.

Compare #(1 1 2 3 5 8 13) with Array with: 1 with: 1 with: 2 with: 3
with: oh no, Array doesn't actually have a message that takes 7
parameters.

More importantly though, we're quibbling about something that's not
very important at all when we could be figuring out how to address the
real problems that Squeak faces, such as modularity.

frank

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Igor Stasenko
In reply to this post by Kamil Tomsik
2011/5/31 [hidden email] <[hidden email]>:
> It's not my idea, it was just interesting and I'd be glad to
> see some evolution (even pink plane) of squeak. I do not
> propose anything - but array literals just stink, they're
> another concept, which IMHO could be implemented in the very
> same way as control operators were.
>
> My question was not about array literals, it was about
> evolution of squeak - if something like this is at least planned?
>

Right question contains half of the answer.
If you ask about language/system evolution in general, i think
you will get more extended answers.
Because array literals is really too little detail to care of.
One way or another, but you still need to provide a way how to
efficiently represent array literals in code.
And i don't see anything which could be so much powerful comparing to
existing syntax.
Some other languages have syntax constructs even for more complex
stuff: hash tables aka dictionaries.
Yes, syntax maybe ugly and looking weird, but nevertheless, it serves
its purpose: it provides a way to represent a hash table in source
code.

> Because I couldn't find any "long-process-plan".
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Frank Shearar-3
On 31 May 2011 16:04, Igor Stasenko <[hidden email]> wrote:

> 2011/5/31 [hidden email] <[hidden email]>:
>> It's not my idea, it was just interesting and I'd be glad to
>> see some evolution (even pink plane) of squeak. I do not
>> propose anything - but array literals just stink, they're
>> another concept, which IMHO could be implemented in the very
>> same way as control operators were.
>>
>> My question was not about array literals, it was about
>> evolution of squeak - if something like this is at least planned?
>>
>
> Right question contains half of the answer.
> If you ask about language/system evolution in general, i think
> you will get more extended answers.
> Because array literals is really too little detail to care of.
> One way or another, but you still need to provide a way how to
> efficiently represent array literals in code.
> And i don't see anything which could be so much powerful comparing to
> existing syntax.
> Some other languages have syntax constructs even for more complex
> stuff: hash tables aka dictionaries.
> Yes, syntax maybe ugly and looking weird, but nevertheless, it serves
> its purpose: it provides a way to represent a hash table in source
> code.

Oh, and let's not forget ByteArrays - #[1 2 3 4]!

frank

>
>> Because I couldn't find any "long-process-plan".
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

ccrraaiigg
In reply to this post by Frank Shearar-3

> More importantly though, we're quibbling about something that's not
> very important at all when we could be figuring out how to address the
> real problems that Squeak faces, such as modularity.

     Yup. How you can recommend a system in which there's no easy way to
share your work?


-C

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547




Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Kamil Tomsik
In reply to this post by Frank Shearar-3
Sorry, I do not agree on this - less concepts the language has,
the easier it is to "master".

I like smalltalk-way of control structures - it's just message send,
and literal arrays could be done in the very same way.

We don't have to sit down and wait until the next "big idea" will
appear, we can spend some energy for improving and cleaning current
state.

Have a look on Self and Newspeak (if you haven't already), there is a lot
of interesting stuff. While I don't like implicit receivers in Newspeak and
methods as slots in Self, those languages both have some points in  
simplicity.

I really believe the right way of evolution is in simplifying
and finding more powerful concepts. And dropping/replacing less powerful  
ones.

But... once more again - is there any long-process-plan for squeak?
Is already anything planned (on the language-level)? I'd like to read  
about it.



Dne Tue, 31 May 2011 17:38:06 +0200 Frank Shearar  
<[hidden email]> napsal(a):

> On 31 May 2011 16:04, Igor Stasenko <[hidden email]> wrote:
>> 2011/5/31 [hidden email] <[hidden email]>:
>>> It's not my idea, it was just interesting and I'd be glad to
>>> see some evolution (even pink plane) of squeak. I do not
>>> propose anything - but array literals just stink, they're
>>> another concept, which IMHO could be implemented in the very
>>> same way as control operators were.
>>>
>>> My question was not about array literals, it was about
>>> evolution of squeak - if something like this is at least planned?
>>>
>>
>> Right question contains half of the answer.
>> If you ask about language/system evolution in general, i think
>> you will get more extended answers.
>> Because array literals is really too little detail to care of.
>> One way or another, but you still need to provide a way how to
>> efficiently represent array literals in code.
>> And i don't see anything which could be so much powerful comparing to
>> existing syntax.
>> Some other languages have syntax constructs even for more complex
>> stuff: hash tables aka dictionaries.
>> Yes, syntax maybe ugly and looking weird, but nevertheless, it serves
>> its purpose: it provides a way to represent a hash table in source
>> code.
>
> Oh, and let's not forget ByteArrays - #[1 2 3 4]!
>
> frank
>>
>>> Because I couldn't find any "long-process-plan".
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>


--
Tato zpráva byla vytvořena převratným poštovním klientem Opery:  
http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Kamil Tomsik
In reply to this post by ccrraaiigg
Haven't Metacello solved this?

Dne Tue, 31 May 2011 17:54:41 +0200 Craig Latta <[hidden email]>  
napsal(a):

>
>> More importantly though, we're quibbling about something that's not
>> very important at all when we could be figuring out how to address the
>> real problems that Squeak faces, such as modularity.
>
>      Yup. How you can recommend a system in which there's no easy way to
> share your work?
>
>
> -C
>
> --
> Craig Latta
> www.netjam.org/resume
> +31  06 2757 7177
> + 1 415  287 3547
>
>
>
>


--
Tato zpráva byla vytvořena převratným poštovním klientem Opery:  
http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Stéphane Rollandin
In reply to this post by Kamil Tomsik
Hello,

Would you mind either signing your posts or set-up your email 'from'
field, please ? It would be nicer to have a name associated to
[hidden email] :)

Best,

Stef

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Kamil Tomsik
Sure, sorry for that.
(Should be okay from now)

BTW: I've written few other flaws in smalltalk, if anybody is interested in
either reading or discussing.
http://cztomsik.posterous.com/smalltalk-wtf

Dne Tue, 31 May 2011 18:55:01 +0200 Stéphane Rollandin  
<[hidden email]> napsal(a):

> Hello,
>
> Would you mind either signing your posts or set-up your email 'from'  
> field, please ? It would be nicer to have a name associated to  
> [hidden email] :)
>
> Best,
>
> Stef

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Eliot Miranda-2
In reply to this post by Kamil Tomsik


2011/5/31 [hidden email] <[hidden email]>
Sorry, I forgot about uselessness of array literals.

I simply don't see any use-case in which I'd like to
evaluate something in compile-time, it's feels to me
like another form of static state.

Are there any (major) advantages of array literals?
Something which couldn't be done without them?

I remember anecdotes from the last decade on slow start-up of Java applications that were either competing with VisualWorks or had been ported from VisualWorks that in part were due to the lack of powerful literal facilities in Java.  It appears that having the ability to define complex data statically without having to construct it by running code is a significant space and time saver (space, since the code to construct a complex literal will almost certainly be bulkier than that literal unless the code is sophisticated enough to be functioning like a decompressor, in which case it'll likely be incomprehensible too).  For me, a string literal syntax is an essential component of a good programming language and Smalltalk excels here.

There /is/ an issue as to whether #() is necessary syntax.  After all one could rely on the compiler to detect whether a { expr. expr } form can be evaluated at compile time.  That's a position Gilad Bracha has taken in Newspeak, and I think that design is driven by modularity concerns (in Newspeak there is a desire for the class of literals to eventually be determined at module instantiation time, based on what classes one imports, not on compile time).  While this is a good argument in Newspeak it strikes me as very bad for readability.  Using an easily recognised literal form takes significant cognitive load off of the programmer and that's extremely important (and fits with Smalltalk's ethos).

Eliot



Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Kamil Tomsik
In reply to this post by Kamil Tomsik
Hm, didn't work.

I guess I'll just sign myself :)

Best,

Kamil Tomsik

Dne Tue, 31 May 2011 19:28:22 +0200 [hidden email] <[hidden email]>  
napsal(a):

> Sure, sorry for that.
> (Should be okay from now)
>
> BTW: I've written few other flaws in smalltalk, if anybody is interested  
> in
> either reading or discussing.
> http://cztomsik.posterous.com/smalltalk-wtf
>
> Dne Tue, 31 May 2011 18:55:01 +0200 Stéphane Rollandin  
> <[hidden email]> napsal(a):
>
>> Hello,
>>
>> Would you mind either signing your posts or set-up your email 'from'  
>> field, please ? It would be nicer to have a name associated to  
>> [hidden email] :)
>>
>> Best,
>>
>> Stef

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Nicolas Cellier
In reply to this post by Kamil Tomsik
I wonder which language does not upset you based on these criteria...
Maybe lisp ?

Nicolas

2011/5/31 [hidden email] <[hidden email]>:

> Sure, sorry for that.
> (Should be okay from now)
>
> BTW: I've written few other flaws in smalltalk, if anybody is interested in
> either reading or discussing.
> http://cztomsik.posterous.com/smalltalk-wtf
>
> Dne Tue, 31 May 2011 18:55:01 +0200 Stéphane Rollandin
> <[hidden email]> napsal(a):
>
>> Hello,
>>
>> Would you mind either signing your posts or set-up your email 'from'
>> field, please ? It would be nicer to have a name associated to
>> [hidden email] :)
>>
>> Best,
>>
>> Stef
>
>

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

ccrraaiigg
In reply to this post by Kamil Tomsik

> Hasn't Metacello solved this?

     No.


-C

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547




Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Kamil Tomsik
In reply to this post by Nicolas Cellier
It's not anti-smalltalk post,
it's just a list of smells. (not big ones)

Smalltalk is great language.


Dne Tue, 31 May 2011 20:05:20 +0200 Nicolas Cellier  
<[hidden email]> napsal(a):

> I wonder which language does not upset you based on these criteria...
> Maybe lisp ?
>
> Nicolas
>
> 2011/5/31 [hidden email] <[hidden email]>:
>> Sure, sorry for that.
>> (Should be okay from now)
>>
>> BTW: I've written few other flaws in smalltalk, if anybody is  
>> interested in
>> either reading or discussing.
>> http://cztomsik.posterous.com/smalltalk-wtf
>>
>> Dne Tue, 31 May 2011 18:55:01 +0200 Stéphane Rollandin
>> <[hidden email]> napsal(a):
>>
>>> Hello,
>>>
>>> Would you mind either signing your posts or set-up your email 'from'
>>> field, please ? It would be nicer to have a name associated to
>>> [hidden email] :)
>>>
>>> Best,
>>>
>>> Stef
>>
>>
>


--
Tato zpráva byla vytvořena převratným poštovním klientem Opery:  
http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Igor Stasenko
2011/5/31 Kamil Tomsik <[hidden email]>:
> It's not anti-smalltalk post,
> it's just a list of smells. (not big ones)
>
ehm.. you saying:
1. different message types with different precedence -> distraction,
parentheses

now, just for comparison, count the number of precedence rules in
another procedural languages.
in smalltalk there are only 4: unary, binary, keywords, cascade.

I can imagine that we can easily get rid of binary messages.. and
replace them with keywords, so
instead of writing:
a + b.
one must write:
a add: b.

but that will lead to much larger number of parens everywhere.
Keyword syntax should stay. It is most superior form of expression
known by myself, because if message selector is picked carefully,
then it tells, what arguments are expected for each keyword, unlike to
C where function could have 5-10 arguments
and you have to refer to its source code in order to write down the
correct arguments to make a function call.

> Smalltalk is great language.
>

What makes a smalltalk great is not just language, but also
environment. If you look at it purely from syntax point of view, then
i'm
afraid, you don't see a whole image.
Because without dev tools, it will be not much better than PHP, Ruby
or Javascript, where you on your own with source code, and have to
manually navigate through code.

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Kamil Tomsik
In short:

1.) binary messages make sense only for math. I've never implemented even  
one binary message, have you? (for non-math things)

Why not step further and make dsl for equations? let them live outside of  
language.
(with everything common to math world)

2.) keyword messages with more than 2 arguments are just ugly - they smell  
in the "missing another object" way. And 2 arguments are rare too. I would  
allow one argument at top.

3.) unary messages - I would drop them too, and the reason is - I don't  
write a lot of "return" code, I give orders, I want actions from my  
objects. I don't want another objects on which I can operate (or get  
another ones, and again and again). But another syntax sugar for passing  
"yourself" would be needed :-/.

4.) all of this could result in consistent syntax like:
receiver doSomething: yourself.
receiver doSomething: param.

this simplification also allows like-english cascade:
receiver doSomething: param, doSomethingElse: anotherParam.

or multiple receivers (like F-Script):
receiver, anotherReceiver, anotherReceiver doSomething: yourself,  
doSomethingElse: param.

This is not proposal, just my current "state-of-thinking".

On Tue, 31 May 2011 21:01:24 +0200, Igor Stasenko <[hidden email]>  
wrote:

> 2011/5/31 Kamil Tomsik <[hidden email]>:
>> It's not anti-smalltalk post,
>> it's just a list of smells. (not big ones)
>>
> ehm.. you saying:
> 1. different message types with different precedence -> distraction,
> parentheses
>
> now, just for comparison, count the number of precedence rules in
> another procedural languages.
> in smalltalk there are only 4: unary, binary, keywords, cascade.
>
> I can imagine that we can easily get rid of binary messages.. and
> replace them with keywords, so
> instead of writing:
> a + b.
> one must write:
> a add: b.
>
> but that will lead to much larger number of parens everywhere.
> Keyword syntax should stay. It is most superior form of expression
> known by myself, because if message selector is picked carefully,
> then it tells, what arguments are expected for each keyword, unlike to
> C where function could have 5-10 arguments
> and you have to refer to its source code in order to write down the
> correct arguments to make a function call.
>
>> Smalltalk is great language.
>>
>
> What makes a smalltalk great is not just language, but also
> environment. If you look at it purely from syntax point of view, then
> i'm
> afraid, you don't see a whole image.
> Because without dev tools, it will be not much better than PHP, Ruby
> or Javascript, where you on your own with source code, and have to
> manually navigate through code.

Reply | Threaded
Open this post in threaded view
|

Re: smalltalk evolution

Randal L. Schwartz
>>>>> "info@tomsik" == info@tomsik cz <[hidden email]> writes:

info> In short: 1.) binary messages make sense only for math. I've never
info> implemented even one binary message, have you? (for non-math
info> things)

info> Why not step further and make dsl for equations? let them live
info> outside of language.  (with everything common to math world)

info> 2.) keyword messages with more than 2 arguments are just ugly -
info> they smell in the "missing another object" way. And 2 arguments
info> are rare too. I would allow one argument at top.

So, you've now eliminated both possible ways of creating a new Point:

    3 @ 4
    Point x: 3 y: 4

I wonder what language we would end up with if all of your (even
conflicting) goals were implemented.

The more syntax you eliminate, the more you end up with LISP.  Maybe you
want LISP... you know where to find it!

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

123