Pharo 6.0 Released
pharo.org
pharo.org
[1] http://gtoolkit.org [2] https://github.com/studio/studio
So when I say that I picked Glamor I mean that my plan is to extend the Spotter and the Inspector to be able to navigate and visualize the internal data structures inside my application.
Does that answer your question?
See also this thesis on moldable tools: http://scg.unibe.ch/archive/phd/chis-phd.pdf
Unfortunately, the announcement is a bit terse. Does anyone have any links or more detailed information on these items?
- A new code changes management system named Epicea for easier reviewing and recovering of your code easily
How does it differ from the old system?
- Integrated support for Git through an easy-to-use tool for repositories and commits management named Iceberg (as a preview for Pharo 6, it will be the default in Pharo 7)
Documentation? Screenshots? Any more information so I (we) can get an idea of how it compares to Git integration in other tools like VisualStudio Code?
Epicea and Iceberg seem to cover roughly the same ground. What are the relative advantages and disadvantages? When would you pick one tool over the other?
- The PharoVM is now part of OpenSmalltalk initiative
What's the OpenSmalltalk initiative?
- Introduction of object immutability, alternative bytecode sets and block closures independent of outer context
Very interesting. Is there documentation on any of this? How do you use it? Why was this added? Can you point to some projects that use any of this?
- Pharo is faster
How much faster? And, more interestingly, how did you achieve it?
- What's the OpenSmalltalk initiative?
Pharo used a fork of the CogVM [1] for some time which has been moved to GitHub and is now called OpenSmalltalkVM [2]. For Pharo 6.0, the team has merged their changes back into the OSVM repository.
Epicea is something dealing with code changes even if you are not using git. Instead of .changes files. You can see what you changed in a given session.
FullBlockClosure: A FullBlockClosure is a closure that can be independent of any outerContext if desired. It has its own method (currently reusing the startpc inst var) and its own receiver. outerContext can be either a MethodContext/Context or nil.
Alternative bytecode sets is paving the way for the new VM developments, which will really make the VM super fast.
How much faster is Pharo6? On the VM side, depends. But 30% or 200% depending on what one looks at. Definitely speedy. On the image side, feeling is much improved because instead of scrolling through slow lists, FastTable is underneath a lot of things and that is simply much much faster (especially when inspecting super long collections, like thousands and thousands of entries).
It's a bit of a common point of frustration for me, because I've had the same problem with Squeak, Dolphin, and several other flavors of Smalltalk that I've tried. Because of this, the only version of Smalltalk that I've actually been able to work on has been GNU Smalltalk in a terminal.
This is disappointing, because I really want to play with it more. Can anyone recommend a modern version of Smalltalk with a GUI that has HiDPI support?
If you don't mean actually unusable (e.g. artifacts, too tiny, etc) then it sounds like a really superficial issue...
It's a volunteer non profit project. If people haven't done, clearly the don't have the time to do it over other things.
Tsk, tsk-ing them for not having fixed everybodys and anybodys pet peeves is beyond meaningless.
It's not like random non-Pharo using programmers are entitled to anything. Or like anybody forces them to use the platform.
If they don't like it, it's rather "don't let the door hit you on your way out".
If, otoh, they want to use Pharo they can. If they find that future important, they can help build it.
But I don't think entitled criticism helps or is welcome in any community project.
It's easy to point at anything and ask them why they haven't done it yet, and that it's this "mindset" that keeps them small.
As if if they had a different mindset they'd also have magical resources.
https://www.reddit.com/r/programming/comments/6fmzwn/pharo_6...
The upshot seems to be that they're working on it, slowly.
All tools can use it but are not part of the official Pharo6 release. This does not mean that Bloc doesn't work.
https://github.com/pharo-graphics/Bloc
On top of Bloc is Brick, with the widgets.
This project is meant to have Pharo support whatever surface and resolution one is throwing at it. There are commercial projects underway using it for tabletop style UIs.
http://www.slideshare.net/esug/bloc-a-graphical-user-interfa...
To try this out: https://github.com/pharo-graphics/Tutorials
So, all of Moz2D style stuff is working in Bloc
I should do that for my Surface Pro 4. But that would be a specific build.
Would be interesting to know why this platform is not more widespread.
Eclipse was born from Visual Age for Smalltalk and Hotspot was taken from StrongTalk project.
Java, .NET and Swift Playgrounds are now the closer we have to Smalltalk in regards to mainstream adoption.
Being image based also did not help, even though there were ways to exchange code among teams, including distributed source control tooling.
...closer yes. As in an erzatz of coffee is closer to coffee than say, beer.
Enterprise features are getting added. With UnifiedFFI, it now easier to bind to C libraries, so, expect more.
I am looking into providing Kerberos support etc through it. Stay tuned.
Right. I remember reading somewhere, maybe on Martin Fowler's site, that he or some other people worked on a large Chrysler project that used Smalltalk.
>Eclipse was born from Visual Age for Smalltalk
Via Visual Age for Java, IIRC. Had tried it out a bit, was slow, IIRC, maybe needed more RAM than I had then on my company PC.
The language has been around for decades and it's always been marginal, for multiple reasons (license, cost and the whole image deployment model which, even today, makes it problematic to do even the simplest things, e.g. deploy a simple Smalltalk web app to the cloud).
In 90's Portugal it was common as enterprise language used by the likes of IBM and friends, also used to teach OO in many universities (alongside C++), before Java was born.
Yes, it would, and also interesting to know how much work is available using Smalltalk / Pharo these days. I looked at the success page, there seem to be some slick apps there (on a brief look).
Maybe they are flying under the radar.
Yes, there are some slick apps being done, with no need for a legion to deliver a sizeable piece of functionality.
Pharo forked from Squeak because it wanted to be a vehicle to deliver business value for real and not just be a research ground. Version 6 is a significant milestone in that direction. Iceberg (Git tool) was funded by the consortium. http://consortium.pharo.org/ Check the industrial members, this is no small fish.
I guess that we are on this trajectory: https://www.joelonsoftware.com/2001/07/21/good-software-take...
Thanks for the informative answer.
Good point about the trajectory.
Where does Pharo shine, at least in the eyes of those who use it?
I had briefly considered it to use it as a cross-platform desktop RAD platform, but its integration story was pretty weak. Things like connecting to PostgreSQL could be done, but only using an older protocol. Serialization formats like ProtoBuf were not available. The GUI framework was not easy to parse (for me), though there were inklings of work on easy-to use, high-level GUI builders.
I left with an impression that it was for people smarter than me, though I'd still like to learn it!
BTW, I had heard that software for seaport dock management used to be dominated by SmallTalk. Not how things are now.
(Edited to fix the worst of the grammar errors)
e.g. Roassal + GTInspector + PetitParser can do a ton. Coupled with Zinc (HTTP Client + Server) and XMLPullParser, data can be brought in easily.
One key thing here is that there is much less accidental complexity that on other platforms when coding.
The continuum between coding/running/debugging/understanding is really sweet. It is more of an experience of making progress in much less time than on other platforms.
I have been coding on quite a number of other stacks but Pharo is really giving more to my soul, so to speak.
Also, the whole thing is MIT and no big corp owns any of it. So, we shape our own future. The community is smaller but really inspiring and it all made me a much better dev.
And it makes my thinking cleaner. Not a small feat.
I accept that you enjoy using Pharo. What is the output of that time enjoyably spent? What product does Pharo have the largest relative advantage in creating?
So is is good for doing some web application dealing with lots of devices.
Have a Jira client for doing lots of Jira automation using the REST API, along with a bunch of goodies etc. Pharo was quite practical to deal with that.
Am finishing up an XMPP client, and writing callbacks for dealing with XEPs etc is a dream in a live environment like Pharo. Expect more there soon.
Compared to other things I did with say Java or .NET, they all take longer and are more convoluted. I used to be a Java full time dev/tech lead/architect for years.
I am still doing Hadoop stuff but it all feels like there is always an annoying ton of accidental complexity in the Java/.Net camp.
Check http://pharo.org/success/Quuve for a rationale about picking Pharo instead of Python.
And UnifiedFFI: https://www.youtube.com/watch?v=418eEvCiepU
UnifiedFFI sources:
https://github.com/pharo-project/pharo-vm/blob/e0ce2d9d78c3c...
https://github.com/pharo-project/pharo-vm/tree/48e59f7238853...
This is, of course, quite OT, but what is it with the trend towards dark color schemes? I find that it makes text significantly harder to read. Especially if you sit in a not-very-bright-room.
Other than that, the release notes sound cool. It is good to see that the project is making progress. Git integration sounds very interesting. Source code management was one of the things I found rather confusing as a Smalltalk newbie.
How does the joke go? -- "Hours of planning can be saved by just a few weeks of coding" or something along those lines. I find a garish eyestrain-inducing theme to incite me to spend more time planning and less time coding.
This is no longer the case with displays, so we can choose ourselves, and light on dark is much easier on my eyes (at least it feels like that).
and I think that's why in large classrooms they are still the favourite medium
But it is astounding easier to read black on white in bright settings, like as a passenger in a car. So sometimes I'll use it (black on white) for readability.
Nostalgia for CRT terminals?
Personally, I find that if I'm looking at a screen for many hours at a time a darker theme helps prevent eye strain, or at least prolong the inevitable. YMMV, of course.
I've been told this can be caused by astigmatism (which I have), but I haven't spent much time researching it. When I come across a web site with dark background (thankfully quite rare) I use a Chrome plugin that can fix it, and it works reasonably well in most cases.
BTW, there is the Sublimish Theme that didn't made the release but will be in Pharo 7.
The general take for the next release is to make all of the skinning easier for the system. Like how easy WinAmp was to skin.
IIRC, on emissive displays (e.g., pretty much every computer display), light on dark produces more eyestrain with extended use, especially in dark environments.
This is less pronounced with reflective media like paper (at least, in most practical scenarios; you could contrive lighting scenarios with a similar problems, but they don't usually occur accidentally.)
OTOH, Pharo has a very good light theme, even if it's not the default.
Same here. Something about high-contrast schemes irritates my eyes; and I have trouble reading low-contrast text on dark backgrounds, so I've been using black-on-#FFFFDD since I noticed it on the Go Playground.
Smalltalk.
Has this issue been solved in 6.0? I'd be happy to give it another go.
[1] https://stackoverflow.com/questions/38788468/pharo-keybindin...
Now, why is it "better"? It is not because "trust me". It is because it makes code much more malleable. You need to let go of coding in files and of the need to scroll through code page after page. One needs to think of the code as a repository. Well the kind of thing tools like Jetbrains provides. When they do index your code, they basically build a Smalltalk image structure without the liveliness of it. So, the thing that makes me find it better is that when I got a bug (not a "crash"), a debugger pops out and I can inspect all of the state, maybe change code here and there (because I realized how stupid I was to code things that way 10 minutes ago), go back a frame in my debugger and continue the run. Without having had to stop anything, or restart the program. If I save my image before a run, I can always open it back like I would with a VMWare snapshot. That is quite great. After a while it reduces the time to code by a significant factor. Agreed it is another way to code. And ideed you'll know when you will have tried it. But it is hard to do all of that by oneself without seein g other Smalltalkers coding for real.
Now, for the files metaphor, I plan to have a fuse module at one point so that one can get into the image and see the contents as files, like one is looking into /proc or /dev etc. Then one can use Vim or whatever (I am a heavy tmux and vim user, so I feel your pain when it comes to the keybindings needs - but the current pain is worth the rewards). It took me a couple years to become proficient with Pharo and there is more to discover in that system for years to come. Because Pharo is a system and not a build system. You need to understand the system in which your code lives. This is very different from creating a piece of code from A to Z, compiling it and running it somewhat standalone or within, say, Tomcat or some similar device.
Also you shouldn't lose your work in Pharo because of the "Recover Lost Changes" tool that exists and allows one to grab the code back. Epicea brings this to a whole new level.
Hope this makes some of the possibilities a tad clearer.
And, I'll add, it's what gives it a feeling of being truly brittle when the whole thing comes crashing down. It's not just your program that dies, but the whole desktop. I'm glad to hear they found and fixed that bug, it was seriously detrimental.
I do not feel stuck but have a few tricks: https://github.com/Pharophile/ExternalTools
(and for the save thing: https://github.com/Pharophile/HOImageSaver)
I like being able to add new features to my own dev environment the way I want. Like with https://github.com/Pharophile/TilingWindowManager
Try that with other tooling. A plugin or two, yeah, but hacking your own development environment from the inside out? That's really awesome I say.
Having qualified my mindset, one thing I'd love to see is some way of "ssh-ing" into an image at least for being able to kick-off or inspect objects in a VM.
Perhaps in a related feature, having some kind of plan9/9p file server and/or client would provide a method to expose or consume data through a "standard" method.
Or maybe I'm mixing too many metaphors... at any rate, glad to see some activity in the Smalltalk/Pharo world here.
And... how do you deploy a Pharo-based desktop application? Does it need the image? Can you compile it?
Deploying is easy, it is as any executable with some dlls and resources.
I deploy web apps on Azure with Windows 2012 R2 server and run them with NSSM so that they are nice services.
Otherwise, I run them on Linux with monit or supervisord.
As for scaling, well, you can run a bunch of running VMs with a load balancer in front.
An option is to use GsDevToolkit because Gemstone can run Pharo code and scale quite far.
A lot of apps do not need the scaling actually. So, 4 or 5 VM instances can really go a long way.
Works smoother because of usage of FastTable which replaces the old lists of morphs that got overkill. Actually, Pharo was fast for dealing with that massive amount of morphs. It felt slow because of the amount of stuff it did. But not intrisically slow.
Kudos to all the team
I've been unable to really decipher what the MOOC is despite reading the website and watching the videos I could find.
I keep wishing it were a YouTube channel...
"do" means register for the course ? it seems they did not rerun the course (sadly).
about the content, it's very similar to other PL mooc, you get the Pharo env, first week is basic hands on[1], then you solve problems of increasing complexity (but here it's no CS level problems, more IT/CRUD).
[1] the fun part is that in Pharo, first exercises are about modifying the world you live in. You also learn the versionning system to save/load your work.