Opening this one as part of an issue raised in powerlang repo by Boris
As it was suggested: to conserve the related Slack thread in BA-ST in a somewhat-more-permanent medium, I am cut-and-pasting it here:
leandro:
Acabo de crear el canal #smalltalk-ide-as para ver si podemos identificar buenas ideas para una IDE de Smalltalk.
shingarov:
My favorite would be, "How to get rid of IDEs altogether."
Seriously, in my search for departure away from Smalltalk-80 towards the true Smalltalk, IDEs and "the" Browser are nearly crowning my "list of anti-Smalltalk concepts in Smalltalk-80". This is for several reasons.
First: ossification.
In his obituary of Larry Tesler, Kent Beck relates the following story:
The early Smalltalkers knew they needed a browser, a way to navigate, understand, and modify the code in the system. The core group went off to talk about it. Larry got pissed, just wrote a damn browser (the design of which, much to his disgust, persists today 45 years later), and showed it to them when they returned.
I had various discussions with fellow Smalltalkers about what the moral of this story is, and heard things along the lines of, "just do it, instead of sitting in committees"; I think such interpretation would be too shallow. The key to understanding Larry here, is the indefinite article: "a browser" -- just one out of thousands of possibilities to be explored by the programmer. But Smalltalk-80 fixated Larry's sketch into the status of "The Browser", thus reinforcing the barrier between "the application" and "the Smalltalk system". Such ossification is exactly the opposite of what Smalltalk is all about.
The word "IDE" stinks even worse, suggesting imagery of "immutable, Smalltalk-vendor-provided tools." (Ok, replace "vendor" with "implementer" and it doesn't improve much).
What we need instead, is to create such tools on the spot, at the moment the need arises. For example, to design and implement the JIT-postmortem debug UI I showed at the hackathon, took 1 day. Well, 2 days if we count in the time I spent familiarizing with Tudor's APIs. Speaking of which -- I very much agree with the GT approach. (In the Museum of History of Science in Cambridge, there is a spectacular collection of visual models -- enough to convince anyone that the scientific "discovery" is at least as much about seeing and showing as it is about, well, discovery proper). At the same time I like to emphasize that interesting "[micro/tele/...]scopes" are only possible thanks to the interesting structures they are visualizing. For example, Tudor's Debugger-as-Context-Inspector is only possible because we have Contexts in the first place. This is nontrivial because Smalltalk still has to learn a lot from languages like ML which offers the programmer incredible depth of debugging insight -- through a primitive command-line interface.
This is a two-way street.
The ossification of the tools, and the ossification of the fundamental data structures, have been -- I think -- mutually-causing in Smalltalk-80. And vice-versa: whatever interesting development of one, will inevitably cause interesting development of the other. Today, I am altogether not happy about what constructions I can express in Smalltalk. We have a straightforward mechanism for products (just stick the factors into the object's "slots"). For co-products... we are supposed to use class polymorphism. Actually, we are supposed to express all constructions as combinations of "slots" and "subclassing". This can be really awkward: think of true and false -- the simplest construction of choice between two discrete points -- how we have to jump through hoops to e.g. disallow creating additional instances of True, etc. We have a whole bunch of these -- they are called Design Patterns -- solutions to problems that shouldn't be problems in the first place.
So, what I want in the first place is an algebra of universal constructions in my language. And then I want to be able to play with them without crashing the live Smalltalk system -- think of trying to change Smalltalk's metaobject protocol, even though it is written in Smalltalk (for example, change Squeak's class-as-species-membership to Bee's class-as-a-behavior). Finally, once I have a myriad of object models, each will inspire its own set of tools, will imply its own universe of possible IDEs.
guilleamaral:
speaking about ossification, it seems like not only you are questioning the skin but also the bones... I think your channel should have been "How to get rid of the whole thing!" then!
seriously, though we agree on that the path taken by GT seems to break with the tooling dogma, you see more structural changes on the way to a purer smalltalk... or would we name it differently?
shingarov:
or would we name it differently?
We would name it Smalltalk.
Let me provide some background of how this "Smalltalk of the future" project started.
At ESUG'14 in Cambridge, right after my presentation, we sat down at one of those little coffee-tables and had a chat with Dan Ingalls, and I asked: "why is Smalltalk doing so poorly these decades?" -- and he said: "Because we have no Smalltalk; this what we have is Smalltalk-80 and it's not a Smalltalk."
So.
To secure a future for Smalltalk, the first thing we need is to build one. Good examples to follow would be Smalltalk-71, Smalltalk-72, Smalltalk-76. I call mine "Smalltalk-25", but let me emphasize that I mean it to be "a Smalltalk" just like Larry sketched his browser to be "a browser".
it seems like not only you are questioning the skin but also the bones
Yes, absolutely.
To keep close to the present topic of IDEs:
If I am building a new-generation tool, and some core structure is blocking me, then I have no other choice than to redesign that structure. (As a familiar illustration: imagine you are designing the Debugger, and the core runtime doesn't have Contexts. At this point, you have only two options: (1) give up altogether, or (2) redesign the VM to allow reification of sends). So, it's not that I chose to question-the-bones by licence (because-I-felt-like-it or something) -- but because I am forced to.
These forced redesign steps lead one to the next, forming chains of inevitability. What's scary is how far this chain goes.
I started from the modest scope of designing a better debugger [for my own VM debugging needs] which would be relevant/competitive in the force of what the competition has in ~2020. The very first thing I bumped into was that I was blocked by this VM fundamentally rooted in the Deutsch--Schiffman'83 design. So you start reevaluating DS'83 from first principles, and you immediately discover that your life is defined by the larget context of the computing-technology stack. Which means you are at a roadfork of two options.
One is, what I call "the SKAMP approach" after Alan Knight's article "The Smalltalk Kick-Ass MegaProcessor" (in Smalltalk Report ca. 1993). The argument was that, dynamic languages such as Smalltalk are such a tiny niche that any benefit from a hardware-accelerated Smalltalk processor [and other layers in the technology stack] is meaningless given the economy of scale. So as dynamic-language-VM designers, we are stuck to play by the rules given by the big guys.
This is all the more unfortunate because the layers of the technology stack are not mutually-neutral. E.g. the processor and the language compiler are co-designed in a tight whole of cause-and-effect considerations. To be outside of that whole, means that conforming to the rules becomes increasingly more difficult as the technology progresses forward, stretching this first "SKAMP approach" to its limit.
Two big tide-waves in the last decade have effected why modern dynamic-language-VM design has started to follow an opposite approach. 1: We have witnessed the stretch actually break for [certain] production customers. 2: Dynamic languages are no longer niche: people buy computers (be that phones, servers, whatever) to run JS, Python, Java etc.
For example, a number of VM people (Mario, Jecel, myself,... many others) have formed the "J-Extension" Task Group within RISC-V (which is itself a "fifth generation" of SOAR (Smalltalk-on-a-RISC)), so the new ISA is co-designed together with the VM.
And now that we are playing in the big guys' sandbox, now this chain-of-inevitability extends even further. Now we are embedded in the co-design of the technology stack (and collaborating on the Processor Architecture, the Verification, the Platform, etc.) Further, the technology stack itself is embedded in the co-design of society. Which itself is moving; for example, the values that existed in "the XEROX PARC decade" (referring to my message in #books here) may not correspond with today's dichotomy between the group of creators vs strict-consumers.
Opening this one as part of an issue raised in powerlang repo by Boris
As it was suggested: to conserve the related Slack thread in BA-ST in a somewhat-more-permanent medium, I am cut-and-pasting it here:
leandro:
shingarov:
My favorite would be, "How to get rid of IDEs altogether."
Seriously, in my search for departure away from Smalltalk-80 towards the true Smalltalk, IDEs and "the" Browser are nearly crowning my "list of anti-Smalltalk concepts in Smalltalk-80". This is for several reasons.
First: ossification.
In his obituary of Larry Tesler, Kent Beck relates the following story:
I had various discussions with fellow Smalltalkers about what the moral of this story is, and heard things along the lines of, "just do it, instead of sitting in committees"; I think such interpretation would be too shallow. The key to understanding Larry here, is the indefinite article: "a browser" -- just one out of thousands of possibilities to be explored by the programmer. But Smalltalk-80 fixated Larry's sketch into the status of "The Browser", thus reinforcing the barrier between "the application" and "the Smalltalk system". Such ossification is exactly the opposite of what Smalltalk is all about.
The word "IDE" stinks even worse, suggesting imagery of "immutable, Smalltalk-vendor-provided tools." (Ok, replace "vendor" with "implementer" and it doesn't improve much).
What we need instead, is to create such tools on the spot, at the moment the need arises. For example, to design and implement the JIT-postmortem debug UI I showed at the hackathon, took 1 day. Well, 2 days if we count in the time I spent familiarizing with Tudor's APIs. Speaking of which -- I very much agree with the GT approach. (In the Museum of History of Science in Cambridge, there is a spectacular collection of visual models -- enough to convince anyone that the scientific "discovery" is at least as much about seeing and showing as it is about, well, discovery proper). At the same time I like to emphasize that interesting "[micro/tele/...]scopes" are only possible thanks to the interesting structures they are visualizing. For example, Tudor's Debugger-as-Context-Inspector is only possible because we have Contexts in the first place. This is nontrivial because Smalltalk still has to learn a lot from languages like ML which offers the programmer incredible depth of debugging insight -- through a primitive command-line interface.
This is a two-way street.
The ossification of the tools, and the ossification of the fundamental data structures, have been -- I think -- mutually-causing in Smalltalk-80. And vice-versa: whatever interesting development of one, will inevitably cause interesting development of the other. Today, I am altogether not happy about what constructions I can express in Smalltalk. We have a straightforward mechanism for products (just stick the factors into the object's "slots"). For co-products... we are supposed to use class polymorphism. Actually, we are supposed to express all constructions as combinations of "slots" and "subclassing". This can be really awkward: think of
trueandfalse-- the simplest construction of choice between two discrete points -- how we have to jump through hoops to e.g. disallow creating additional instances ofTrue, etc. We have a whole bunch of these -- they are called Design Patterns -- solutions to problems that shouldn't be problems in the first place.So, what I want in the first place is an algebra of universal constructions in my language. And then I want to be able to play with them without crashing the live Smalltalk system -- think of trying to change Smalltalk's metaobject protocol, even though it is written in Smalltalk (for example, change Squeak's class-as-species-membership to Bee's class-as-a-behavior). Finally, once I have a myriad of object models, each will inspire its own set of tools, will imply its own universe of possible IDEs.
guilleamaral:
shingarov:
We would name it Smalltalk.
Let me provide some background of how this "Smalltalk of the future" project started.
At ESUG'14 in Cambridge, right after my presentation, we sat down at one of those little coffee-tables and had a chat with Dan Ingalls, and I asked: "why is Smalltalk doing so poorly these decades?" -- and he said: "Because we have no Smalltalk; this what we have is Smalltalk-80 and it's not a Smalltalk."
So.
To secure a future for Smalltalk, the first thing we need is to build one. Good examples to follow would be Smalltalk-71, Smalltalk-72, Smalltalk-76. I call mine "Smalltalk-25", but let me emphasize that I mean it to be "a Smalltalk" just like Larry sketched his browser to be "a browser".
Yes, absolutely. To keep close to the present topic of IDEs: If I am building a new-generation tool, and some core structure is blocking me, then I have no other choice than to redesign that structure. (As a familiar illustration: imagine you are designing the Debugger, and the core runtime doesn't have Contexts. At this point, you have only two options: (1) give up altogether, or (2) redesign the VM to allow reification of sends). So, it's not that I chose to question-the-bones by licence (because-I-felt-like-it or something) -- but because I am forced to.
These forced redesign steps lead one to the next, forming chains of inevitability. What's scary is how far this chain goes.
I started from the modest scope of designing a better debugger [for my own VM debugging needs] which would be relevant/competitive in the force of what the competition has in ~2020. The very first thing I bumped into was that I was blocked by this VM fundamentally rooted in the Deutsch--Schiffman'83 design. So you start reevaluating DS'83 from first principles, and you immediately discover that your life is defined by the larget context of the computing-technology stack. Which means you are at a roadfork of two options.
One is, what I call "the SKAMP approach" after Alan Knight's article "The Smalltalk Kick-Ass MegaProcessor" (in Smalltalk Report ca. 1993). The argument was that, dynamic languages such as Smalltalk are such a tiny niche that any benefit from a hardware-accelerated Smalltalk processor [and other layers in the technology stack] is meaningless given the economy of scale. So as dynamic-language-VM designers, we are stuck to play by the rules given by the big guys.
This is all the more unfortunate because the layers of the technology stack are not mutually-neutral. E.g. the processor and the language compiler are co-designed in a tight whole of cause-and-effect considerations. To be outside of that whole, means that conforming to the rules becomes increasingly more difficult as the technology progresses forward, stretching this first "SKAMP approach" to its limit.
Two big tide-waves in the last decade have effected why modern dynamic-language-VM design has started to follow an opposite approach. 1: We have witnessed the stretch actually break for [certain] production customers. 2: Dynamic languages are no longer niche: people buy computers (be that phones, servers, whatever) to run JS, Python, Java etc.
For example, a number of VM people (Mario, Jecel, myself,... many others) have formed the "J-Extension" Task Group within RISC-V (which is itself a "fifth generation" of SOAR (Smalltalk-on-a-RISC)), so the new ISA is co-designed together with the VM.
And now that we are playing in the big guys' sandbox, now this chain-of-inevitability extends even further. Now we are embedded in the co-design of the technology stack (and collaborating on the Processor Architecture, the Verification, the Platform, etc.) Further, the technology stack itself is embedded in the co-design of society. Which itself is moving; for example, the values that existed in "the XEROX PARC decade" (referring to my message in #books here) may not correspond with today's dichotomy between the group of creators vs strict-consumers.