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.
2011/5/31 info@tomsik.cz info@tomsik.cz:
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.
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".
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.
Because I couldn't find any "long-process-plan".
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.
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.
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?
2011/5/31 info@tomsik.cz info@tomsik.cz:
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
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
Haven't Metacello solved this?
Dne Tue, 31 May 2011 17:54:41 +0200 Craig Latta craig@netjam.org 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 toshare your work?
-C
-- Craig Latta www.netjam.org/resume +31 06 2757 7177
- 1 415 287 3547
2011/5/31 info@tomsik.cz info@tomsik.cz
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).
2¢ Eliot
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 info@tomsik.cz :)
Best,
Stef
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 lecteur@zogotounga.net 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 info@tomsik.cz :)
Best,
Stef
Hm, didn't work.
I guess I'll just sign myself :)
Best,
Kamil Tomsik
Dne Tue, 31 May 2011 19:28:22 +0200 info@tomsik.cz info@tomsik.cz 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 lecteur@zogotounga.net 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 info@tomsik.cz :)
Best,
Stef
I wonder which language does not upset you based on these criteria... Maybe lisp ?
Nicolas
2011/5/31 info@tomsik.cz info@tomsik.cz:
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 lecteur@zogotounga.net 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 info@tomsik.cz :)
Best,
Stef
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 nicolas.cellier.aka.nice@gmail.com napsal(a):
I wonder which language does not upset you based on these criteria... Maybe lisp ?
Nicolas
2011/5/31 info@tomsik.cz info@tomsik.cz:
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 lecteur@zogotounga.net 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 info@tomsik.cz :)
Best,
Stef
2011/5/31 Kamil Tomsik info@tomsik.cz:
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.
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 siguctua@gmail.com wrote:
2011/5/31 Kamil Tomsik info@tomsik.cz:
It's not anti-smalltalk post, it's just a list of smells. (not big ones)
ehm.. you saying:
- 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.
"info@tomsik" == info@tomsik cz info@tomsik.cz 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!
On Tue, 31 May 2011 22:01:14 +0200, Randal L. Schwartz merlyn@stonehenge.com wrote:
"info@tomsik" == info@tomsik cz info@tomsik.cz 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'll go few steps further to show big-picture in hypothetical syntax (one-argument closures with argument as implicit receiver, no returns -> CPS)
Point new: [x: 3, y: 4, printOn: aStream]. <rcvr> <msg>: <arg>[<msgForNew>: <arg>, <msgForNew>: <arg>, <msgForNew>: <arg>]. concepts: always left-to-right (receiver->message->argument), no parentheses -> uniformity returns: nothing, does something
vs. (Point x: 3 y: 4) printOn: aStream. (<rcvr> <msg>: <arg> <key2>: <arg2>) <msg>: <arg>. concepts: sometimes left-to-right, depending on parentheses and message-type (syntax) returns: aPoint, which won't be used anyway, because it was printed already.
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!
I'm not saying "let's drop objects", I'm saying "let's simplify language, let's drop unused/misused/bad-in-long-process things"
info@tomsik.cz wrote:
On Tue, 31 May 2011 22:01:14 +0200, Randal L. Schwartz merlyn@stonehenge.com wrote:
> "info@tomsik" == info@tomsik cz info@tomsik.cz 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: 4I'll go few steps further to show big-picture in hypothetical syntax (one-argument closures with argument as implicit receiver, no returns -> CPS)
Point new: [x: 3, y: 4, printOn: aStream]. <rcvr> <msg>: <arg>[<msgForNew>: <arg>, <msgForNew>: <arg>, <msgForNew>: <arg>]. concepts: always left-to-right (receiver->message->argument), no parentheses -> uniformity returns: nothing, does something
So, #new: creates a point without values for x and y... What if I want to only build objects that make sense, meaning that their instance variables must conform to some invariant defined by the class?
vs. (Point x: 3 y: 4) printOn: aStream. (<rcvr> <msg>: <arg> <key2>: <arg2>) <msg>: <arg>. concepts: sometimes left-to-right, depending on parentheses and message-type (syntax) returns: aPoint, which won't be used anyway, because it was printed already.
Easy choice. This is much nicer.
Cheers, Juan Vuletich
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!
I'm not saying "let's drop objects", I'm saying "let's simplify language, let's drop unused/misused/bad-in-long-process things"
No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1375 / Virus Database: 1509/3663 - Release Date: 05/27/11
So, #new: creates a point without values for x and y... What if I want to only build objects that make sense, meaning that their instance variables must conform to some invariant defined by the class?
you can't do this even in smalltalk.
...and checking arguments presence is not enough, you would need to check its internal state too - and you shouldn't do that.
Best, Kamil
Kamil Tomsik wrote:
So, #new: creates a point without values for x and y... What if I want to only build objects that make sense, meaning that their instance variables must conform to some invariant defined by the class?
you can't do this even in smalltalk.
How come? In your Point example it is very easy to get a 'broken' point... How would you get an equally broken OrderedCollection in Smalltalk? In my opinion doing 'OrderedCollection basicNew' or "anOrderedCollection instVarNamed: 'array' put: nil" don't count, because it's not happening by accident: You're clearly stating the intention to break it!
...and checking arguments presence is not enough, you would need to check its internal state too - and you shouldn't do that.
You shouldn't do _what_? You say you shouldn't check internal state? I wonder what you mean here... and if you're serious or just trolling...
You'd be in a much better position to find Smalltalk's shortcomings if you first learn more about it. Start with "Design principles behind Smalltalk". "The early history of Smalltalk" is also a great read. There are many great books about Smalltalk, for example "Smalltalk with Style". Then, spend a couple of years doing relevant, non-trivial stuff with Smalltalk, studying the image and applications written with it. Maybe then you have a better POV.
Cheers, Juan Vuletich
Best, Kamil
2011/6/1 Juan Vuletich juan@jvuletich.org:
Kamil Tomsik wrote:
So, #new: creates a point without values for x and y... What if I want to only build objects that make sense, meaning that their instance variables must conform to some invariant defined by the class?
you can't do this even in smalltalk.
How come? In your Point example it is very easy to get a 'broken' point... How would you get an equally broken OrderedCollection in Smalltalk? In my opinion doing 'OrderedCollection basicNew' or "anOrderedCollection instVarNamed: 'array' put: nil" don't count, because it's not happening by accident: You're clearly stating the intention to break it!
Well, it's _technically_ true. Consider Point>>x:y:. First you evaluate "self basicNew", at which point you have an uninitialised object, and then you call the private #setX:setY:, after which you have a well-initialised object. From the outside, you only ever see a properly initialised object, of course.
But I say "technically". Practically speaking, having constructor messages on the class side that call private initialisers on the instance side, and having the discipline not to send those private messages from other objects, means No Problem.
frank
Cheers, Juan Vuletich
Best, Kamil
On 1 June 2011 12:53, Frank Shearar frank.shearar@gmail.com wrote:
2011/6/1 Juan Vuletich juan@jvuletich.org:
Kamil Tomsik wrote:
So, #new: creates a point without values for x and y... What if I want to only build objects that make sense, meaning that their instance variables must conform to some invariant defined by the class?
you can't do this even in smalltalk.
How come? In your Point example it is very easy to get a 'broken' point... How would you get an equally broken OrderedCollection in Smalltalk? In my opinion doing 'OrderedCollection basicNew' or "anOrderedCollection instVarNamed: 'array' put: nil" don't count, because it's not happening by accident: You're clearly stating the intention to break it!
Well, it's _technically_ true. Consider Point>>x:y:. First you evaluate "self basicNew", at which point you have an uninitialised object, and then you call the private #setX:setY:, after which you have a well-initialised object. From the outside, you only ever see a properly initialised object, of course.
But I say "technically". Practically speaking, having constructor messages on the class side that call private initialisers on the instance side, and having the discipline not to send those private messages from other objects, means No Problem.
Newspeak seems addressing that.
frank
Cheers, Juan Vuletich
Best, Kamil
I'm not trolling, feel free to ignore me if you think so.
It's just common to not depend on internal state of other objects (even parameters), if client will pass something wrong, it's his failure. Otherwise we would end up with Java-like code, where everything is checked by instanceof and revalidated, just to be sure.
and "Point new [x: 3, printOn: aStream]" could result in 3@0, it's not a big deal.
And I've read all of those and few others too. Just to be clear.
Best, Kamil
Dne Wed, 01 Jun 2011 12:18:27 +0200 Juan Vuletich juan@jvuletich.org napsal(a):
Kamil Tomsik wrote:
So, #new: creates a point without values for x and y... What if I want to only build objects that make sense, meaning that their instance variables must conform to some invariant defined by the class?
you can't do this even in smalltalk.
How come? In your Point example it is very easy to get a 'broken' point... How would you get an equally broken OrderedCollection in Smalltalk? In my opinion doing 'OrderedCollection basicNew' or "anOrderedCollection instVarNamed: 'array' put: nil" don't count, because it's not happening by accident: You're clearly stating the intention to break it!
...and checking arguments presence is not enough, you would need to check its internal state too - and you shouldn't do that.
You shouldn't do _what_? You say you shouldn't check internal state? I wonder what you mean here... and if you're serious or just trolling...
You'd be in a much better position to find Smalltalk's shortcomings if you first learn more about it. Start with "Design principles behind Smalltalk". "The early history of Smalltalk" is also a great read. There are many great books about Smalltalk, for example "Smalltalk with Style". Then, spend a couple of years doing relevant, non-trivial stuff with Smalltalk, studying the image and applications written with it. Maybe then you have a better POV.
Cheers, Juan Vuletich
Best, Kamil
Hi all, If you don't like the Squeak language as it is, all you need to do is to write a new compiler and use it for compiling the methods of your own classes. Many different languages can co-exist in the same image without problems. VW has done it; the methods of some classes were written in SQL when I looked at it several years ago. I've done it when I got rid of the annoying class companion, the metaclass. (Several of my classes shared the same metaclass). The experiment didn't lead where I wanted to go, so I abandoned it. My BabyIDE environment for DCI programming does it by extending Traits with knowledge about the (DCI) Context of the methods. None of it exactly straight forward, but doable.
Here are some details if you're interested
Most programming languages such as Java are used to specify complete programs. The 'original' of a program is its text form. A compiler translates to a binary form.
There is no Smalltalk language in this sense. The 'original' of a program is its binary form as an object structure in the image. The creation of a new class object is done by a process in this image. Usually, this is done by a command in the Browser. The common textual form for defining a new class is a 'doIt'; a statement to be interpreted by the image. The so called Smalltalk language is used to specify methods; one method at the time. The compilation and installation of a method is done by the class; the methods of different classes can be specified in different languages.
So, if you really want a different syntax, you can write your own compiler and share it with other people who share your interests. There's no need for an up-front decision and translation of all legacy code.
Many interesting experiments could be made this way. --Trygve
On 2011.06.01 03:24, Juan Vuletich wrote:
info@tomsik.cz wrote:
On Tue, 31 May 2011 22:01:14 +0200, Randal L. Schwartz merlyn@stonehenge.com wrote:
>> "info@tomsik" == info@tomsik cz info@tomsik.cz 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: 4I'll go few steps further to show big-picture in hypothetical syntax (one-argument closures with argument as implicit receiver, no returns -> CPS)
Point new: [x: 3, y: 4, printOn: aStream]. <rcvr> <msg>: <arg>[<msgForNew>: <arg>, <msgForNew>: <arg>, <msgForNew>: <arg>]. concepts: always left-to-right (receiver->message->argument), no parentheses -> uniformity returns: nothing, does something
So, #new: creates a point without values for x and y... What if I want to only build objects that make sense, meaning that their instance variables must conform to some invariant defined by the class?
vs. (Point x: 3 y: 4) printOn: aStream. (<rcvr> <msg>: <arg> <key2>: <arg2>) <msg>: <arg>. concepts: sometimes left-to-right, depending on parentheses and message-type (syntax) returns: aPoint, which won't be used anyway, because it was printed already.
Easy choice. This is much nicer.
Cheers, Juan Vuletich
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!
I'm not saying "let's drop objects", I'm saying "let's simplify language, let's drop unused/misused/bad-in-long-process things"
No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1375 / Virus Database: 1509/3663 - Release Date: 05/27/11
On 1 June 2011 08:30, Trygve Reenskaug trygver@ifi.uio.no wrote:
Hi all, If you don't like the Squeak language as it is, all you need to do is to write a new compiler and use it for compiling the methods of your own classes. Many different languages can co-exist in the same image without problems. VW has done it; the methods of some classes were written in SQL when I looked at it several years ago. I've done it when I got rid of the annoying class companion, the metaclass. (Several of my classes shared the same metaclass). The experiment didn't lead where I wanted to go, so I abandoned it. My BabyIDE environment for DCI programming does it by extending Traits with knowledge about the (DCI) Context of the methods. None of it exactly straight forward, but doable.
Here are some details if you're interested
Most programming languages such as Java are used to specify complete programs. The 'original' of a program is its text form. A compiler translates to a binary form.
There is no Smalltalk language in this sense. The 'original' of a program is its binary form as an object structure in the image. The creation of a new class object is done by a process in this image. Usually, this is done by a command in the Browser. The common textual form for defining a new class is a 'doIt'; a statement to be interpreted by the image. The so called Smalltalk language is used to specify methods; one method at the time. The compilation and installation of a method is done by the class; the methods of different classes can be specified in different languages.
So, if you really want a different syntax, you can write your own compiler and share it with other people who share your interests. There's no need for an up-front decision and translation of all legacy code.
Many interesting experiments could be made this way.
Amen. And what I'd like to see Trunk do is enable this kind of experimentation, by providing hooks into the base system, and making things pluggable/modular so that (a) you can actually run the experiment - by swapping out a Compiler, for instance - and (b) you don't have to hack on the Squeak platform itself. That lets your experiment fail without taking down the entire image.
frank
--Trygve
On 2011.06.01 03:24, Juan Vuletich wrote:
info@tomsik.cz wrote:
On Tue, 31 May 2011 22:01:14 +0200, Randal L. Schwartz merlyn@stonehenge.com wrote:
"info@tomsik" == info@tomsik cz info@tomsik.cz 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'll go few steps further to show big-picture in hypothetical syntax (one-argument closures with argument as implicit receiver, no returns -> CPS)
Point new: [x: 3, y: 4, printOn: aStream]. <rcvr> <msg>: <arg>[<msgForNew>: <arg>, <msgForNew>: <arg>, <msgForNew>: <arg>]. concepts: always left-to-right (receiver->message->argument), no parentheses -> uniformity returns: nothing, does something
So, #new: creates a point without values for x and y... What if I want to only build objects that make sense, meaning that their instance variables must conform to some invariant defined by the class?
vs. (Point x: 3 y: 4) printOn: aStream. (<rcvr> <msg>: <arg> <key2>: <arg2>) <msg>: <arg>. concepts: sometimes left-to-right, depending on parentheses and message-type (syntax) returns: aPoint, which won't be used anyway, because it was printed already.
Easy choice. This is much nicer.
Cheers, Juan Vuletich
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!
I'm not saying "let's drop objects", I'm saying "let's simplify language, let's drop unused/misused/bad-in-long-process things"
No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1375 / Virus Database: 1509/3663 - Release Date: 05/27/11
--
Trygve Reenskaug mailto: trygver@ifi.uio.no
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo Tel: (+47) 22 49 57 27
Norway
"Frank" == Frank Shearar frank.shearar@gmail.com writes:
Frank> Amen. And what I'd like to see Trunk do is enable this kind of Frank> experimentation, by providing hooks into the base system, and making Frank> things pluggable/modular so that (a) you can actually run the Frank> experiment - by swapping out a Compiler, for instance - and (b) you Frank> don't have to hack on the Squeak platform itself. That lets your Frank> experiment fail without taking down the entire image.
It already does. OMeta uses that, for example. I think the "Tiles" language also did. Each class can declare which compiler is used for its methods and subclass methods.
Time to get cracking.
On 1 June 2011 18:50, Randal L. Schwartz merlyn@stonehenge.com wrote:
"Frank" == Frank Shearar frank.shearar@gmail.com writes:
Frank> Amen. And what I'd like to see Trunk do is enable this kind of Frank> experimentation, by providing hooks into the base system, and making Frank> things pluggable/modular so that (a) you can actually run the Frank> experiment - by swapping out a Compiler, for instance - and (b) you Frank> don't have to hack on the Squeak platform itself. That lets your Frank> experiment fail without taking down the entire image.
It already does. OMeta uses that, for example. I think the "Tiles" language also did. Each class can declare which compiler is used for its methods and subclass methods.
Yes, this is true. And it mostly works quite easily, too - just override YourClass >> #compilerClass and possibly #decompilerClass.
Time to get cracking.
Yes - but first I have some tools to refactor!
frank
2011/6/1 Frank Shearar frank.shearar@gmail.com:
On 1 June 2011 18:50, Randal L. Schwartz merlyn@stonehenge.com wrote:
> "Frank" == Frank Shearar frank.shearar@gmail.com writes:
Frank> Amen. And what I'd like to see Trunk do is enable this kind of Frank> experimentation, by providing hooks into the base system, and making Frank> things pluggable/modular so that (a) you can actually run the Frank> experiment - by swapping out a Compiler, for instance - and (b) you Frank> don't have to hack on the Squeak platform itself. That lets your Frank> experiment fail without taking down the entire image.
It already does. OMeta uses that, for example. I think the "Tiles" language also did. Each class can declare which compiler is used for its methods and subclass methods.
Yes, this is true. And it mostly works quite easily, too - just override YourClass >> #compilerClass and possibly #decompilerClass.
And if you are building already existing AST nodes with a different syntax, you can now just override parserClass.
Nicolas
Time to get cracking.
Yes - but first I have some tools to refactor!
frank
Randal wrote to Kamil:
The more syntax you eliminate, the more you end up with LISP. Maybe you want LISP... you know where to find it!
There are alternatives if you think outside the box. My "underlining syntax" proposal for Neo Smalltalk, for example:
http://www.merlintec.com:8080/software/4
-- Jecel
2011/5/31 info@tomsik.cz info@tomsik.cz:
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)
Example : / for building file path
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.
They are rare anyway... In my experience, the 16 arguments limit, though well founded from Object POV, is limiting interoperability with 3rd party library (LAPACK) and that's just boring. My opinion is that educating is better than just forbiding. We can tolerate exceptions. Anyway, the workarounds we'll build might well be much uglier...
dic := Dictionary new. SystemNavigation default allBehaviorsDo: [:e | e selectorsDo: [:s | (dic at: s numArgs ifAbsentPut: [Set new]) add: s]]. dic collect: [:e | e size] -> a Dictionary(0->18320 1->10083 2->3560 3->1331 4->556 5->201 6->88 7->47 8->24 9->4 10->7 11->1 12->3 13->3 14->1 15->1 )
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.
I'm not convinced it would ease readability. OK, imperative shall be the preferred mode, tell don't ask, but eliminating queries altogether is a bit totalitarian to my taste. I invite you to rewrite a utility library, say Graphics, with this style and come back with the result if you are pleased with it.
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".
Designing a language is a very interesting topic. But a very involved one too. I'd say try it, eat your own dog food and share a posteriori opinions, it will be much more fruitfull.
Nicolas
On Tue, 31 May 2011 21:01:24 +0200, Igor Stasenko siguctua@gmail.com wrote:
2011/5/31 Kamil Tomsik info@tomsik.cz:
It's not anti-smalltalk post, it's just a list of smells. (not big ones)
ehm.. you saying:
- 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.
Example from my previous reply to Randal for illustration:
Point new: [x: 3, y: 4, printOn: aStream].
Always left-to-right syntax, always one argument, possible multiple receivers and messages, syntax sugar for closures, closure always have only one argument which is also implicit receiver - you can't deny it's at least interesting to think about such kind of uniformity.
Example : / for building file path
okay, maybe, still not worth of losing left-to-right
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. Iwould allow one argument at top.
They are rare anyway... In my experience, the 16 arguments limit, though well founded from Object POV, is limiting interoperability with 3rd party library (LAPACK) and that's just boring. My opinion is that educating is better than just forbiding. We can tolerate exceptions. Anyway, the workarounds we'll build might well be much uglier...
dic := Dictionary new. SystemNavigation default allBehaviorsDo: [:e | e selectorsDo: [:s | (dic at: s numArgs ifAbsentPut: [Set new]) add: s]]. dic collect: [:e | e size] -> a Dictionary(0->18320 1->10083 2->3560 3->1331 4->556 5->201 6->88 7->47 8->24 9->4 10->7 11->1 12->3 13->3 14->1 15->1 )
yes, however I think external libraries shouldn't be just "bridged", new library should be designed, in the mood of rest of the language.
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.
I'm not convinced it would ease readability. OK, imperative shall be the preferred mode, tell don't ask, but eliminating queries altogether is a bit totalitarian to my taste. I invite you to rewrite a utility library, say Graphics, with this style and come back with the result if you are pleased with it.
Have a look on that illustration on top - imperative while still readable: create new point, with x: 3, y: 4 and print it on given stream.
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".
Designing a language is a very interesting topic. But a very involved one too. I'd say try it, eat your own dog food and share a posteriori opinions, it will be much more fruitfull.
Nicolas
I think about it - I was just curious about: 1. if there is any effort to change squeak on language level 2. what do people who already implemented one successful language, think about what I've just written
Kamil
I think about it - I was just curious about:
- if there is any effort to change squeak on language level
I joining to what Nicolas said: try eating own food. Implement new syntax, implement some library on it. Show results, proving that changing syntax make things less complex, easier to read and understand, and of course easier and faster to implement. Otherwise its just a voice in the desert.
- what do people who already implemented one successful language, think
about what I've just written
i don't know. Maybe you should ask them instead? Ask perl author(s) or ruby author(s), what they thinking about what you just wrote. (especially Ruby one, which has no formally defined grammar).
I would really like to know what they thinking. Seriously & Pun intended.
"Igor" == Igor Stasenko siguctua@gmail.com writes:
Igor> I joining to what Nicolas said: try eating own food. Igor> Implement new syntax, implement some library on it.
And don't forget to implement the entire toolchain, including debugger.
Maybe it's time to throw out syntax and "text" based programming all together...
The punctuation is just there to trigger the parser to perform ... and trigger the memory of those "in the know" about: what "did", or "does", or "will" happen. What if we use spreadsheet cells, or colors, or fonts, or little icons superimposed on the labels (text labels/names for code, data, or other memory artifacts or equipment) to more clearly express visually what is more often hidden in meaning.
Each cell/label can expand to explicitly visually express its connection to time, persistence, mutability, scope, nesting, linking, precedence, execution order, namespace, importance to the individual programmer or importance to society at large, implications of change, and other properties.
Why? For the same reason syntax coloring helps the memory. There's just too little information visually expressed in syntax, a holdover from the early dark days of computing, when every bit & byte was expensive. It's why we vocally speak to each other with much intonation to carry extra meaning and not just speak in monotones. We're in the GUI age now. And I don't mean graphical drag and drop programming or APL special symbols! I mean code entry by typing ... but translated, and stored, with its visual representation of meaning. For example, in such an IDE, one could change the English word with one in another language with the same meaning, but the references and context remain the same, independent of the text of the label, like a spreadsheet cell does.
Simplicity ... through multi-level, collapsable, visual explicitly.
- Darius
Yes, I'm pretty sure next big language will continue where Self stopped. (programming as an experience)
Visual programming is much more "direct" than reading & writing. However I'm not sure if we can make useful visual programming language without need for any kind of scripting.
On Wed, 01 Jun 2011 00:58:34 +0200, Darius Clarke socinian@gmail.com wrote:
Maybe it's time to throw out syntax and "text" based programming all together...
The punctuation is just there to trigger the parser to perform ... and trigger the memory of those "in the know" about: what "did", or "does", or "will" happen. What if we use spreadsheet cells, or colors, or fonts, or little icons superimposed on the labels (text labels/names for code, data, or other memory artifacts or equipment) to more clearly express visually what is more often hidden in meaning.
Each cell/label can expand to explicitly visually express its connection to time, persistence, mutability, scope, nesting, linking, precedence, execution order, namespace, importance to the individual programmer or importance to society at large, implications of change, and other properties.
Why? For the same reason syntax coloring helps the memory. There's just too little information visually expressed in syntax, a holdover from the early dark days of computing, when every bit & byte was expensive. It's why we vocally speak to each other with much intonation to carry extra meaning and not just speak in monotones. We're in the GUI age now. And I don't mean graphical drag and drop programming or APL special symbols! I mean code entry by typing ... but translated, and stored, with its visual representation of meaning. For example, in such an IDE, one could change the English word with one in another language with the same meaning, but the references and context remain the same, independent of the text of the label, like a spreadsheet cell does.
Simplicity ... through multi-level, collapsable, visual explicitly.
- Darius
"Darius" == Darius Clarke socinian@gmail.com writes:
Darius> What if we use spreadsheet cells, or colors, or fonts, or little icons Darius> superimposed on the labels (text labels/names for code, data, or other Darius> memory artifacts or equipment) to more clearly express visually what is more Darius> often hidden in meaning.
But don't leave out those of us for whom all of that is merely a distraction.
I don't grok icons. I hate fontification coloring.
If the next big thing is visual programming, I'm outta here.
Darius> Why? For the same reason syntax coloring helps the memory.
Except for me. It does nothing, except annoy me.
Please remember that not *everyone* has "visual" as their lead processing system, and for some of us, it's nearly absent.
Depends on what "visual programming" is.
Visual programming is not (mainly) wysiwyg designer. It's just evolution - from consoles, to browsers and editors, to visual representations of units and whole systems.
I've written post about it: http://cztomsik.posterous.com/visual-programming
On Wed, 01 Jun 2011 02:50:10 +0200, Randal L. Schwartz merlyn@stonehenge.com wrote:
"Darius" == Darius Clarke socinian@gmail.com writes:
Darius> What if we use spreadsheet cells, or colors, or fonts, or little icons Darius> superimposed on the labels (text labels/names for code, data, or other Darius> memory artifacts or equipment) to more clearly express visually what is more Darius> often hidden in meaning.
But don't leave out those of us for whom all of that is merely a distraction.
I don't grok icons. I hate fontification coloring.
If the next big thing is visual programming, I'm outta here.
Darius> Why? For the same reason syntax coloring helps the memory.
Except for me. It does nothing, except annoy me.
Please remember that not *everyone* has "visual" as their lead processing system, and for some of us, it's nearly absent.
On Wed, 01 Jun 2011 00:15:50 +0200, Igor Stasenko siguctua@gmail.com wrote:
introducing concept itself is not a problem, rewriting/generating libraries will be harder.
I think about it - I was just curious about:
- if there is any effort to change squeak on language level
I joining to what Nicolas said: try eating own food. Implement new syntax, implement some library on it. Show results, proving that changing syntax make things less complex, easier to read and understand, and of course easier and faster to implement. Otherwise its just a voice in the desert.
- what do people who already implemented one successful language, think
about what I've just written
i don't know. Maybe you should ask them instead? Ask perl author(s) or ruby author(s), what they thinking about what you just wrote. (especially Ruby one, which has no formally defined grammar).
I would really like to know what they thinking. Seriously & Pun intended.
On 31 May 2011 22:43, info@tomsik.cz info@tomsik.cz wrote:
Example from my previous reply to Randal for illustration:
Point new: [x: 3, y: 4, printOn: aStream].
Always left-to-right syntax, always one argument, possible multiple receivers and messages, syntax sugar for closures, closure always have only one argument which is also implicit receiver - you can't deny it's at least interesting to think about such kind of uniformity.
Absolutely. It's called the lambda calculus. And it's very interesting to work things out using lambda calculus, and figure out the semantics of statements... but would you really want to program in the lambda calculus?
Even the textbooks allow multiple parameter functions, with the understanding that \xyz <whatever> is really \x \y \z <curried whatever.
frank
On 31 May 2011 22:43, info@tomsik.cz info@tomsik.cz wrote:
Example from my previous reply to Randal for illustration:
Point new: [x: 3, y: 4, printOn: aStream].
Always left-to-right syntax, always one argument, possible multiple receivers and messages, syntax sugar for closures, closure always have only one argument which is also implicit receiver - you can't deny it's at least interesting to think about such kind of uniformity.
Absolutely. It's called the lambda calculus. And it's very interesting to work things out using lambda calculus, and figure out the semantics of statements... but would you really want to program in the lambda calculus?
Even the textbooks allow multiple parameter functions, with the understanding that \xyz <whatever> is really \x \y \z <curried whatever.
frank
Lambda calculus has different purpose (evaluation), this is sequence of orders (no return value) in logic left-to-right order.
Actually I'd like to see something very different (in hypertalk style) and with "smart" syntax like:
Account>>deposit amount = increase balance by amount. SomeScript>>doSomethingWith account = deposit amount(100) to account.
This is just sketch, prototype in my head, which wasn't crystalized yet, but it's IMHO interesting approach and could improve readability too.
However left-to-right tell-dont-ask style improves design and is also much easier to read and "scan". (I do write a lot of code this way so I can compare)
It is also very natural for people and their thinking. (we usually don't want to GET/EVALUATE something, we want things to be DONE)
I do not need low-level support in language, I can already code this way, but every interaction with existing library is just pain... Hm, as I think about it, maybe I don't need to rewrite libraries, maybe some kind of dynamic wrapper could be enough...
I'm curious for your opinions. It's very enlightening discussion, thx for that.
Am 2011-05-31 um 23:25 schrieb Nicolas Cellier:
2011/5/31 info@tomsik.cz info@tomsik.cz:
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)
Example : / for building file path
Example: >> for accessing Methods in a class like this: Class >> #name
Best -Tobias
info@tomsik.cz wrote:
In short:
1.) binary messages make sense only for math. I've never implemented even one binary message, have you? (for non-math things)
That's not true (the first part. I don't know what you have ever implemented). For instance look for implementors of #=, #==, #>, #>>, #->, #+, #,, #&, #|.
This is a nice example of something I have implemented: Text buildWithStyles: ({ #H3 -> (ParagraphStyle named: 'Heading 3'). #b11 -> (CharacterStyle named: 'Blue 11'). #r10b -> (CharacterStyle named: 'Red 10 bold'). #g11i -> (CharacterStyle named: 'Green 11 Italic') } as: Dictionary) contents: [ :builder | builder , 'Starts with no character style. But later gets' < #b11 , ' small and blue' , ' and stays like that. Then' >< #r10b , ' emphasized and inside this,' < #g11i , ' green and italic' > ' for a while. Later' > ' back to Heading 3.' / #H3].
The objectives for this were: - the styles can be crated dynamically, and there's no need to add new selectors for new styles - it is very unobtrusive, the text is reasonably easy to read (much nicer than, for example, rtf or html), especially with Shout.
Anyway, even if it were true that binary messages "make sense only for math", that wouldn't be a reason to ban them! Math stuff is useful too!
Cheers, Juan Vuletich
1.) binary messages make sense only for math. I've never implemented even one binary message, have you? (for non-math things)
49 of them for this package only: http://www.zogotounga.net/comp/squeak/functionaltalk.htm
(see at the bottom of the page)
Stef
I'm not saying they're not useful, but they're usually part of some internal DSL, why not introduce full-blown DSL? (for math, func programming, whatever else)
When using internal DSLs you have to switch your mind to different language anyway, why not represent it in code in a different way too?
I've written few internal DSLs when I was doing Java, and it always felt like "ew. wtf? is this java?" with need for careful inspecting. And it always decreased code-readability, but this can be subjective (as everything).
Dne Wed, 01 Jun 2011 10:38:31 +0200 Stéphane Rollandin lecteur@zogotounga.net napsal(a):
1.) binary messages make sense only for math. I've never implemented even one binary message, have you? (for non-math things)
49 of them for this package only: http://www.zogotounga.net/comp/squeak/functionaltalk.htm
(see at the bottom of the page)
Stef
I'm not saying they're not useful, but they're usually part of some internal DSL, why not introduce full-blown DSL? (for math, func programming, whatever else)
It is not clear to me what you call DSL here. In a dynamic language such as Smalltalk I do not see a clear distinction between a DSL and a protocol.
As for the package I linked to, I use it extensively in my main project (muO) so it doesn't feel like a DSL to me at all: it just implements functions as objects and make it easy to use them.
Here is a code example:
GenericInputMorph>>acceptMorph: aMorph "Sent by the drop reporter."
morphTest ifNotNil: [(morphTest <~ aMorph) ifFalse: [^ self]].
textPane setText: (((self morphicLambda <~ aMorph) ifNil: [^ self]) <= m) lambdaStoreString. morph := aMorph. dropReporter smallLabel: aMorph name. textPane hasUnacceptedEdits: true
Do you see a DSL there ?
Stef
yes, sorry for that - every time I see binary message (<~, and even <=) I start wondering about & searching for what does it mean.
which is exact opposite of what I want to do. code (action) should express what will happen. I don't want to be extra curious about details - if codes says it will work, I trust it.
refactoring note - your class should not depend on return value, but rather on double-dispatch (allowing you to extend what can be dropped to GenericInputMorph even without touching it) so test for isNil is IMHO wrong way of doing it as well as need for <~ special operator.
Best, Kamil
I'm not saying they're not useful, but they're usually part of some internal DSL, why not introduce full-blown DSL? (for math, func programming, whatever else)
It is not clear to me what you call DSL here. In a dynamic language such as Smalltalk I do not see a clear distinction between a DSL and a protocol.
As for the package I linked to, I use it extensively in my main project (muO) so it doesn't feel like a DSL to me at all: it just implements functions as objects and make it easy to use them.
Here is a code example:
GenericInputMorph>>acceptMorph: aMorph "Sent by the drop reporter."
morphTest ifNotNil: [(morphTest <~ aMorph) ifFalse: [^ self]].
textPane setText: (((self morphicLambda <~ aMorph) ifNil: [^ self]) <= m) lambdaStoreString. morph := aMorph. dropReporter smallLabel: aMorph name. textPane hasUnacceptedEdits: true
Do you see a DSL there ?
Stef
refactoring note - your class should not depend on return value, but rather on double-dispatch (allowing you to extend what can be dropped to GenericInputMorph even without touching it) so test for isNil is IMHO wrong way of doing it as well as need for<~ special operator.
Everybody has his own style. I don't buy "best" coding practice. My coding is a personal craft, and while it is always evolving, it will never obey any specific guidelines. It's just not the way I do programming.
Best,
Stef
Stéphane Rollandin wrote:
Everybody has his own style. I don't buy "best" coding practice. My coding is a personal craft, and while it is always evolving, it will never obey any specific guidelines. It's just not the way I do programming.
Best,
Stef
Amen! As Dan said: "The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone."
Cheers, Juan Vuletich
So the #(static array literals) have been very useful to me due mostly to their compactness.
I recently had a big dictionary of dictionaries of of dictionaries of... and it was convenient to recursively grab the storeString. But if I just #storeString'd it, the string was big enough to make the compiler choke. I ended up recursively sending asArray, and then grabbing static array literals (this was in a Cuis image.) This was a *much* more compact representation of the object in question, and the compiler took to it handily.
At first, I felt the same way that you feel about the static array literals about the dynamic array literals; I didn't have any reference point for the syntax, it looked odd, and reminded me only of dotted pairs in Lisp... which isn't exactly the most recognizable idiom in the world.
Over time, though, the sheer utility of the dynamic arrays changed my mind. I still like having the static arrays for symbolic processing, though.
If you really have a great desire to remove the static array literal syntax, I will offer one piece of advice: find a way to let people have their cake and eat it too. Wouldn't it be cool if our literals could be loaded and unloaded as easily as changing a hat? I think you might even start seeing more experimentation with new literal syntaxen.
It's that old mathematician's trick: if you can find a way to solve the more general problem, you can eliminate a bunch of subproblems in one stroke.
Why not investigate making Squeak's syntax more modular? :)
2011/5/31 info@tomsik.cz info@tomsik.cz
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.
squeak-dev@lists.squeakfoundation.org
-
Casey Ransberger -
Craig Latta -
Darius Clarke -
Eliot Miranda -
Frank Shearar -
Igor Stasenko -
info＠tomsik.cz -
Jecel Assumpcao Jr. -
Juan Vuletich -
Kamil Tomsik
-
merlyn＠stonehenge.com -
Nicolas Cellier -
Stéphane Rollandin -
Tobias Pape -
Trygve Reenskaug