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 frank.shearar@gmail.com napsal(a):
On 31 May 2011 16:04, Igor Stasenko siguctua@gmail.com wrote:
2011/5/31 info@tomsik.cz info@tomsik.cz:
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.