ben-coman
and... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/p...
Traditionally Pharo could only create standalone applications, but the minheadless builds are making good progress on stripping the windowing code to facilitate it being embeddable.
A platform specific VM runs on Windows, Linux, OSX. All those VMs run a single application binary.
Then try these one-liners in the Playground... https://medium.com/concerning-pharo/elegant-pharo-code-bb590....
Then (and I know its a video) but maybe serverless PharoLambda would interest you... https://www.youtube.com/watch?v=YUbd0-FX6pI
One aspect of simplicity is its minimal syntax... https://en.wikipedia.org/wiki/File:Pharo_syntax_postcard.svg
Stephane Ducasse wrote:
> I told them NOT to use github.
> I told them that Bloc was alpha. They got a large list of topics and could have picked another one.
> Now of course we should improve and they too.
This is not saying that everything in Pharo is perfect, but in future could you please frame your criticism to indicate your pain with Pharo was with alpha features.
"The only languages worth learning are those that change the way you think about programming."
btw, see the section here on "Blub Paradox" (http://www.paulgraham.com/avg.html ) which means I'm not really competent to comment of C#'s dynamic objects.
It seems C# work by subclassing the DynamicObject class. What about dynamically extending all the other existing C# classes?
What if I subclassed a C# Queue as MyQueue and then while my days long simulation was running I wanted add an instance variable 'trackCount' to all existing MyQueue instances? In Pharo all you do is this...
Queue subclass: #MyQueue instanceVariableNames: ’trackCount’ classVariableNames: ’’ poolDictionaries: ’’ category: ’Example’
and program keeps running, this definition is updated in the editor.
But Pharo is all about the deep integration of the tooling. Its what facilitates such a tight Code->Compile->Run->Debug cycle. It can take a while for the penny to drop. If you do a drive-by taste of Pharo you probably didn't get chance to really get into the flow.
Some say... "The only programming languages worth learning are those that change the way you think about programming." And Pharo/Smalltalk tooling does that.
btw, which was the CUIS prototype framework you used? There should be little reason it couldn't be made to run on Pharo.
Stephane Ducasse wrote:
> I told them NOT to use github.
> I told them that Bloc was alpha. They got a large list of topics and could have picked another one.
> Now of course we should improve and they too.
I don't know what it means that there is not later reports. The consortium is definitely active. It arose because open source software is about people scratching an itch, and often the focus is on the fun stuff and not on the boring, difficult, dirty engineering required to make a product reliable and successful (e.g. operating a CI infrastructure). Pharo arose out of INRIA[1], one of France's publicly funded national research institutes. But their mission and governance structure is not suited to managing non-research engineers dedicated to working on Pharo. So InriaSoft[2] was created to fork off its successful software into consortiums funding pure engineering work on the software as an ongoing concern. At the moment the consortium has one full-time engineer, but hope to get another in the next couple of years if the consortium continues the current growth rate.
AFAIK (I am not directly involved), the main efforts decided by consortium members were:
* Stabilizing 32-bit to 64-bit conversion for Pharo, utilizing and contributing to the OpenSmalltalk-VM project.
* Stablizing Iceberg as our Git/GUI interface
* Maintaining CI infrastructure
btw, There is also the Pharo Association with 82 individual members. [3]
[1] https://www.inria.fr/en/institute/inria-in-brief/inria-in-a-... [2] https://www.inria.fr/en/news/news-from-inria/launch-of-inria... [3] https://association.pharo.org/
Here are commercial companies that believe in Pharo (in the money on the table way of measuring belief)
* Bloc is not a "Released" subsystem. While its development group report Bloc is stabilizing and encourage more people to start exercising it, Bloc is not on the Pharo 7 Release roadmap. Pharo 6 is current stable release.
* For a long long time, Monticello was Pharo's main source code control system. Responding to general criticism that Smalltalk sometimes lives in its own shoebox and doesn't interface well to "standard" systems, Pharo is spending significant effort on Iceberg to adopt Git as its main version control system (I don't know of any other Smalltalk that has a GUI Git tool). But Iceberg is quite a new subsystem with a Technical Preview release in Pharo 6.0. It was initially slow to draw new users from Monticello as many users were not familiar with git, so bugs remained that were only exposed with broader use. Last December I was trying Iceberg and also experienced crashes with it.
One thing to keep in mind is that Pharo's usually great stability is due to everything being implemented in itself on a garbage collected virtual machine, i.e. memory-violation errors eliminated. Iceberg makes use of the "libgit" external C library via FFI. While this aligns with Pharo's policy of not reinventing the wheel (another oft criticism of Smalltalk) but does allow memory errors that normally could never occur. So the Iceberg subsystem is not a good benchmark to judge the stability of the rest of Pharo.
btw, Lately I've found Iceberg stability quite improved and I started using it daily. Also, based on constructive feedback an improved GUI is planned.
* Around December there was also bug in the new Garbage Compactor related to the conversion of the VM from 32-bit to 64-bit. This is a complex system that took a while to identify, diagnose and correct.
Unfortunately I think you landed in a perfect storm. If the presenter was trying to show off the latest features I guess you got caught up on the bleeding edge of development. Part of the problem here is Pharo bleeding edge is usually quite stable (I use it daily), but we of the Pharo choir better placed to work around any hiccups in order to push Pharo forward. But these should not be exposed to newcomers and you don't have time to deal with them in a classroom setting. I'm sorry this damaged your impression of Pharo, but please understand how your broad statements damage Pharo in turn.