[ANN] Smalltalk's Successor
Locked
 
|
A bold claim. It'll be interesting to see if anybody challenges me on this. |
Re: [ANN] Smalltalk's Successor
|
|
Here is a challenge: What is "Smalltalk"? VAST, VW, and Pharo are quite different environments. To the extent that they share a common syntax (which they don't, quite), fine, but porting nontrivial code between them is NOT easy. They certainly have very little in common as GUI kits. All praise and thanks to the people who *have* ported stuff. On Tue, 11 Aug 2020 at 01:05, Richard Kenneth Eng <[hidden email]> wrote:
|
|
|
It's true, Smalltalk faces the same dilemma as Linux and Lisp. As a /family/
of languages, portability is a genuine issue. There's no getting around this dichotomy. You can have either a flexibility of choice or the tyranny of one standard, but not both. The decision is a fact of life that we face frequently. You can have either the flexibility of dynamic typing or the safety of static typing, but not both. You can have either the natural modelling of the real world due to state mutation or the mathematical safety of immutability, but not both. You can have either the portability of a virtual machine or the close-to-the-metal performance of native code generation, but not both (JIT compilation notwithstanding). Life is about choices. There will always be a place for different technologies. Smalltalk will not always be the ideal choice. That's why there are five entirely different languages that dominate our industry (Python, JavaScript, Java, C#, C++). There is no reason why there can't be a sixth, especially if it can dramatically improve our productivity and make programming less cognitively stressful. Surely, that's worth fighting for. Enough? Richard O'Keefe wrote > Here is a challenge: What is "Smalltalk"? > VAST, VW, and Pharo are quite different environments. > To the extent that they share a common syntax (which > they don't, quite), fine, but porting nontrivial > code between them is NOT easy. They certainly have > very little in common as GUI kits. All praise and > thanks to the people who *have* ported stuff. > > > On Tue, 11 Aug 2020 at 01:05, Richard Kenneth Eng < > horrido.hobbies@ > > > wrote: > >> https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ >> >> A bold claim. It'll be interesting to see if anybody challenges me on >> this. >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Re: [ANN] Smalltalk's Successor
|
|
Richard
if you would like to have a real impact why don’t you help for real to copy edit and improve documentation. This is not your articles that will attract people, a strong documentation smoothing the learning curve will. This is super easy you can edit text right in your web browser. I do not think that you understand what I’m saying but I had to try. We have not many native english speakers and having better and more documentation is super important but if people can could help don’t do it then we will do it slower. S
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France |
Re: [ANN] Smalltalk's Successor
|
|
In reply to this post by horrido
Hi,
On the issue of families of technologies (Lisp and Linux), I see that the article's conclusion doesn't work well in the languages front, as it does on the operative systems one. If you replace the title with Lisp's successor or Linux's successor, the articles conclusion changes, because of the way families of Linux distributions and Lips variants evolve. So you can say that because the diversity of Linux distributions, we don't need (yet) a Linux's successor, while you can say that, because of the diversity of Lisp languages, we already have in fact several Lisp's successors (Racket, Clojure and so on), all of them recognizing their Lisp lineage, but trying to improve and evolve on specific fields (By the way a worthy mention on your list would be Cuis Smalltalk). I see that your articles tend to reiterate the same points time and again about Smalltalk (historicity, simplicity, agility, proven record), which can be fine for a new comer to it, but gets old for the people who is actually engaging with reading you. Blog title changes, addressed a particular point and comes back to the repeated arguments in favor of Smalltalk and then it retakes the starting point with a conclusion. Maybe you could create a single page where you can point your readers, with companion images, videos and notes and just mention briefly the favorable points of Smalltalk for a blog newcomer with a link to your reiterated detailed arguments. With reiteration covered, you may be willing to consider some blind spots which are present (and of course are part of any writing process as they represent a point of view). I know that popularity is the main motive behind the Smalltalk Renaissance efforts, but addressing the blind spots in the search for popularity, could be useful to consider: how popular is popular enough? In a world which values popularity so much (particularly in places of the Global North) which are the disadvantages of popularity? Can a community have the "proper size" to move quickly enough and have good support and funding? Which business and needs are well served disregarding of choosing popular technologies? Just as a thought experiment, as the ones you ask to your non Smalltalk readers to consider options beyond the ones they persue, If popularity is not the best place to focus effort, which could be a good place to do it? Thanks for the conversation, Offray On 10/08/20 8:07 p. m., horrido wrote: > It's true, Smalltalk faces the same dilemma as Linux and Lisp. As a /family/ > of languages, portability is a genuine issue. > > There's no getting around this dichotomy. You can have either a flexibility > of choice or the tyranny of one standard, but not both. > > The decision is a fact of life that we face frequently. You can have either > the flexibility of dynamic typing or the safety of static typing, but not > both. You can have either the natural modelling of the real world due to > state mutation or the mathematical safety of immutability, but not both. You > can have either the portability of a virtual machine or the > close-to-the-metal performance of native code generation, but not both (JIT > compilation notwithstanding). > > Life is about choices. There will always be a place for different > technologies. Smalltalk will not always be the ideal choice. That's why > there are five entirely different languages that dominate our industry > (Python, JavaScript, Java, C#, C++). > > There is no reason why there can't be a sixth, especially if it can > dramatically improve our productivity and make programming less cognitively > stressful. Surely, that's worth fighting for. > > Enough? > > > > Richard O'Keefe wrote >> Here is a challenge: What is "Smalltalk"? >> VAST, VW, and Pharo are quite different environments. >> To the extent that they share a common syntax (which >> they don't, quite), fine, but porting nontrivial >> code between them is NOT easy. They certainly have >> very little in common as GUI kits. All praise and >> thanks to the people who *have* ported stuff. >> >> >> On Tue, 11 Aug 2020 at 01:05, Richard Kenneth Eng < >> horrido.hobbies@ >> > >> wrote: >> >>> https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ >>> >>> A bold claim. It'll be interesting to see if anybody challenges me on >>> this. >>> >>> > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > |
Re: [ANN] Smalltalk's Successor
|
|
In reply to this post by horrido
The contrast between "flexibility of choice" and "tyranny of one standard" is, um, a little over-drawn. I have three different Common Lisp systems on this laptop: CMUCL, SBCL, and CCL. I have the flexibility of choice between them *because* the adhere to a common standard. Each of them has its own extra bits, but I am free to choose between them because everything *else* is not idiosyncratic. I have a choice of machine learning libraries for Python, but that is useful to me because the *rest* of Python isn't different, so there's a huge amount of stuff I can use with an ML program. In Smalltalk I cannot even port a program that opens a file for input, another one for output, and copies the one to the other, despite everything I need being in the ANSI Smalltalk standard. I mean come ON! I have two commercial Smalltalks, two formerly commercial Smalltalks, three free Smalltalks, and several Smalltalk implementations that were never quite finished, and no two of them handle Unicode the same way! Think about it: you have "Καλημέρα κόσμε" in a file, and no part of trying to copy that file is portable. Let's not mention Sockets, OK? Let's just not go there. Choice and consistency are NOT a dichotomy. They are both important. You need consistency at one level to construct choices at the next level. I note that there are type systems available for Prolog, Erlang, Scheme, and Python (https://realpython.com/python-type-checking/) and I've done work on a type inference program for AWK. Also that there are dynamic type facilities for Haskell and Clean. So dynamic types -vs- static types are not a hard dichotomy either. On Tue, 11 Aug 2020 at 13:08, horrido <[hidden email]> wrote: It's true, Smalltalk faces the same dilemma as Linux and Lisp. As a /family/ |
|
|
Am 12.08.20 um 06:28 schrieb Richard O'Keefe:
> The contrast between "flexibility of choice" and "tyranny of one > standard" is, um, a little over-drawn. I have three different Common > Lisp systems on this laptop: CMUCL, SBCL, and CCL. I have the > flexibility of choice between them *because* the adhere to a common > standard. Each of them has its own extra bits, but I am free to choose > between them because everything *else* is not idiosyncratic. Very true. Software tends to form high stacks with many layers of dependencies. Productive work on any given layer requires stability in the layers below. But if anyone depends on *your* work, that's a constraint on your freedom to innovate. Smalltalk today is in the same situation as Scheme (but unlike Common Lisp): there are more people interested in evolving Smalltalk than people building applications on top of Smalltalk. And that makes Smalltalk unattractive for those application builders for whom the progress in the quality of their tools is not worth the cost of the diversity and instability that require constant attention. It all depends on what you are working on, and in particular on the time scale of evolution of your work. If your application's requirement change rapidly, it's easier to deal with an unstable platform than if you are working on a complex design to be used over decades. Konrad. |
Re: [ANN] Smalltalk's Successor
|
|
"Protect me from my friends I will deal with my ennemies."
Pharo is Pharo. The smalltalk community likes to complain but we prefer to invent the future. For the record we are helping companies to DELIVER and we are engaging any people that want to invent the future with us. I have often the impression that having success is bad in this wonderful communauty Horrido can’t you spend your energy in something more productive? What a drag? Richard O’Keefe, this is a pity because we will never learn much from your experience. Anyway this is your choice but a strange one. I would love to have a type inferencer for Pharo. Sorry no time to spend more time on this. S. I did not do Pharo for ego I did it because else I would have join Lua or Python because Squeak and VW were killing my Smalltalk flame. I prefer doing than talking. |
|
|
In reply to this post by Offray Vladimir Luna Cárdenas-2
You are quite right, which is why I'm retiring as Smalltalk evangelist. There
is simply nothing more I can say about Smalltalk. Over the last 5 years, I've said everything there is to say and I've said them in every way imaginable. My last act as Smalltalk evangelist will be Camp Smalltalk Supreme in 2022. Then I shall spend the remainder of my days searching for personal enlightenment. Offray Vladimir Luna Cárdenas-2 wrote > I see that your articles tend to reiterate the same points time and > again about Smalltalk (historicity, simplicity, agility, proven record), > which can be fine for a new comer to it, but gets old for the people who > is actually engaging with reading you. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Re: [ANN] Smalltalk's Successor
|
|
You could have probably a lot more impact developing a couple of nice libraries (I have tons of ideas) or to write some little book chapters.
Now my state of mind is that we can always learn something and we can always do something small but that it an improvement. You believed that advocating smalltalk will resurrect. It wont.
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France |
Re: [ANN] Smalltalk's Successor
|
|
In reply to this post by Stéphane Ducasse
Am I starting to hallucinate, or did I read some time in the last year that there are plans for a "long term stability" branch of Pharo? That had me giving thanks. Pharo is splendid, and that will give us the best of both worlds: a stable base for development WITHOUT holding back development of Pharo itself. I think Stéphane Ducasse may have completely misunderstood me. I wonder what he thinks my "choice" is? The only choice I'm aware of making is to continue being engaged with Pharo. (Hint: I am not on the Squeak mailing list. I don't even know if there is one any more.) The unpleasantly disparate nature of "Smalltalk" does not make *Pharo* a bad choice, it just means that anyone who develops in Pharo with the aim of deploying in VW is facing a much harder task than they might have been led to expect. I would also like to praise S.D. and his merry band for (a) the free Smalltalk books (b) the continuing series of books specifically about Pharo. Is there some way I can contribute to the Pharo book(let)s? I'm not too bad at proof-reading. On Thu, 13 Aug 2020 at 01:43, Stéphane Ducasse <[hidden email]> wrote: "Protect me from my friends I will deal with my ennemies." |
Re: [ANN] Smalltalk's Successor
|
|
One other point. When I saw the subject line "Smalltalk's successor", I expected to read that *Pharo* already is Smalltalk's successor, what with traits and GT and direct support for Git &c. I think "The future of Smalltalk is not far-off it's Pharo and it's here" is a claim that could well be made. On Thu, 13 Aug 2020 at 13:44, Richard O'Keefe <[hidden email]> wrote:
|
Re: [ANN] Smalltalk's Successor
|
|
In reply to this post by Richard O'Keefe
Ok please accept my apologies if I hurt you.
My point richard is that you can have an impact on Pharo. It is easy if you design libraries running on top of Pharo and make them public. S.
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France |
|
|
In reply to this post by Richard O'Keefe
Hi Richard,
I had the same impression, that "Pharo is Smalltalk's successor". (Without any negative feelings toward VAST and VW; they fill a very important role for commercial use -- businesses depend on the kind of support that a commercial distribution provides and are very willing to fund that.) The future of Smalltalk is being created every day with commits to the Pharo Project. Who's to say a company can't be created to provide commercial support for Pharo in the way that Red Hat does for Linux? And the Pharo Consortium is, in many ways, already one such entity. So please do contribute to making the booklets better, Richard! I started last fall (and need to start up again) and found it very fulfilling, as well as educational. It's easy to do; for you & others, here are the basic steps: 1. Fork a booklet repository and then clone it. 2. Set a git 'upstream' to the original (because you'll be trading revisions as you go). 3. Edit the Pillar markdown, add new material, etc. 4. Push and submit a Pull Request. 5. Continue working (i.e., start a 'pipeline' of edit submissions). 6. Note that you can modify the target of a PR while the PR is still "in review". 6. Check the WIP 'releases' that the CI system generates to proofread. I was using Atom and it's markdown rendering, which is imperfect, but it was sufficient. Sean DeNigris recently suggest editing in Gtoolkit's live Pillar editor: "It's beta, but a compelling experience. I did a little screencast here: https://youtu.be/GZOYF82h9qA". I'm looking at it this week for my own use. There's also the 'Documentation' channel on the Pharo Discord site. I'd like to see the 'doc writers' start to interact there (and here); the last Discord entry was 6 weeks ago... -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |