I have attached 2 cropped screen-captures of the same class displayed in the class browser; class-smalltalk.png is the regular class syntax, class-fluid.png is the same class but with the "Fluid" checkbox selected, and shows a different syntax. May I know what that is all about? There's a different terminology too, something called "slot", which I have faint memories of being quite like that in "Self" environments. Thank you, ~Kathe Â
On 2 Feb 2022, at 09:04, contactme@kathe.in wrote:
I have attached 2 cropped screen-captures of the same class displayed in the class browser; class-smalltalk.png is the regular class syntax, class-fluid.png is the same class but with the "Fluid" checkbox selected, and shows a different syntax.
This is no different syntax, as there is no Syntax (in the sense of Grammar) to define classes. These are all message sends, just like before.
May I know what that is all about?
There's a different terminology too, something called "slot", which I have faint memories of being quite like that in "Self" environments.
The Fluid class definition has two goals: 1) be extensible. With the ST80 way, any new parameter would mean adding *a lot* of methods. And every new parameter needs all the other variations, itâs a serious combinatorial explosion. Just an example: CompiledMethods and CompiledBlock use CompiledMethodLayout. But they are created with: CompiledCode variableByteSubclass: #CompiledMethod instanceVariableNames: '' classVariableNames: '' package: 'Kernel-Methods' So the system checks for the name and uses the CompiledMethodLayout instead of ByteLayout. This is hacked in to the system really with âif the name is CompiledMethod, do not use ByteLayout but CompiledMethodLayout.â But now CompiledCode classLayout ==> "a CompiledMethodLayoutâ Which means yes, we have a class that we can not define! With the new class definition, this is explicit: CompiledCode << #CompiledBlock layout: CompiledMethodLayout; slots: {}; tag: 'Methods'; package: âKernel' Now of course we could have added ~20 methods (not sure if that is enoughâ¦) of a compiledMethodSubclass:, and added a version with the layout as a parameter (another 20+1 variants). But what if we want to add yet another parameter? What is *you* want to do that? With Fluid, class defintions are extensible, and we can easily extend them. 2) Why are variables not a list of names in a String anymore? Because we have âFirst Class Variablesâ: every variable in the system has a meta-object, which is implemented by a class. Point instanceVariables first "#x => InstanceVariableSlotâ So yes, there is an Object that represents âthe variable #x in Pointâ. With an api. The compiler delegates code generation to it fore read and write. You can think of it as a Meta Object Protocol for Variables... (I sometimes wonder if the name Slot was good, we could just think of it as âInstanceVariableâ in the sense of the Variable being modelled as an object, instead of a String). This is a big topic, but the idea is: letâs use Objects, not Strings! We can define our own kind of Variable (see the hierarchy of Variable), and the use of the array {} now allows us to actually define a class that uses this special kind of Variable. There is a presentation I did about it last year: https://vimeo.com/603398445 Marcus
Hello Marcus, Thanks for responding with thorough details, but I'm not such a good OO programmer, so what I need to know is; Will we be able to continue developing with Pharo using the same old Smalltalk-like syntax? Or, will there be major changes some time in the future? Like how (I think) "_" from Squeak was replaced with ":=" in Pharo! Thank you. On Wednesday, February 02, 2022 10:50 CET, Marcus Denker <marcus.denker@inria.fr> wrote: Â
On 2 Feb 2022, at 09:04, contactme@kathe.in wrote:
I have attached 2 cropped screen-captures of the same class displayed in the class browser; class-smalltalk.png is the regular class syntax, class-fluid.png is the same class but with the "Fluid" checkbox selected, and shows a different syntax.
This is no different syntax, as there is no Syntax (in the sense of Grammar) to define classes. These are all message sends, just like before.
May I know what that is all about?
There's a different terminology too, something called "slot", which I have faint memories of being quite like that in "Self" environments.
The Fluid class definition has two goals: 1) be extensible. With the ST80 way, any new parameter would mean adding *a lot* of methods. And every new parameter needs all the other variations, itâs a serious combinatorial explosion. Just an example: CompiledMethods and CompiledBlock use CompiledMethodLayout. But they are created with: CompiledCode variableByteSubclass: #CompiledMethod instanceVariableNames: '' classVariableNames: '' package: 'Kernel-Methods' So the system checks for the name and uses the CompiledMethodLayout instead of ByteLayout. This is hacked in to the system really with âif the name is CompiledMethod, do not use ByteLayout but CompiledMethodLayout.â But now CompiledCode classLayout ==> "a CompiledMethodLayoutâ Which means yes, we have a class that we can not define! With the new class definition, this is explicit: CompiledCode << #CompiledBlock layout: CompiledMethodLayout; slots: {}; tag: 'Methods'; package: âKernel' Now of course we could have added ~20 methods (not sure if that is enoughâ¦) of a compiledMethodSubclass:, and added a version with the layout as a parameter (another 20+1 variants). But what if we want to add yet another parameter? What is *you* want to do that? With Fluid, class defintions are extensible, and we can easily extend them. 2) Why are variables not a list of names in a String anymore? Because we have âFirst Class Variablesâ: every variable in the system has a meta-object, which is implemented by a class. Point instanceVariables first "#x => InstanceVariableSlotâ So yes, there is an Object that represents âthe variable #x in Pointâ. With an api. The compiler delegates code generation to it fore read and write. You can think of it as a Meta Object Protocol for Variables... (I sometimes wonder if the name Slot was good, we could just think of it as âInstanceVariableâ in the sense of the Variable being modelled as an object, instead of a String). This is a big topic, but the idea is: letâs use Objects, not Strings! We can define our own kind of Variable (see the hierarchy of Variable), and the use of the array {} now allows us to actually define a class that uses this special kind of Variable. There is a presentation I did about it last year: https://vimeo.com/603398445 Marcus  Â
On 7 Feb 2022, at 08:41, contactme@kathe.in wrote:
Hello Marcus,
Thanks for responding with thorough details, but I'm not such a good OO programmer, so what I need to know is; Will we be able to continue developing with Pharo using the same old Smalltalk-like syntax? Or, will there be major changes some time in the future? Like how (I think) "_" from Squeak was replaced with ":=" in Pharo!
:= is I think even ANSI Standard, or not? There are no plans for syntactical changes⦠But of course: The *goal* of Pharo is not to be Smalltalk80. I have to admit I kind of misunderstood Squeak back then⦠I really thought the idea if was to take ST80 as a startingoint âto invent the futureâ⦠I still like that idea, I have to say⦠to me what fascinates me is how to take something that is as of a great idea as ST80 and improve it⦠for example just consider the resources (in terms of memory or processing power or networking) we have today vs. 1978. The âletâs through it all away and start from scratchâ approach is not great, either⦠as you need something to buld upon. And: as soon as you finish that âbetterâ system, you would have the same problem: you would be stuck with a âfinishedâ system, while the world continues to evolve. It is a real interesting research question: How an you build Systems that can evolve over a long time ? Marcus
On Monday, February 07, 2022 08:57 CET, Marcus Denker <marcus.denker@inria.fr> wrote: Â
On 7 Feb 2022, at 08:41, contactme@kathe.in wrote:
Hello Marcus,
Thanks for responding with thorough details, but I'm not such a good OO programmer, so what I need to know is; Will we be able to continue developing with Pharo using the same old Smalltalk-like syntax? Or, will there be major changes some time in the future? Like how (I think) "_" from Squeak was replaced with ":=" in Pharo!
:= is I think even ANSI Standard, or not? There are no plans for syntactical changes⦠But of course: The *goal* of Pharo is not to be Smalltalk80. I have to admit I kind of misunderstood Squeak back then⦠I really thought the idea if was to take ST80 as a startingoint âto invent the futureâ⦠I still like that idea, I have to say⦠to me what fascinates me is how to take something that is as of a great idea as ST80 and improve it⦠for example just consider the resources (in terms of memory or processing power or networking) we have today vs. 1978. The âletâs through it all away and start from scratchâ approach is not great, either⦠as you need something to buld upon. And: as soon as you finish that âbetterâ system, you would have the same problem: you would be stuck with a âfinishedâ system, while the world continues to evolve. It is a real interesting research question: How an you build Systems that can evolve over a long time ? Systems which evolve over time need to have a very tiny core which is supremely malleable. For one, I would start with a "Forth" and add an object-system to it using the "Metaobject Protocol" along with a Common Lisp like "Condition System". Â
On 7 Feb 2022, at 09:10, contactme@kathe.in wrote:
On Monday, February 07, 2022 08:57 CET, Marcus Denker <marcus.denker@inria.fr> wrote:
On 7 Feb 2022, at 08:41, contactme@kathe.in wrote:
Hello Marcus,
Thanks for responding with thorough details, but I'm not such a good OO programmer, so what I need to know is; Will we be able to continue developing with Pharo using the same old Smalltalk-like syntax? Or, will there be major changes some time in the future? Like how (I think) "_" from Squeak was replaced with ":=" in Pharo!
:= is I think even ANSI Standard, or not?
There are no plans for syntactical changesâ¦
But of course: The *goal* of Pharo is not to be Smalltalk80.
I have to admit I kind of misunderstood Squeak back thenâ¦
I really thought the idea if was to take ST80 as a startingoint âto invent the futureâ⦠I still like that idea, I have to say⦠to me what fascinates me is how to take something that is as of a great idea as ST80 and improve it⦠for example just consider the resources (in terms of memory or processing power or networking) we have today vs. 1978.
The âletâs through it all away and start from scratchâ approach is not great, either⦠as you need something to buld upon. And: as soon as you finish that âbetterâ system, you would have the same problem: you would be stuck with a âfinishedâ system, while the world continues to evolve.
It is a real interesting research question: How an you build Systems that can evolve over a long time ?
Systems which evolve over time need to have a very tiny core which is supremely malleable. For one, I would start with a "Forth" and add an object-system to it using the "Metaobject Protocol" along with a Common Lisp like "Condition System".
Forth in the context of the core of an object system is interesting⦠someone did in 1979 a Smalltalk and Forth inspired system called âRosetta Smalltalk" https://dl.acm.org/doi/10.1145/1113572.1113555 <https://dl.acm.org/doi/10.1145/1113572.1113555> But: the nice thing of evolving a system is that you *always* can show a real, working result. You can have users, including yourself⦠you can find ways of financing your work that is not just promising something for the future. (which you can only do so often before people get sceptical). I think being part of the early Squeak community kind of burned for me the âletâs not improve that (relatively) simple thing A, instead wait for <genius X> to finish <amazing Project Z>. Imagine instead you would build a feedback-loop *inside* of your system... Marcus
On Monday, February 07, 2022 09:31 CET, Marcus Denker <marcus.denker@inria.fr> wrote: Â Â Â On 7 Feb 2022, at 09:10, contactme@kathe.in wrote:Â On Monday, February 07, 2022 08:57 CET, Marcus Denker <marcus.denker@inria.fr> wrote: Â
On 7 Feb 2022, at 08:41, contactme@kathe.in wrote:
Hello Marcus,
Thanks for responding with thorough details, but I'm not such a good OO programmer, so what I need to know is; Will we be able to continue developing with Pharo using the same old Smalltalk-like syntax? Or, will there be major changes some time in the future? Like how (I think) "_" from Squeak was replaced with ":=" in Pharo!
:= is I think even ANSI Standard, or not? There are no plans for syntactical changes⦠But of course: The *goal* of Pharo is not to be Smalltalk80. I have to admit I kind of misunderstood Squeak back then⦠I really thought the idea if was to take ST80 as a startingoint âto invent the futureâ⦠I still like that idea, I have to say⦠to me what fascinates me is how to take something that is as of a great idea as ST80 and improve it⦠for example just consider the resources (in terms of memory or processing power or networking) we have today vs. 1978. The âletâs through it all away and start from scratchâ approach is not great, either⦠as you need something to buld upon. And: as soon as you finish that âbetterâ system, you would have the same problem: you would be stuck with a âfinishedâ system, while the world continues to evolve. It is a real interesting research question: How an you build Systems that can evolve over a long time ? Systems which evolve over time need to have a very tiny core which is supremely malleable. For one, I would start with a "Forth" and add an object-system to it using the "Metaobject Protocol" along with a Common Lisp like "Condition System".   Forth in the context of the core of an object system is interesting⦠someone did in 1979 a Smalltalk and Forth inspired system called âRosetta Smalltalk" https://dl.acm.org/doi/10.1145/1113572.1113555 But: the nice thing of evolving a system is that you *always* can show a real, working result. You can have users, including yourself⦠you can find ways of financing your work that is not just promising something for the future. (which you can only do so often before people get sceptical). I think being part of the early Squeak community kind of burned for me the âletâs not improve that (relatively) simple thing A, instead wait for <genius X> to finish <amazing Project Z>. Imagine instead you would build a feedback-loop *inside* of your system...  Marcus Agree about what you felt within the Squeak community, I was there too around 1999~2000. There were a bunch of geniuses there, but the way I understand it, geniuses produce the initial spark, but you need strong-willed, perseverent people to kindle the project there-after. The reason I was drawn to Pharo is because of what Ducasse and you and others like you have done with the core spark of Smalltalk-80 based Squeak running Morphic. Though, I've always liked the MVC environment more and fell in love with the "Third-Way" project to deliver a full-blown widget-set for MVC developed by a guy called Gartner (I think) from Germany. Can you elaborate on your feedback-loop *inside* the system idea? Especially in the context of Pharo? Â
It is a real interesting research question: How an you build Systems that can evolve over a long time ?
Systems which evolve over time need to have a very tiny core which is supremely malleable. For one, I would start with a "Forth" and add an object-system to it using the "Metaobject Protocol" along with a Common Lisp like "Condition System".
Forth in the context of the core of an object system is interesting⦠someone did in 1979 a Smalltalk and Forth inspired system called âRosetta Smalltalk"
https://dl.acm.org/doi/10.1145/1113572.1113555 <https://dl.acm.org/doi/10.1145/1113572.1113555>
But: the nice thing of evolving a system is that you *always* can show a real, working result. You can have users, including yourself⦠you can find ways of financing your work that is not just promising something for the future. (which you can only do so often before people get sceptical).
I think being part of the early Squeak community kind of burned for me the âletâs not improve that (relatively) simple thing A, instead wait for <genius X> to finish <amazing Project Z>.
Imagine instead you would build a feedback-loop *inside* of your system...
Marcus
Agree about what you felt within the Squeak community, I was there too around 1999~2000. There were a bunch of geniuses there, but the way I understand it, geniuses produce the initial spark, but you need strong-willed, perseverent people to kindle the project there-after.
The reason I was drawn to Pharo is because of what Ducasse and you and others like you have done with the core spark of Smalltalk-80 based Squeak running Morphic. Though, I've always liked the MVC environment more and fell in love with the "Third-Way" project to deliver a full-blown widget-set for MVC developed by a guy called Gartner (I think) from Germany.
Do you have a pointer?
Can you elaborate on your feedback-loop *inside* the system idea? Especially in the context of Pharo?
So your âSystems which evolve over time need to have a very tiny core which is supremely malleableâ I actually think is very true.. and Pharo clearly is not there yet. (and what that even is supposed to be.. has many answers). But what we technical people are the quickly to say âa malleable system needs a very tiny core, so letâs first do thatâ. And abandon what we have. But if you step back, for the end-âuserâ (that is programmer) it would not change much, it would solve nothing on that level of the problem of how to evolve a platform *and* the systems using it. Which might be even harder to do right than the kernel... Another aspect is that âlets build the perfect evolvable systemâ is as impossible as âlets build the perfect systemâ⦠when you are done, you realise that you could do even better! Marcus
On 10/02/22 9:33, Marcus Denker wrote:
So your âSystems which evolve over time need to have a very tiny core which is supremely malleableâ I actually think is very true.. and Pharo clearly is not there yet. (and what that even is supposed to be.. has many answers).
But what we technical people are the quickly to say âa malleable system needs a very tiny core, so letâs first do thatâ. And abandon what we have.
But if you step back, for the end-âuserâ (that is programmer) it would not change much, it would solve nothing on that level of the problem of how to evolve a platform *and* the systems using it. Which might be even harder to do right than the kernel...
Another aspect is that âlets build the perfect evolvable systemâ is as impossible as âlets build the perfect systemâ⦠when you are done, you realise that you could do even better!
Marcus
Recently I was seeing some videos abut GToolkit and Cuis and I thought about how both approach to malleability/understandability in different interesting ways: Cuis by providing a small extensible core that gets simpler over time and GToolkit by providing a compelling default user experience that invites to use and query the system in different ways. I think that the ways Smalltalk systems approach malleability (particularly Pharo/Cuis based) can have deep impacts for populations beyond programmers, as showcased in my recent list post about sharing data stories powered by Pharo, that in fact related with Malleable Systems Wiki [1], [1] https://mutabit.com/repos.fossil/malleable-systems/doc/trunk/wiki/en/malleab... Cheers, Offray
On Thursday, February 10, 2022 15:33 CET, Marcus Denker <marcus.denker@inria.fr> wrote:   It is a real interesting research question: How an you build Systems that can evolve over a long time ? Systems which evolve over time need to have a very tiny core which is supremely malleable. For one, I would start with a "Forth" and add an object-system to it using the "Metaobject Protocol" along with a Common Lisp like "Condition System".   Forth in the context of the core of an object system is interesting⦠someone did in 1979 a Smalltalk and Forth inspired system called âRosetta Smalltalk" https://dl.acm.org/doi/10.1145/1113572.1113555 But: the nice thing of evolving a system is that you *always* can show a real, working result. You can have users, including yourself⦠you can find ways of financing your work that is not just promising something for the future. (which you can only do so often before people get sceptical). I think being part of the early Squeak community kind of burned for me the âletâs not improve that (relatively) simple thing A, instead wait for <genius X> to finish <amazing Project Z>. Imagine instead you would build a feedback-loop *inside* of your system...  Marcus Agree about what you felt within the Squeak community, I was there too around 1999~2000. There were a bunch of geniuses there, but the way I understand it, geniuses produce the initial spark, but you need strong-willed, perseverent people to kindle the project there-after. The reason I was drawn to Pharo is because of what Ducasse and you and others like you have done with the core spark of Smalltalk-80 based Squeak running Morphic. Though, I've always liked the MVC environment more and fell in love with the "Third-Way" project to deliver a full-blown widget-set for MVC developed by a guy called Gartner (I think) from Germany.  Do you have a pointer?---- Yes, I got the URL after searching through Google a lot of times. :-) His name is Boris Gaertner and he is/was from Germany. https://wiki.squeak.org/squeak/1829.diff?id=19 I couldn't find his webpage though, and I couldn't locate the code of his framework. Maybe you could ask on the Squeak mailing list!  Can you elaborate on your feedback-loop *inside* the system idea? Especially in the context of Pharo?   So your âSystems which evolve over time need to have a very tiny core which is supremely malleableâ I actually think is very true.. and Pharo clearly is not there yet.(and what that even is supposed to be.. has many answers). But what we technical people are the quickly to say âa malleable system needs a very tiny core, so letâs first do thatâ. And abandon what we have.  But if you step back, for the end-âuserâ (that is programmer) it would not change much, it would solve nothing on that level of the problem of howto evolve a platform *and* the systems using it. Which might be even harder to do right than the kernel... Another aspect is that âlets build the perfect evolvable systemâ is as impossible as âlets build the perfect systemâ⦠when you are done, yourealise that you could do even better!  Marcus---- Yes, I agree on the point of things just never being done in the world of software. Though, I do tend to think "Common Lisp" is a done language, but their development environments (even commercial ones) leave a lot to be desired. For a moment think from the perspective of art, as one of the greats had mentioned; perfection is achieved when there's nothing more to take away. I think what you and the core team did using the stuff (core Squeak + Morphic) available to you back then without knowledge about Boris Gaertner's work is quite an achievement. But Pharo is really too big, especially when you compare it with a standard Smalltalk-80 system. Maybe the core team "could" consider going along the same path of cleaning-up and simplifying the core Smalltalk system further but instead of working with the bloat of Morphic, instead go with that MVC-based "ThirdWay" framework! In fact, I would wholeheartedly support the core team changing a lot of what it means to be Smalltalk if the end result can be made smaller and more malleable. As an example of a minimalistic and extremely malleable language, take a look at "io"; https://iolanguage.org/ Yes, it's a lot bigger than a Forth, but at least it won't drive normal people to insanity. :-D Just a suggestion, no intention of denigrating the work that has been done till date. Â
participants (3)
-
contactme＠kathe.in -
Marcus Denker -
Offray Vladimir Luna Cárdenas