Hacker News new | past | comments | ask | show | jobs | submit login
Pharo 6.0 Released (pharo.org)
118 points by ch_123 on June 7, 2017 | hide | past | favorite | 81 comments



Great to see Pharo on HN. I picked Pharo and Glamor [1] for a new IDE that I'm working on [2] and it's a real pleasure to work with so far. I didn't find anything else in the same league.

[1] http://gtoolkit.org [2] https://github.com/studio/studio


If you don't mind, could you explain how Pharo and Glamor fit together?


I'm not sure how "official" this answer is but to me Glamor is a set of extensible ("moldable") development tools that are included in the Pharo distribution: Spotter (object search with better UI than google), Inspector (click through object graphs with domain-specific visualizations), and a few others like the debugger.

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


I also would like know this. I find the Pharo ecosystem challenging to understate as the documentations aren't as rich as other platforms with more volunteers. Or maybe it's because of the more exploratory programming/learning style of SmallTalk and it'd just be easier if I just poked around the image to learn rather than reading the docs?


Very nice. Congratulations!

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?


- - The PharoVM is now part of OpenSmalltalk initiative

- 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.

[1] http://www.mirandabanda.org/cogblog/about-cog/

[2] https://github.com/OpenSmalltalk/opensmalltalk-vm


Iceberg: code management with Git, so lots of actions can directly happen from inside Pharo. There can be other backends than Git in the design. Git is the only backend atm.

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).


I tried Pharo awhile ago, but last I checked the HiDPI support was still not there, and the menu was just unusable on my QHD+ screen.

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?


There is Bloc, which is a fully vector based engine that is resolution independent (actually there is Sparta under this which is a recast of Athens).

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

https://wiki.mozilla.org/Platform/GFX/Moz2D


Perhaps it's a simple matter of nobody having raised this issue so far? I think this is their issue tracker:

https://pharo.fogbugz.com/


I said almost the same thing on reddit here:

https://www.reddit.com/r/programming/comments/6fmzwn/pharo_6...

The upshot seems to be that they're working on it, slowly.


>I tried Pharo awhile ago, but last I checked the HiDPI support was still not there, and the menu was just unusable on my QHD+ screen.

If you don't mean actually unusable (e.g. artifacts, too tiny, etc) then it sounds like a really superficial issue...


That attitude is more-or-less why Smalltalk is in the boat it's in. Lots of mindshare with few actual users because everybody can name a superficial issue that keeps them from using it.


If only the Pharo community knew that, they would have jumped to fix this issue! Because clearly they have all the time and resources in the world, and they only keep this issue open out of spite...

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.


I hope you feel better after that little outburst. If this is your reaction to mild criticism of obvious shortcomings, it puts out quite a welcome mat.


I'm not the "Pharo community", just someone trying out Pharo.

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.


[flagged]


It's the entitled ones who are the "arseholes", and project after project has commented publicly about how toxic they are for the actual community.

I'm just restating the obvious.


There were more pressing matters to solve. A lot of Pharo devs are using Macbook Pros with retina display, so they have an itch to scratch. But the issue lies on the VM side for now, so that limits the numbers of contributors + PharoVM reunited on the OpenSmalltalk initiative and that is no walk in the park.


Another easy way to solve that for one's HiDPI support would be to hack the VM a bit to display things properly.

I should do that for my Surface Pro 4. But that would be a specific build.


Here[0]'s an interesting section on large scale users. Seems to have been used in production for some ATMs in Russia.

Would be interesting to know why this platform is not more widespread.

[0] http://pharo.org/success


Smalltalk's thunder in the enterprise was killed when Java started to gain adoption.

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.


Iceberg brings full Git support to Pharo.

...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.


>Smalltalk's thunder in the enterprise was killed when Java started to gain adoption.

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.


There was really never any Smalltalk thunder.

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).


Depends on where on the world one were.

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.


>Would be interesting to know why this platform is not more widespread.

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).


As an employee I do not know. But as an entrepreneur or self employed developer providing solutions, there are quite a few successful people.

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...


I was asking about both, for employees as well as self employed.

Thanks for the informative answer.

Good point about the trajectory.


What kinds of projects is this best suited for? Cross-platform GUIs? Web servers? Data processing and numerical computing?

Where does Pharo shine, at least in the eyes of those who use it?


I want to know this too! When I poked around before, I got the impression that it would be good for writing apps that need sophisticated logic, as the language and the platform is very flexible. I think I came across several Pharo tools for source code analysis and using them also seemed to leverage SmallTalk's flexibility and exploratory capabilities.

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)


It shines when one puts the tools together.

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.


Tell me about the things it's good at making. If those aren't a match, I don't care about any of the points above!

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?


I did this one a while ago. http://pharo.org/success/CableExpertise

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.


Yes, I'm interested in knowing that too. Smalltalk was used a lot for GUIs originally, I've read. So maybe GUIs are one of the target areas now too.



Many thanks for these links. They help. Documentation as a way to attract new users and educate existing ones, doesn't seem to be part of the culture with Pharo.


> The Dark Theme was improved and set as default color theme of Pharo

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.


I'm the opposite, and when rationalizing it to myself I'm thinking that our traditional black-on-white writing has more to do with the fact that it's easier to stain light paper with dark ink/coal/etc than dark paper and light writing.

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).


I've always found that black boards were more readable than black ink on white paper

and I think that's why in large classrooms they are still the favourite medium


If find it the other way around. Dark backgrounds makes white text easier to read. And yes, Smalltalk source-code management is not intuitive (i.e., not like the others like git, Hg, svn) though it works well enough.


I'm afraid you might be in the minority. A strong majority of developers I know (and even those whose desks I just walk past) seem to be using dark themes in their editors/IDE's.

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.


The key word here is “personally”. Personally, I can't read anything with dark background at all. It only takes a few seconds before everything starts swirling in front of my eyes, and when looking away from the screen everything around me starts to look weird. It takes several seconds for me to return to normal.

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.


Brighter themes are harsher on the eyes, whereas darker themes are not. At least that's why I prefer them.


It might sound a little odd, but I slightly prefer programming in a harsh-on-the-eyes environment from time to time. I think it keeps one out of one's "comfort zone" and thus more focused on immediate problem-solving.

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.


Could be interesting to make an ADHD theme...


I think I might have cracked that one... I configured my .emacs to randomly choose from a selection of 20 or so monospace fonts (filtered by local-machine availability) and ~35 different color themes each time it starts up.


> This is, of course, quite OT, but what is it with the trend towards dark color schemes?

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.


Got floaters. Dark is better because of less shadows. I am pushing the dark theme thing in Pharo for that very reason.

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.


>...dark color schemes? I find that it makes text significantly harder to read.

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.


I prefer the dark themes myself.

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.


>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.

Nostalgia for CRT terminals?


Great, I've been waiting for this release that also makes Pharo a member of the OpenSmalltalk initiative. I wonder when/if the Pharo MOOC will be updated for 6.0.


This is on behalf of the other knights of the square brackets, and anal folks like me. The language name is spelled with a lower case T, like this:

Smalltalk.


Yeah.


I was excited to dig into Smalltalk some time ago, and downloaded Pharo 5. The reason I quit after a couple of minutes is that there was no support for standard Unix keybindings (i.e., C-a beginning-of-line), and no way to configure Pharo to understand them. [1]

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...


What made you excited to learn Smalltalk? Seems odd that you quit after a few minutes. If keybindings are that important to you, perhaps try gnu Smalltalk.


I don't care much about keybindings, but I had a similar experience to GP. I used Pharo for a project and hated it. Not so much because it's "bad" per se, but the whole thing is running in a VM process in its own graphical environment, it's like a walled-garden kind of experience. I don't see the point in developing with it unless you are developing for it, so you have to buy into it completely or not at all. Whenever you ask Pharo people why it's better, the answer is always just, "Oh it's better.. trust me. I can't explain but it's about the image and .. well you'll know when you've tried it." You know what? I tried it. And it sucks. Pharo 5 crashed many times on me making me lose my work, so I got into the habit of saving the entire image every 5 seconds. Got tired of that pretty quickly.


Pharo 5 VM had a bug with a double free in the FreeType integration. So, using truetype fonts instead of the basic raster font made the VM crash. It took a while to find out why this double free occured. The crash was not from Pharo bytecode or the VM core, but from a stupid double free crash.

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.


Oh my problem is not at all with the idea of coding in an image, being able to dynamically change functions, etc. In fact I work that way all the time using emacs and Python. My problem is just being stuck with this annoying graphical environment that wraps it all.

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.


Well, I am coding all day long in that thing and it is stable.

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.


Thanks for the information... I've had an interest in Smalltalk for a long time, but never really followed up b/c of the radical change in mindset (I've been a "CLI guy" for my entire career).

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.


Ah, and about the "for it", you may want to have a look at scale, which lets you play with Pharo on the CLI.

https://github.com/guillep/Scale


Oh hello. That's the first I've seen it, basically what I was asking for. Thanks for the link!


Feel free to add new features! PRs welcome.


How do you deploy a Pharo-based web application? Does it need the image? And how do you scale?

And... how do you deploy a Pharo-based desktop application? Does it need the image? Can you compile it?


There was an older blog post about deploying Seaside (a SmallTalk web app framework) on AWS. It boiled down to stripping the image of unused parts (tree shaking), including the GUI and copying the images over to the server behind a load balancer. Sorry for the lack of details, I can't find that particular article. This looks like it might answer the questions: https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBo...


The image is the compiled bytecode. There is no source in there. The source code is in the PharoXX.sources files and .changes files.

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.


The simplest thing is to prepare your image and copy it where you want it to run. It's like sculpting your software, actually


I tried it out, and it definitely feels snappier than Pharo 5. They did a great job! The thing that bugs me the most, which has not changed in v6, is that there's some sort of active UI polling going on, so it sucks like 5% of your CPU just sitting there doing nothing. That's not good for battery life. It would be nice to know if changing that is in their plans for some future release.


Here is the presentation of Pharo 6.0 at Pharo Days 2017 with screenshots and more clues.

https://www.slideshare.net/pharoproject/pharo-6


Great news! UI looks better and works smoother or this is just my opinion?


UI looks indeed better. Uses FreeType instead of strike font. One can tune the freetype glyph contrast in the settings as well. And use any freetype font, like Hack (which is what I do use).

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.


What's up with that compression-pixelated lighthouse? Looks odd and seems to split up the content on the site for no reason.


I did the Pharo MOOC. For such a different culture it was almost 100% pleasure.

Kudos to all the team


How do you "do" it?

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...


Are we talking about this mooc https://www.fun-mooc.fr/courses/inria/41010/session01/about ?

"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.


Too bad. I was aware of it when they were calling for registration but the time didn't suit me and I just assumed it would be available permanently in some way e.g. online videos. My loss!


I too assumed it would be that way. Many MOOCs did this.. If I hear anything about it I'll ping you.


Hey @agumonkey, small world.


Hey back phil


Is there no documentation of new features and changes?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: