Where does the Pharo runtime run? To which platforms can I bring its solutions? are these standalone binaries or can I create libraries or code which play well with other languages and systems?
Every time I look at a programming language, and at the HN it is every second day, I think about what kind of problems can it solve, and for what kind of platforms these compile/run their runtimes.. and surprisingly not many programming languages inform properly about the most basic feature, and prefer to go deeper into their.
Pharo runs in a VM that's compiled to C and runs as a stand-alone native application on Linux, Mac, Windows. You can also build from source but most people don't and there are some rough edges. There are plenty of libraries and mechanisms for connecting to the rest of the world e.g. subprocesses, sockets, FFI, and libraries built on those.
Development is entirely via the most integrated GUI you've ever experienced. It runs on MacOS, Windows, and Linux.
For deployment, you can run it headless.
You can also deploy as Javascript for Node/Browsers via a tool called PharoJS (http://pharojs.org - full disclosure, I'm one of the principals of PharoJS), but it's a work in progress (with a Slack workspace to support it).
GNU Smalltalk can deploy to a standard executable, so you could do most development in Pharo, and then switch to GNU Smalltalk, but you'd lose the fabulous IDE.
I have not looked at Pharo, but the Lisp development environment on my Symbolics computers is amazingly integrated, so this is a very high bar to surpass if true.
Running Pharo (or Cincom Smalltalk or Squeak Smalltalk) on an OS like Windows is similar in many ways to an old Symbolics machine, but Symbolics didn't need to sit on top of an OS, but was lisp all the way down. This existed in the past with Smalltalk as well at Xerox Park where it introduced the GUI and Mouse. I forget the machine's name, but someone on HN rebuilt one recently. The hardware was expensive at the time much like Lisp machines. The best lisp comparison to Smalltalk on Windows is likely SBCL + Emacs Slime, but even that is an inadequate comparison as Emacs Slime is mostly just a super powerful text editor and Pharo is fully graphical. You can run some code to generate a rotating 3D image and recompile any of the methods on the fly and instantaneouly see changes. Even the IDE is fully modifiable and you can change the language to make True = False and break everything. Both SBCL Common Lisp & Pharo use the image concept. So you can save your work and system state in the image.
There are emulators for the old Lisp Machines. The best were Medley (for the old Interlisp-D system from Xerox) and Open Genera from Symbolics. They are philosophical relatively near to Pharo. But Pharo has seen more development in the past decade.
For Common Lisp there are/were many integrated IDEs: Macintosh Common Lisp, Allegro CL, LispWorks, Clozure CL on the Mac, Corman Lisp on Windows upto McCLIM for several CL implementations. A general difference to Pharo is usually that these CL IDEs use mostly native user interfaces. Pharo comes with its own user interface, graphics, window system, display code, event handling, ... Example: Pharo windows on a Mac are not Mac windows. Clozure CL windows on the Mac are Cocoa windows. Similar: most CL systems use native code.
The real commercial Smalltalk machines were underpowered compared to some of the Lisp Machines - for example those from Symbolics - but those were also quite a bit more expensive. It was possible to spend more than $100k for a Symbolics Lisp Machine with accelerated color graphics and HDTV in/out.
The main difference of Pharo with integrated Lisp environments:
1) Pharo uses portable system independent images. Most Lisp systems uses system (OS / architecture) specific images, since code is natively compiled.
2) Pharo code is not native AOT compiled, IIRC. Common Lisp is either source interpreted or AOT compiled - some are even AOT compiled only - with incremental AOT runtime compiler.
3) Pharo uses its own user interface & gui system. Most Common Lisp systems use a native backend for their GUI. Recent exception is Mezzano, which a CL on the metal, which comes with its own GUI.
4) Pharo/Smalltalk usually manages and tracks source code for the user. Most CL IDEs use files and the user works with files and systems of files. CL then more or less tracks the code in these files.
5) Pharo offers to save state in an image between sessions - Lisp systems use that mostly on demand and less as a session state mechanism. LispWorks has some support for sessions.
<It was possible to spend more >than $100k for a Symbolics >Lisp Machine with accelerated >color graphics and HDTV >in/out.
Quantel Harry was the competition.
Link below, is for the 1981 Quantel Paintbox, the existence of which is responsible for the direction of my juvenile mind.
I should love to one day get together with like minded folk and assemble a complete ca. '89 broadcast graphics suite. I'm in advertising (London, independent, founder) and I'm not convinced that I couldn't work out the financial arithmetic favourably. I am persuaded by artist friends of the merit, tempered I expect by the reality of the working interfaces, if they actually used a 80s Quantel - we take instantaneous responsiveness for granted.. Time and place required, but I'm serious enough to have scouted premises and allocated budget.
I digress. Sorry.
I only have read about Pharo in the last couple of weeks, but I am taken by the sophistication of the ambitions and delivery thereof. I say this here, rather thanon a Pharo list, because I am unsure of what skills and specialities are required, but I have a professional itch to scratch, which is estimating the work of supporting a new language to the fullest extent possible, in Visual Studio. If this could be accomplished in under half a man year for a senior developer, I really want to know. (result to be released to community, purpose of exercise purely personal curiosity about what consequent effect is possible)
My impression is that Quantal was more or less about 2d paint and compositing.
The Symbolics Graphics System was more about 3d modeling and animation for TV and games. Paint was also provided - but also in combination with animation.
User lispm is all about some lisp and lisp machines...super knowledgeable on the subject. I like to think he has acheived a general purpose AI on his networked Symbolics machines. All jokes aside he/she has posted some great stuff on here and the lisp subreddit.
Like lispm, I have several working MacIvory machines as well as several native Ivory machines and several working DEC Alphas running OpenGenera. I also have others including TI and Xerox but have not yet restored them.
You can, with a bit of effort, get OpenGenera running on a Linux VM and display on a modern X server. There are a few patches needed due to recent X server changes, or just run an Ubuntu from a dozen years ago on metal.
I looked for any useful documentation for a few minutes and just gave up. I don't want to read a book. I don't want to watch a video. This is not my first programming language, thank you. I just want a "hello world" example to get an idea what I am actually dealing with. How do I run a "hello world" program from the command line? How can I deploy that to another machine that doesn't necessarily have a GUI?
> I just want a "hello world" example to get an idea what I am actually dealing with. How do I run a "hello world" program from the command line?
The trouble is that what you are dealing with is a graphical interactive programming environment. Sure, you can run it from the command line like /bin/perl, but to understand what you are dealing with you have to open it up and try it on its own terms.
If you aren't interested in a novel immersive programming environment then you can safely ignore Pharo too.
>If you aren't interested in a novel immersive programming environment then you can safely ignore Pharo too.
I was curious and so downloaded and ran the default image, and I'm beyond captivated by it, but I have to agree that neither the link nor the homepage do a good job of enticing me to do so, or even hinting and what can I expect.
If I didn't feel like setting up and checking out random projects I stumble upon, I would have never even seen what Pharo is about, given the abundance of marginally different programming languages that pop up on HN.
So yeah, I also think Pharo's best "Hello, World" is just opening it and trying out stuff, but maybe it should try to sell itself, at least a little, for the uninitiated?
> maybe it should try to sell itself, at least a little, for the uninitiated?
Guessing this is a hard problem. People have been working on marketing Smalltalk for almost 50 years now. If there were an easy solution I reckon they'd have found it by now :)
This seems a step worse, though. Neither the release page nor the main Pharo page even mention smalltalk, yet the documentation page talks about it as if it's the same thing (and only seems to point to books and videos, not basic introductions and tutorials). It's really strange for a programming language site to go to so much effort to hide its language.
Yes, I see that the announcement says that the FFI is improved, so I look at the documentation page to see how it is improved, and I see quite a few links, but these are mostly old links to contributed docs, none obviously covering the new release. I guess that the books page linked to documentation page is the one most likely to include anything about the FFI, but the newest book I spot there is 8 months old. Google search for pharo 7.0 FFI turns up the same release announcement and nothing else relevant.
One thing that struck me a bit odd was, that the website makes it look like I have to buy a book or join a (paid?) mooc to get started, because these are the very first sections under "documentation".
I was just looking for a basic examples to get some sense what Pharo is about and what the look and feel are. Without downloading and installing it, I wasn't aware that there is a pretty nice interactive tutorial built in.
Maybe convey better how Pharo is distinct from other languages/environments and how to get going?
Pharo is indeed very easy to get started, but the website makes it appear harder than it actually is.
Oh yeah, absolutely; seeing the MOOC featured so prominently, which I genuinely was in no mood for, I was just about resigned to having to aimlessly click around and run barely functional snippets - and then I open the image, and there's a super friendly beginner ready interactive tutorial!
Pharo might be the first project I've seen whose actual usability an user-friendliness is behind that of their presentation :)
I don't remember the MOOC costing money, but it was in French with English subtitles which is understandable with them being French researchers at INRIA, but it couldn't keep my attention up due to the gap.
The books are all free in PDF form and the lead developer also has another website somewhere where he hosts old Smalltalk textbooks which are largely still relevant.
They certainly could work on conveying this better, but it is open source and likely not a high priority.
For me it was just the initial perception I got. E.g. I only realized that the books were free after you told me. And yes, this is due to me evidently being too lazy doing an additional click. I don't mind paying for books, but not as a first step.
I did download and tried Pharo because I was intrigued by it from another person, if I just were to land on the website from some random link, I likely wouldn't have.
I think there could be some small changes in wording and presentation that would get a long way for people without any prior knowledge of the language. For example if you compare it to Rust (just content, not design wise)
I see what you mean. I think Smalltalk and lisp have always suffered from poor marketing. There have been efforts to change this, but possibly too little too late.
Social proofs could work too. If you can't show me how powerful Pharo is visually, show me a bunch of people (preferably people whose names, or company/employers' names, I would recognize, but that's secondary) telling me how powerful Pharo is.
Pharo does have commandline functionality, but that won't demonstrate its value as a first experience. For an interactive tutorial... open Pharo, then left-click background, Tools > Playground, type & highlight 'ProStef go', right-click & 'do it'.
They do. By saying "there is such functionality, but you should try this instead, because using it from commandline won't tell you why this is interesting". Which isn't directly answering the question, but pointing the asker in a good direction.
But this is about Pharo, which is a Smalltalk environment, which is different from how most programing languages are used. So starting from those kinds of questions is missing the point, when the focus should first be on seeing what makes a Smalltalk environment different.
> Telling `virtualized` that they are missing the point — instead of answering their questions — makes the community seem arrogant.
However, virtualized stated that they gave up after five minutes because they couldn't find a hello world example similar to programming languages they're presumably familiar with, because they didn't want to watch a video or read a book. So explaining that the Smalltalk environment is different, and thus it doesn't make a lot of sense for Pharo's website to advertise with a command line example, is appropriate, since that implementation is GUI-based.
It would be akin to complaining about RStudio's site because someone couldn't quickly find how to run a hello world R script from the command line, when RStudio is about the IDE.
We’ve converged on a computing and programming experience that is largely homogeneous across languages and platforms, and Smalltalk is definitely an alternate timeline tech.
I kind of like these systems because they remind me of when computers were weird and different and had legitimate tradeoffs. People’s expectations of computers were still rooted in a physical model of interacting with the world. Computers were still very much trying to prove that they were relevant to the “real world.”
You create a new image and then start piecing things together from there. GNU Smalltalk is probably what you want if you want to stick to the CLI. That said, it's not exactly a representative example when you want the same program that prints to stdout or something.
I'm curious to know about this aspect of it because my first step after the hello world is usually to figure out how to host the thing.
There's literally a command-line example (although it doesn't print Hello world, but the factorial of 42) on their front page.
That said, Smalltalk isn't something you use from the commandline typically, or only during deployment or for applying external automation. The GUI environment is fairly key.
Are you suggesting that `FileStream stdout` doesn't work, or that using `Stdio stdout` is in some way better, or that `nextPutAll:` will add a newline, or that … ?
Even after you download it, pick Pharo 7, and open it up, the "Explore Pharo" section points you to a page that doesn't work that says it's accurate for version Pharo 5. [0]
I finally found out that the magic invocation was to open up a window by clicking on the background, and navigating to Tools -> Playground, and running `Profstef go.` But they certainly didn't make it easy.
As a beginner, ProStef (Mini tutorial) helped me get familiar with environment. To access that tutorial, it's on the welcome page in the Learn Pharo tab when you first launch the image. Hope that helps!
Not from command line - but this will hopefully get you up and running in the IDE and have an idea what Pharo can do. or To deploy on another machine you simply copy the image file - so they can run from pharo. The image can be run headless (doesnt display GUI) if you need to deploy on a server.
Run PharoLauncher and Load a Pharo image instance.
Once the Pharo Desktop IDE appears type CTRL+O+T to open Transcript - the system log console abnd type CTRL+O+W to open playground - Playground is a window into which you can type. It can be used for any purpose, but is most often used for typing Pharo expressions and equickly executing them.
(There are windows /icon menu entries for these as well)
In playground window type:
Transcript show: 'Hello World'
and press the play 'do it' icon at the top of the playground window to evaluate it
You should now see Hello World appear in the transcript window.
What you just did was send the Transcript objects show method the message 'Hello World'
Lets do a slightly more complex Cut and paste the following code into the Playground window and click the play button. The first part installs the Roassal visualization framework. It only needs to be run once. The second part uses ROassal's Mondrian API which offers facilities to describe and render graphs. Mondrian allows mapping of metric values and properties into visual dimensions, such as shape and colors. Cut and paste the second piece of code into playground and hit play doit icon to evaluate. In the view panel you should see a simple tree class browser of the installed classes in the Pharo image with size of class coloured and scaled to represent number of source code lines in each class. Note lines in speach marks are comments.
> are these standalone binaries or can I create libraries or code which play well with other languages and systems?
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.
Why the downvotes? is there anything wrong in my question? I read the webpage and the answer is nowhere (at least I could not find it), and looking at the docs is not so easy to find this information, it seems that I have to get deep in a chapter of a book or a video in order to find out whether this tool has anything to do with my work, tool or area at all.
Does it compile to other platforms? Binary code, compile to C, to LLVM? Does it compile to other VMs like Java and it is compatible with javascript engines? For me this is a basic aspect of a language.
Like Java, it runs on a VM. This VM works on the mainstream OS.
One of the peculiarity of Pharo (and Smalltalk) is that when you shutdown the system, you can persist the whole system on disk (called "the image"). Next time you open it, you start exactly where you left.
All the development tools are mixed with your code. There is no differences between the coding time and runtime (i.e., you code at runtime). If you are familiar with IRB in Ruby, imagine a GUI running in IRB.
This means that it is hard to see the limit between your code and Pharo's code. Pharo 7 seems to bring a bootstrap process where you can build images from scratch. This is an interesting evolution that will vastly improve the development/reproducability/deployment story.
Please don't complain about downvotes, especially not within the first 23 minutes. It's common to receive one random downvote and a couple more piling on, but given a few hours a decent comment will be back in the black.
For what it's worth I think these are decent questions to ask, even if others think they're worthy of a downvote.
As far as I understand it: it doesn't necessarily compile in that sense. You are constructing an 'image', which is basically a living environment that your program runs in, and maybe it corresponds somewhat to a VM. But you're not really treating the code that the VM runs as separate to the VM itself.
In some sense I think you might map it to something like a Lisp machine, where you can interact with a running program and its state through a REPL.
Someone more knowledgeable might be able to elaborate on that (or correct the misunderstandings), but it felt worth offering something other than a straight up dismissal of your question.
Smalltalk system consists of a VirtualMachine and an image. An image is just some Smalltalk code compiled into a form suitable for VM to read it into memory. The initial image contains all the standard classes of Smalltalk plus the GUI and various tools. When you add a method to some class inside the GUI, it gets compiled and added to the image held by the VM in memory. Later, you can dump the modified image to disk, producing a new initial image you can later use.
This is indeed similar to Common Lisp and Emacs.
Back to the original question: the VM runs on Windows/Mac/Linux and on some IoT devices. The code is compiled to bytecode which can then be JIT compiled further on some architectures/OSes. The compiler and the whole infrastructure is exposed and available on runtime.
Pharo has classes for easy FFI to C and for bundling native libraries. I don't know if it's possible to call back from C to Pharo, but I assume yes (many libraries require this). There is no FFI or other integration with any other language (at least as a built-in, there are RPC interfaces for some langs as add-on packages).
As for "standalone binaries" - almost, as you need to bundle the VM with the image; there are some helper scripts for bundling and then launching images.
The most obvious use case is GUI programming, there's also old-school Web programming with Seaside, data crunching and visualization with Roassal. Other than these killer-apps, Pharo is just as capable as any other high-level language, although with a much smaller selection of libraries available.
Some/many Common Lisp implementations. But there are a bunch of Common Lisp implementations which are not image-based.
Another difference might be that most image-based Common Lisp implementations don't use portable byte-code. Some are using byte-code engines, but those are usually not portable across operating systems and/or machine architectures.
You can definitely do GUI programming as the IDE itself is in Smalltalk, but I wouldn't call it super straightforward like using a GUI designer in Visual Studio. I've tried before and got lost in Bloc & Specc?
To be honest, I stopped playing with Pharo around the time when Spec was being designed and beta-tested - I forgot most of it, but I hazily recall that it was a bit too magical for my taste. I hope it got better since then, but I'd have to check.
But, about the GUI, I was thinking about Morphic. It's basically a GUI designer on its own: you can create widgets by instantiating their objects in Playground. It doesn't matter what widget it is: you can create a button or a list item or a textarea on their own. You can then edit them with halo actions or in the inspector until they look like you want, then add them to container widgets, then finally put them in a window. It's bottom-up programming for GUIs! You need to manually track the changes you make via inspector (ie. to copy them to playground), but if you do, you can copy the whole playground into a method and done, you've just designed a GUI app! You later replace some Widgets with their subclasses written by you to handle events and you're done.
Unfortunately, no, I don't recall anything like this. Executing something like `b := ButtonMorph new openInHand` in the playground would be a start - you can then set click action and caption on `b` and changes should be reflected immediately in the world. Take a look at Morph subclasses and try instantiating ones that seem interesting. Or Alt-Shift-click any widget on the screen to invoke its halo - it will display its class name, and also there's a "duplicate" button in the halo. It's quite discoverable if you put in the effort, although yeah, I'd kill for a good summary and overview of all the various widget kinds and ways of composing them...
Sounds incredible! Git integration and related code management changes are especially nice, 64-bit by default is great and support for binary packages is also important. New, extensible code browser (Calypso) also sounds impressive, but I'll have to see it in action first.
Pharo is an incredibly productive environment. Fully inspectable everything (on the language level, but also on GUI level - you can inspect all kinds of widgets interactively) and the Debugger where you can define your logic as needed make for incredible programming experience. Plus, it's Smalltalk, which is a beautiful language in its own right.
With this release, it looks like Pharo may finally become more than just a toy. Looking forward to it!
GToolkit is also an exciting new development that's happening in parallel with the mainline Pharo. This is a reimagined programming workflow for Smalltalk with new UIs for coding, debugging, documenting, example browsing, testing, etc.
Likely the best bits of this environment will be cherry-picked into future Pharo releases, but meanwhile it is available here at https://gtoolkit.com/ and I for one am building an application on it.
Are there any screencasts or similar videos out there? Looks promising but it probably "clicks" more if you see it in action with a more complete example.
I'd recommend downloading and starting it. It opens into an interactive "notebook-like" tutorial. The system is very discoverable. Has a markdown-like syntax where you can embed Smalltalk objects and code examples and interact with them directly in the page.
In fact, Pharo pretty much can do everything you asked for. It is just amazing to learn a lot of CS concepts. Just so know, Pharo is a great tool to teach. I am a student and this is how I came across Pharo about a few years back.
I was going to say that it sounds a little like that Smalltalk IDE Squeak, and then it dawned upon me that this is actually a Smalltalk dialect too. :D
And a third option that is much leaner and maybe less overwhelming especially if you are interested in actually learning Smalltalk itself to begin with:
I lol'd when the quote, "Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback.", is accompanied with a relatively chaotic artwork of the development environment.
Anyways, the dedication of the team is really remarkable. It looks like a really useful learning/teaching tool for OOP. I'll try and hopefully beat my prejudice.
I need to caution against using a Smalltalk dialect like Pharo to teach OOP.
The essential problem is that Smalltalk does OOP "right" and what one sees called OOP in the broader community generally does not have that same ideological purity. In addition Smalltalks are a deeply different vision of programming. I don't think I've ever shown a programmer a Smalltalk and had them go "Oh yeah this all makes sense." I have to preface it...
"This is a different vision of programming than you are used to, go ahead and run the executable."
"Um, it opened a desktop?"
"Yeah. So this is the program you are writing."
"What is?"
"This blank canvas."
"Oh, this is a text editor?"
"No, like, the program is running live right now."
"Well can I shut it down and edit it?"
"You edit it while it's still running. Here, go ahead and right click something..."
There's invariably some form of disbelief: surely we wouldn't have made this whole programming thing hard for no reason, so surely this approach to "everything is alive and you are mutating the ecosystem" is impossible for the simple reason that it is not ubiquitous.
For someone who's familiar with the "IDE" shown in the artwork, I was able to quickly parse the different components and it conveyed a vague sense of excitement :).
Indeed. It harks back to the "holy shit, look at all the stuff you can do with our tool!" marketing of the 80s and 90s.
Microsoft used to market advanced versions of their BASIC -- such as QuickBASIC for DOS -- by having it open several windows on the screen and draw or animate something different in each. A similar program shipped as a demo for Microsoft's AmigaBASIC.
In any case, I'm not one to judge a programming system by its artwork. I hope people don't get discouraged by it and not try it out, It's a phenomenal system for translating thoughts to programs.
When I see "pure" I think "side-effect free" but I sure do not think that is their intention in using that term of art here. I am pretty sure they mean "pure object-oriented" to mean "impure language where everything is an object".
"Everything's an object" is object oriented programming done right and I can see why Ruby and other languages used those ideas from Smalltalk. I couldn't understand the fascination with the integrated environments though. It was my biggest stumbling block. Is there a pathway to use Pharo with my traditional tools?
>I couldn't understand the fascination with the integrated environments though.
The only thing I can recommend it watching some Alan Kay videos or Pharo demos.
Windows and Linux UI conditioned everyone to think of UI as a crutch for incompetent users, rather than a tool useful in its own right. This cannot be undone in a single reply, no matter how elaborate it will be.
Traditional tools are definitely more polished at the moment, but they are exactly that - traditional, shaped by historic accidents, rather than design. Software development is currently running on a set of highly refined steam engines.
For example, what are the chances that a simulation of a teletype is the best interface for interacting with an operating system? What are the chances that the best conceptual model for a unit of information is manila folder or a phone book ("files", "directories").
Also, IDE came to mean "bloated monolith for editing and compiling code". But it should really mean that application interface is the development tool. Tools that are integrated into OS and applications.
Gtoolkit [1] is a cutting-edge example of what's possible. I say "cutting edge" because it relies upon a dev version of Bloc, which is the new graphics system being developed for future versions of Pharo.
Any sluggishness you experience with Gtoolkit, by the way, is because Bloc is being hosted in Morphic (the current graphics system) temporarily.
There is a ProfStef object that you can send a message to (can't remember the message, maybe "go") which runs through a decent tutorial. After that I'd download one of the books and start going through that. I'm only a novice (have read maybe 1/2 of a book and played around in the IDE a bit). Pharo is really cool, but my programming needs are scientific in nature where I need something closer to Julia where there is a lot of builtin support for numerical work. Someone did write a numerical methods book in Pharo which was neat, but it is still lacking the libraries I need.
What the Smalltalk and apparently now the Pharo people don't seem to understand is that the entire OS is the IDE, "the image".
My OS and all of its rules, tools and configuration, the UNIX philosophy, the POSIX standard, all of its history and convention: _that_ is my dev environment and it's as LIVE as anything can be.
Not some one-off unicorn IDE - no matter how awesome it is, sorry guys.
My entire toolchain in all of its diversity is one big living ecosystem. That is not, as you eloquently hinted at, a bunch of refined steam engines. It is maglev-level awesomeness. Some pointy-clicky IDE where you can inspect objects with trivial properties is not impressive. It was in the 90s, but now now. Ironically Pharo itself, to me, evokes the admittedly beautiful image of a bunch of refined steam engines. A beautiful thing of the past. Impressive, but obsolete - not unlike France itself.
You have to interact with dozens of systems for even the simplest applications now. Databases, HTTP APIs, knowledge systems, OS'es, all kinds of IoT and machinery, all of which have their own standards, their own philosophies, their own tools, their own way of doing things. None of this would ever work if one tool decides it has the Truth and all other should conform to it. Without the UNIX philosophy none of this would even get off the ground. Because that is wat Pharo is, a tool, _inside_ an already living ecosystem. That is exactly why you get programmers asking, why can't I use my tools, why can't I use the "shell", do this do that.. This tool does not fit the UNIX mindset: it's just another tool, but it pretends to be an entire ecosystem that handles everything. An OS inside an OS. This does not make sense to anyone (but the Smalltalk people apparently). Also, as an aside, that is exactly why emacs sucks (take that HN!!).
For some reason some people think programming is hard because you have to create some classes and struggle with basic syntax. Inspecting trivial object and deciding the value of its sole attribute is "2" or "A" is not what makes our work hard.
And yes, UI _is_ a crutch. Only visual tasks need visual interfaces, think Photoshop. Visual UIs slow you down, that's just a physical fact - how fast is you hand? - and it is totally reasonable for new/incompetent users and/or users that perform visual tasks, but programming is not a visual task. Programmers think in abstractions, in symbols. GUIs have their place to be sure, without autocomplete I would be useless, so there's that, but beyond that, nope, useless crutch for incompetent users. Take that, society.
> Without the UNIX philosophy none of this would even get off the ground.
So the UNIX philosophy was the only possible way computing could have gone to result in a diverse set of systems that communicate with each other? Is there some sort of CS proof of this claim? Or was it just how history played out?
> For some reason some people think programming is hard because you have to create some classes and struggle with basic syntax. Inspecting trivial object and deciding the value of its sole attribute is "2" or "A" is not what makes our work hard.
Alan Kay and some others have thought programming would be more productive if it took place at a higher level than manipulating text and files. You might not agree with that, but the reason you have such good tools for text and file manipulation is because the Unix way prevailed. Magnitudes more effort has been poured into making that tooling than alternative approaches.
> Visual UIs slow you down, that's just a physical fact - how fast is you hand? - and it is totally reasonable for new/incompetent users and/or users that perform visual tasks, but programming is not a visual task.
Well, ask someone with a lot of VB or Smalltalk experience how much the environment slows them down in comparison. Because you often hear the opposite.
> GUIs have their place to be sure, without autocomplete I would be useless, so there's that, but beyond that, nope, useless crutch for incompetent users
I guess debuggers, refactoring and class browsers aren't useful, then.
> Impressive, but obsolete - not unlike France itself.
Update: I'm using it now for a while and it's quite epic. So yeah, it's awesome, but in a forbidden fruit kind of way that I cannot condone and thus none of you guys should be using it.
> So the UNIX philosophy was the only possible way computing could have gone to result in a diverse set of systems that communicate with each other?
I don't know and it is not relevant. If you're so inclined you may come up with another paradigm. Anyway, Pharo in particular is not such a paradigm, it's a fancy tool. Fancy, but a tool and it should behave as such and should co-operate, and it doesn't and that makes me very, very, very angry. And upset. And hurt. :-)
> Alan Kay and some others have thought programming would be more productive if it took place at a higher level than manipulating text and files.
I understand, but saying "text manipulation" is quite derogatory. It is _symbol manipulation_, that is what we are doing. The underlying mechanisms of the OS, filesystem and various media are irrelevant. What if I don't work with files, but "symbol maps" or whatever the F* some academic can come up with in his own custom fancy GUI tool. It doesn't change one bit. I still have to manipulate symbols and it still needs to be encoded somewhere. Increases on the fancy-dimension mean decreases on the is-robust-and-useful-in-a-general-way-dimension, not to mention the works-at-all-in-20-years-dimension.
Text files are just low common denominators. They are simple to understand and work well, not only across space, but more importantly, time as well.
> Well, ask someone with a lot of VB or Smalltalk experience how much the environment slows them down in comparison. Because you often hear the opposite.
I know, but that's not the point. I'm not saying Pharo is bad at what it does, being an excellent IDE. It's wonderful. I'm opposed to the ideology of throwing away all UNIX lessons and integrating everything into one God-system. I guess I've upset not only the Smalltalk, but now also the Windows people. Sorry.
> I guess debuggers, refactoring and class browsers aren't useful, then.
These are aids, typically implemented graphically, but not always - Vim has excellent autocomplete, refactoring and class-browsing plugins. Yes, some tasks map excellent to the visual metaphor. Scanning hierarchies and seeing high-level overviews are indeed useful abstractions, but that is not the point. The point is that if you want an excellent debugger, use an excellent debugger. If you want a good refactoring tool, use a good refactoring tool. Don't throw it all in one system and call it a day. That is not the UNIX way and yes, I am saying that is the superior way. In all of its vulgar, plebeian ways, the UNIXes have stood the test of time and I'd seriously reconsider dumping that.
~ Angry, but generally peaceful if slightly anxious and over-caffeinated Engineer
I sympathize with your criticism, which reflects my first impressions of Smalltalk when I played with Smalltalk 80 on my Atari ST 25 years ago. An impressive system, but isolated from the rest of the universe.
However, today's Pharo has made significant progress with interfacing to "foreign" stuff. The file system has become a first-class citizen of the environment. There is an FFI to work with C libraries. And of course support for network protocols. Source code management is based on Git. It's the GUI that remains in a world (window) of its own, but otherwise Pharo's system integration level is just a notch below languages such as Python or Ruby.
Your comparison of Pharo/Smalltalk with Unix is pretty accurate and is the one much people misses, comparing Pharo with other computer language, without taking into account all the companion tooling to make such system work: debuggers, editors, DVCS, graphical toolkits and a long etc.
A more detailed explanation of how Smalltalk compares to the whole Unix environment can be found in "Tracing the Dyanbook"[1], but goes in the same route as you (with a pretty detailed philosophical, educational and historical view of the Smalltalk/Dynabook approach about what computing could be).
So Pharo/Smalltalk can be orders or magnitude less complex that a full OS and yes is running inside one, but for me that means that it gives you a unified way of dealing with environment/OS complexity (mostly incidental) by providing an interactive, live, supporting place to thing about your prototypes. I made Grafoscopio[2] using Pharo, after trying the Operative System approach and translating symbols to files and dealing with that mismatch and with a plethora of (incidental) complexity (See [3]). Despite of being a Unix/Linux user since 20+ years and a novice coder at that time, the feeling of empowerment provided by Pharo compared to the tools I was using in Linux before was pretty big.
I'm glad you have decided to test the tool by yourself and I highly recommend reading [1] for a deeper understanding on how Unix and Pharo/Smalltalk compare to each other and how the last implodes complexity, even when living inside the first one.
I am using Linux a ton (actually on clusters of boxes) and have a boatload of tools and languages (including low level C and in the past, assembly).
Now, I am also using Pharo to do things on Linux and it is easier and faster to get results out of it, especially when I need to fix a failure.
Pharo is not replacing the OS (even if it may feel like it).
One can deal with a running Pharo remotely (either via VNC directly into Pharo or with Pharo7, using Calypso remote connections).
I am with you on the symbolic aspect but still, having an image that one can inspect is great. I was not understanding its value when I started. Now, I do. And I also find it awesome to have a stacktrace saved to disk on a server so that I can reload it into my desktop box and see exactly where things went south, including variables, values etc. Try that with a core dump.
Now, to each its own and I have a personal little project I should actually deliver, namely being able to expose a fuse filesystem from a Pharo image, so that I can use vim and tmux and those things right from a server. There is no technical issue doing this, just damn code it.
The current Pharo is not an OS inside an OS. UnifiedFFI actually makes it easy to bind with C libraries (heck, I wrapped LibStrophe which is full of callbacks, callbacks that are actually written in Pharo, including full debugging on callbacks, see https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPj...) and the more Pharo evolves (been there since Pharo 2.0) the more it delivers on what I need.
With the new boostrapping, one can actually have images with just the bare minimum (no UI, no devtools) so that it can run.
What is also interesting for me in Pharo is that it actually stood the test of time. I am sick of new languages that pop up all the time, where one is relearning the basics with half baked libraries. Pharo core classes are solid, work well and after working in there for a while, it becomes second nature to do quite advanced stuff that one would not even dream to do in, say, Java.
Pharo is indeed a tool and in my toolbox, it is one the best ones so far. Coupled with Unix tools, it is a beast.
I not care if it is getting popular or not. What I care is that it works, that I can influence its course and change what is not pleasing me (try that with other toolchains).
And also that its community actually owns it, not a commercial organization like Oracle, Google, Microsoft...
In that regard, Pharo is pretty much aligned on Linux.
The Pharo community understands the limitations or warts of Pharo, because there are some. But the features are currently delivering a net positive.
And, a little thing that is quite important: I have fun creating and maintaining systems I have done in Pharo.
This really contrasts with other solutions where fighting with accidental complexity takes 50% of the time, if not more.
Anyway, to each its own. I can relate to being angry when engineering. Pharo is lowering the level on my WTF-o-meter, which is actually good.
You certainly can use Pharo with normal tools. You just write (and version, and whatever else) your code normally in files, then you "file in", or load, those in Pharo. You'd need ~3 lines of a wrapper if you don't want to do it manually.
I share your concerns, actually - the truth is, the code editing part of Pharo is its least compelling feature and just cannot compare to my Emacs setup with years of tweaking behind it - and I tried working outside of Pharo at one point. The main problem with that was the loss of many features of Pharo IDE: autocompletion, go to definition, who calls a method, refactoring support, unit test support, debugger (it's magic, really), eval anything anywhere and more.
In the end, I decided that it's not worth it to insist on using my normal tools and learned to use Pharo as a whole (although text editing still sucks, which can explain why the average length of a method tends to be so low in Smalltalks...)
The small size of methods is a feature, not a bug :-).
And this partly explains why the lack of [your favourite editor] bindings isn't so important. You don't typically spend as much time as you're used to typing in code - and make progress faster as a result - counter-intuitive as that may sound. The integration and the debugger are most of the reason why.
It sounds a lot like you are trying to tell a programmer to stop programming using the keyboard and program using the mouse instead. I think I understand why you are doing that, but I don't see how you can expect to be successful this way.
For 99% of programmers out there, programming IS typing on a keyboard. Clicking around with a mouse is only something that non-expert users (or children, e.g. Scratch users) do, because it is approximately 10x slower to get anything done by laboriously pointing and clicking than by typing. For example, finding the largest file in my home directory through the GUI takes 5 careful targeting operations and 5 clicks, a click-and-drag, and then some scrolling, and then I have to do more dragging to move the window around so I can see what's under it. Using a keyboard I type "ll -S" and I'm done in half a second (and immediately able to issue the next command). You simply can't compete with that.
Even though it isn't the same way you are used to operating, I think it will be necessary to take into account the needs of that audience if you want to bring them on board.
As a thought experiment, what would it take to make the environment comfortably usable with only a keyboard, including discoverability of all the necessary keyboard controls? You could treat it as an accessibility issue; what if the user is unable to use a mouse?
As a Pharo contributor, well, there is indeed some clicking involved but not as much as you may think.
Keybindings are okayish at this point but can use some more love indeed. But this is not related to the core of Pharo but to the tooling that can be improved on some aspects (and this is moving forward actually).
If a user is not able to use a mouse, well, maybe the user can have a CI that integrates all of the code written in Tonel format and pushed to a git repo. Can work, Tonel format is pretty readable and usable from a command line.
There are ways to use Pharo as a "normal" language. But then, what's the point.
I see the new framework for keyboard shortcuts was completed. There are many shortcuts to customize in preferences now. Congrats! :)
Still, the shortcuts by default are totally different than the usual. Is it possible to make for example readline (bash) emulation with the new keyboard shortcuts code? Where would you start if you wanted to do this?
> As a Pharo contributor
I played with 7.0 yesterday, I have a few questions, maybe you'll be able to help me:
- I work on a Linux with high DPI display. I increased the font size of everything to extra large and set scaling factor, which helped, but the cursor is still tiny and almost invisible. I tried reading the code in HandMorph and Cursor, however, the beCursor method which handles displaying of hardwareCursor (I assume) is a primitive. I downloaded the opensmalltalk-vm and after a short fight with it succeeded in running its image. I found primitiveBeCursor method, but it calls C-level function called something like `ioSetCursorSomething` - and I couldn't locate that function. Do you know where it is?
- when you set scaling factor and font size, it's not universally recognized. The menu at the top of screen didn't change its font size, the lists with columns (in preferences, in debugger, etc.) have fixed column-size which truncates most entries (and splitter for changing the width of a column is barely visible), some elements start overlapping (tabs in the browser obscure the row with instance/class side, flat/hier and so on), the windows seem to have hard-coded initial extents which ignore font-size and scaling. To be honest it's barely usable right now for me, to the point that, to play with it, I had to create a dummy Xvnc display and run Pharo there, then run x11vnc on the Pharo window id and finally connect to it via VNC client, scaled the whole thing up. It's a bit nightmarish an experience :) Is there any work towards making it better in progress?
- related to the above, is it possible to set the initial extent of the Pharo window (the top-most, OS-level one, I mean) on the command-line? There's a switch for starting in iconified state or fullscreen, but I didn't find one like `size` or `geometry`.
- What are class "extensions"? Are they simply traits, or is it something new? Is it documented somewhere?
---
I see lots of great progress on all fronts, but Pharo remains rough around the edges. The discoverability of the details is great, but the bigger picture - an overview of all the toolkits, for example, or a succinct description of architecture - is very hard to piece together. The new package manager interface finally displays a bit of description for each (this wasn't the case for a long time), but many packages have no description. Coupled with package names being rather hermetic this makes for a frustrating experience. I'm a rather persistent kind of guy and so I stuck with Pharo despite all that, but I imagine many other devs wouldn't care to do this, unfortunately.
Note to self (mostly): there's a SQUEAK_FAKEBIGCURSOR env var which you can set to 1 to have the VM display twice as big cursor. I've no idea why there's the 'FAKE' part, from the source it looks like it just creates a normal X11 cursor that's twice as big. This should work will Cuis, Squeak, and Pharo, as it's part of VM.
The problem with the keyboard-only input style in Pharo is that it encourages opening lots and lots of windows. Arranging them by hand is tedious with a mouse, and with the keyboard, it would be unbearable I think.
There is the infrastructure for custom key-bindings in place, although last time I checked it was being rewritten; I think that was finished around 6.0.
What it would need, in my opinion, as someone who almost never touches a mouse myself:
- either a tiling window manager or a set of fixed layouts for where windows should appear. I'm not sure how is the placement of new windows currently done, but it's rather dumb.
- something like this: http://oremacs.com/download/ace-window.gif for switching focus between windows. Failing that, the ability to switch focus to the window on the left/right/top/bottom. switching between hordes of ungrouped windows in Ctrl+Tab is a nightmare.
- easily overridable global key bindings. This was rather complicated last time I checked. Also, the key-binding model should be powerful enough to allow for chords (sequences of keys: Ctrl+X, then Ctrl+Y, etc.).
- a mode which would go through all the widgets in the current window and display all available labels (over buttons and menus). Most of the labels contain a name of a function and a keyboard shortcut already.
- there's a Shift+Enter shortcut which opens Spotter: you can type some characters and it will search the image for anything matching, including code, comments, external packages, and global menu items. It would be great if it was also context-sensitive so that you can invoke functions of the currently focused window through it too.
- Emacs/Readline and Vim bindings provided in the base image would be very appreciated.
That would be a good start, I think :) It's a lot of work, though, and there doesn't seem to be a will to pursue this in the community, unfortunately :(
Was about to say that myself. How many programmers (especially Linux ones) use vim?
Out of the emulations I’ve seen, JetBrains one is perhaps the closest to real vim (albeit not without a few weird corners). If Pharo is so flexible and modular, wouldn’t it be quite easy to add official support for vim mode?
// I’m honestly baffled at why people who code for living often do not use vim keybindings for coding, but that’s a separate story
I've yet to use a Vim emulator that worked as well as Vim though. The amount of features in it are mind boggling and replicating that would be the work of a large fully funded team.
Even so, lots of people find emulators useful, especially in the context of an IDE that brings its own compelling features to the table. For years I used a commercial emulator in Visual Studio that was a huge boost to my productivity. It was the work of a sole developer.
And smalltalk does bring a lot of compelling features, as others here have noted.
(And some emulators are quite good, like evil-mode, which has converted some hard-core vimmers. Which also makes me wonder about implementing the core of emacs in smalltalk, making similar functions available, and extending it with smalltalk instead of elisp.)
>I couldn't understand the fascination with the integrated environments though
That's one of the key benefits: the environment is an object too.
First class IDE knowledge about your objects (Smalltalk pioneered automatic refactorings etc), the ability to modify it as you like, hot code reload, re-startable apps, "live" images to send for debug, etc.
It feels like an alien world moving into the Smalltalk live environments and the patterns I've built up over the years and tools like Vim, etc are indispensable when it comes to moving around and modifying code. Of all the reading I've done on it, the entirety of the language is contained inside images. I know that the Pharo guys have engineered this marvel, and I think it's on the verge of a breakthrough with a lot of people if they can ease into it somehow.
It is an alien world.... but a better one by most measures.
I come from Emacs (20+ years when I first encountered the Smalltalk IDE), and find aspects of code editing irritating sometimes, but the overall value of the IDE more than pays for that irritation.
One of the coolest things is TDD carried to an extreme level. I build my test, and it fails because there's no such method, so I get a debug window and tell it to create the method... then I fill in the contents and click proceed... and picks up where it left off! It either works, or I'm back in a debug window fixing what failed. Total time from thinking of a test to working code, often less than 5-10 minutes.
(Joking of course, but there's no reason a Smalltalk environment could have a Vim-behave-alike editor, but even better, e.g. with semantic knowledge of the code instead of just words and chars).
I'm incredibly frustrated by environments like Ruby on Rails which pay lip service to the idea of "everything is an object" — but those objects are just a cesspool of hollow non-evolving throwaways that get built up and torn down on every request.
It's the difference between a castle made out of toy blocks and the Buckingham Palace.
The liveness of the environment is really stellar. Other languages have REPLs, but once you've entered your code, it gets compiled and saved in some internal format. In most languages I've tried, there's been no way to retrieve the originally written code. That's possible with Smalltalk.
That was a real eye-opener for me. In most languages (Java, C#, ...) the standard library is like a mountain range - you can climb it, but you cannot change or move it. In Smalltalk, it is like a living room, where I change or move the furniture around as I please.
Pharo is making some moves in this direction with:
* the CI first bootstrapping a non-GUI image as a separate artifact prior to loading the GUI and IDE into the release product.
* good progress on stripping graphical elements out of the VM so it could be embedded in other systems (e.g. as a game scripting engine).
* using git to manage sources.
* some community `vi` keyboard bindings (I haven't tried)
But still there is not yet an easy access to use separate tools. The benefit of using Pharo IDE is being able to mold your tools...
http://www.humane-assessment.com/blog/the-moldable-gtinspect...
No, but you can use something like GNU Smalltalk (http://smalltalk.gnu.org/). But part of the allure of Smalltalk is the environment, not the language.
You can use source code control to keep yourself outside the environment, but I don't know if it's worth it. The Smalltalk environments allow for unique workflows, and that's a lot of the appeal Smalltalk has.
POSIX is similar to what you describe. It's a unified paradigm that wrestles the complexities under one paradigm. UNIX philosophy of each tool doing one thing, and doing it well, combined with the constructs that are provided through shells such as inter-process communication and piping everything has turned out to be quite the solid foundation for software development. I'm not saying we couldn't learn lessons from Pharo, but that I'm not so quick to dump everything else to live inside their bubble just yet.
Ok, I won't speak out of my bottom, but from the few that I knew, POSIX used to be a minuscule incarnation of this[1]. But I don't think it's 5% of smalltalk live environment:
- file metaphore is limited, object are marginally better
- dynamic language instead of edit/compile/run
- infinitely more humane than C/sed/m4/awk/perl hybrid interactions
[1] There's a unix book about how to see it as an IDE, I do believe that long ago, BSD era, things were smaller, cleaner and better integrated. But I still hold my point
> IoT is now an important part of Pharo. Installing PharoThings (https://github.com/pharo-iot/PharoThings) provides an impressive amount of tools to develop applications in small devices.
The Pharo website has zero mention of its relation to Smalltalk, although the Wiki article calls it a dialect.
So how close are the two in reality? Is the syntax from your standard Smalltalk-80 textbook largely portable/compatible to Pharo, or is Pharo merely "inspired" by Smalltalk?
Squeak is directly descended from ST-80. Ten years ago Pharo forked from Squeak due to conflict around adding features outside the ANSI standard. Pharo wanted to distinguish itself from Smalltalk to avoid constraint by the standard so minimises mention of it. But Essentially Pharo is Smalltalk plus...
The syntax is similar, and for the most part, compatible. Pharo's syntax has a few extra extensions, but nothing incompatible.
But Pharo's is inspired by Smalltalk, and I myself consider it Smalltalk, but the purpose of the detachment is to not be constrained by having to continue being Smalltalk.
E.g. in Pharo instance variables are first class objects (called "Slots").
Final steps have been taken to make it useful from small devices up to enterprise usage. Still the best working environment ever encountered. Congrats to this gem!
Every time I try a Smalltalk (++) implementation, the custom UI framework is what kills it for me. Not only are they completely non-native in look and feel, but they also lag behind on features - e.g. Pharo is apparently non-high-DPI aware on Windows.
The main issues that prevents me to have an interest in Pharo are the following two:
- There is no real multithreading support
- It's not easily embeddable
I believe that there are attempts to tackle these problems but what is the status?
The traditional problem embedding is that the VM did a lot of window configuration before the image started. This has all been stripped out of the "minheadless" builds, which have defined a "virtual machine interface"
used like...
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/p...
This has been a point of contention for lots of people, including myself. From what I remember, it was supposed to happen for Pharo 7 but now I see that it didn't.
Squeak and Pharo are great but the font rendering is terrible, I can't stress how bad it looks on hidpi screens. That makes it unusable for me since it gives me headaches. It's a shame too since they have spent a lot of time working on related frameworks (athens?, brick?, bloc?) that alas don't seem to go anywhere (or nobody is in the position to bring everything together). Last I checked they were trying to use a native library from Mozilla (Moz2D which is the backend of Firefox!?!?) to do all rendering, which is highly problematic and disappointing if it ends up being used. The clusterfuck of libraries that they have layered together should clearly point out that this is not the right approach.
On macOS, the graphics stack looks like: CoreGraphics <- Skia <- Moz2D <- Sparta <- Bloc <- Brick
Alan Kay would have a seizure. Aliaksei Syrel: What happened to keeping things simple?
I really hope the graphics issues get resolved since I'm pretty sure they are costing them a lot of users. The regular Pharo devs by virtue of using Pharo every day are (probably) not in the position to realize how a new user coming from environments with great font rendering, UI speed/smoothness, reacts to Pharo. Initial impressions are everything.
I agree that the appearance of the system in this regard probably turns off lots of users. There are some in the Pharo community who are quite aware of this fact, but there are simply not enough contributors at the moment to deal with it on their own.
I am more hopeful about Bloc, however. The stack is not any more insane than that of a web browser.
The entire subsystems were rewritten from scratch, there are huge lengths of deprecated and/or poorly documented code, however, this hidpi bug remains unfixed for 5 years or more.
This is not about having too few contributors; this is about different priorities. This is why Pharo remains an obscure project on the margins of the industry, despite all its potential.
I haven't evaluated the appearance of text in Pharo, but I agree with the importance of the issue. Poor text rendering in any application or environment would be an immediate dealbreaker for me.
TLDR: Pharo needs mountains of high-quality documentation equal to Python's docs or Java's docs if it seriously hopes to attract server-side or desktop mindshare among developers.
Long Version:
In 1980, Smalltalk had some of the best documentation of any language out there. In 2019, it basically has none. By 2019 standards, Pharo 7 ships without any documentation at all. That's a game-stopper.
Pharo 7 looks really polished. It sounds like the design team put in tons of hard work over the past year and half to produce this release. Moreover, since it's smalltalk, Pharo is also probably very powerful for both web and desktop development. BUT NONE OF THAT MATTERS IF DEVELOPERS CAN'T FIGURE OUT HOW TO USE IT!!!
(pardon the all caps, but I want to emphasize my point)
Here is my message for the development team: if you really want developers to start building stuff with Pharo, then you absolutely must (1) write detailed, soup-to-nuts, high quality docs for web design and (2) write another set of detailed, soup-to-nuts, high quality docs for desktop GUI programming.
The Pharo book doesn't cut it--not even close. It's not a very good book. The Pharo MOOC doesn't cut it--again, not even close. Who wants to learn that way? ProfStef is just a fancy hello world; it's really not a tutorial and it doesn't lead anywhere.
I realize that what I'm saying comes across as pretty strong medicine, but please understand, that's because I actually think Pharo looks amazing and would like to use it.
In my opinion, you should stop development on Pharo and document what you've built instead. Write docs for a year. Today's release announcement states that the Pharo 7 team closed 2142 issues. Brag in 2020 about the fact that you wrote 2142 pages of documentation and tutorials over the past year. Make your documentation coverage as thorough as your testing coverage.
Imagine what might happen if Smalltalk 2020 was as thoroughly documented as Smalltalk 80.
Even after I run the image, the browser doesn't make for the best tool to learn the overview of the system. Methods are tiny and a lot of them and you must click each one in turn to see the docstring. It's not easy to know which class is in which package or why. A lot of the classes have no docstring, but are described in some the ancestor class, and there's no way to display dosctrings of a group of classes at once - instead, you have to click through them manually. Various search tools help, but it's also not immediately obvious where they are or how to use them.
The system gets infinitely more discoverable once you install Roassal, which has tons of very useful example visualizations. But it's not installed in the default image, you need to know you need it and know enough Smalltalk and Pharo to install and run it and then how to modify the examples to make them useful for your current exploration area.
Anyway, that's how it is: painful to learn. It's great if you have someone to take you through the whole thing, but that doesn't scale, while the rate of change renders non-reference-like docs (Pharo by Example, Deep into Pharo) obsolete very quickly. Putting Pharo-devs effort into actually documenting the classes and then exposing these docs in accessible HTML is something I would really love to see one day...
Do you have a particular example of a site where the kind of documentation that you would like to find is published for other language (lets say Python)? This could help to understand better which are the expectations and why current books and MOOC are not enough.
From my experience as a recent Pharo user (started in October 2018 with the Pharo MOOC), the two main issues with existing documentation are
1) Much of it is outdated.
2) Much of it supposes significant prior knowledge of Pharo.
Once you start to become familiar with Pharo, neither is much of a problem. You see that the screenshot of Pharo 5 resembles what you see on Pharo 7 in spite of superficial differences. And you picked up enough of the jargon to be able to judge if some documentation is close to your level or not.
For someone who downloads Pharo 7, starts it up, and wonders "what now", most of the existing documentation is confusing. The MOOC was a much better starting point back in October, but with the new system browser in Pharo 7, it's seriously outdated as well.
GUI documentation will likely never show up: the current graphic framework is outdated, subject to deprecation and no subject to improvement since Athens low level layer was left as it is. It may or may not be replaced by Bloc or something else. I don't thing anyone is willing to write documentation when there is not clear direction regarding the GUI framework.
> when there is not clear direction regarding the GUI framework.
Isn't it crazy for this not to be solved yet?! That's a long time - don't remember exactly, but I started with Pharo 1.4 IIRC, and it was bad back there already, then juz got worse.
Is there a blog post detailing a) all the kinds of GUI frameworks that are out there and how advanced their development; and b) what approaches were tried and abandoned, when, and why? I know it's much to ask, but, at this point, I feel the lack of progress in this area should become a much higher priority, and a blog post like would help in recruiting people for the effort.
Here is a link to Python's docs(https://docs.python.org/3/). It's still a little busy, but you can go a long way just by using the Python Tutorial (helpfully subtitled with 'start here') followed by the full Library Reference. A lot of people rave about how great Python is and how popular it's become, but I think one of the unsung heroes of Python's success has been the great documentation.
A (fairly) recent language that appears to have taken a page from Python's documentation success is Google Go. Here's the Go Docs:(https://golang.org/doc/) Take a look at that page. It describes Go, then tells you how to install it, then provides a pretty good tutorial (called a Tour of Go), and then provides a really comprehensive Reference Manual that tells you the various libraries Go ships with, which includes a hyperlink that reveals documentation for each library, and if you explore the linked page and click on a function, that's also a hyperlink that takes you to the actual code for that function so you can read the source code--itself is written in Go. Basically, it's easy to see how Go works, find out what libraries it includes, read good docs for each library, and even explore the library's implementation.
Continuing my argument, I would propose that many of the widely adopted languages of today aren't just good languages, but also benefitted from really good documentation. K&R is still famous, even though the last edition came out in 1989. Here's an interesting question: does C become such a big hit without the fantastic books it had? In the pre-WorldWideWeb universe in which C came to fruition, great books were critical. I would argue no. I believe it's documentation was a critical element of its success.
I think Perl has a similar story. Yes, it was powerful and useful and that was a big feather in its cap, but it also had amazing documentation in the form of books(Camel Book, Llama Book, O'Reilly Perl books in general) and man pages. It's easy to forget--and some don't even know about--the amazing man pages that Perl enjoyed. Here's a hyperlink to Perl's Man Pages table of contents: (http://perldoc.perl.org/perl.html) They are awesome! For example, check out the Perl regex tutorial man page: (http://perldoc.perl.org/perlretut.html) To this day, that's still probably the best explanation of regexes out there. And if that's too much, you can read Perl's quick and dirty regexes man page instead:(http://perldoc.perl.org/perlrequick.html) There's man pages for so much in Perl it's ridiculous.
(Rough waters ahead...)
Now back to your first question about Pharo's current docs. Here was my experience...
I checked out the links you posted. After a few clicks, I got a page with a bunch of pictures that looked like books. I'm wasn't sure what book I should pick, but "Pharo By Example," seemed promising. I clicked on it and discovered it's a PDF--not the preferred format for the web--that tells me the current version of Pharo is still Pharo 5. So I'm already worried because the book is out of date.
OK, I move forward to page 16 before I get to hello world. That's not too bad for a book, but slower than lots of web based tutorials, which is the real competition for "Pharo By Example" since I'm reading it on the web. Page after page then scroll by about Pharo the IDE, but not Pharo the language, which is what I'm really trying to learn about. Finally, on page 28, the book says we get to learn how to define a method, which is apparently how we do anything in Pharo, but then we crash to a stop and write a test first! Then we move forward again until we, at last, get our second piece of code:
shout
^ self asUppercase,'!'
That extremely short method doesn't arrive until page 31.
Next we move to Chapter 3 and make a GUI game called LightsOut, which sounds cool, but it's like drinking from a fire hose because none of the syntax or libraries have been explained yet. (Note: At this point, I don't feel like I could run with this example to make games of my own.) If you survive Chapter 3, which is doubtful, and make it to Chapter 4 on page 59, the book finally explains Smalltalk syntax, though even this seems a bit jumbled since the real discussion of message syntax, which is at the core of Smalltalk syntax, is pushed back to Chapter 5 for some reason. Control structures are discussed in Chapter 4 instead. To put that into perspective, there's a mention of blocks serving as lexical closures in Chapter 4 before we really find out how basic messages work in Chapter 5.
By the end of Chapter 6, we've covered the Smalltalk object model and I still have no idea how to actually make a program! At least, I don't think I do.
To put it bluntly, "Pharo By Example" isn't a good programming book. Yes, I recognize it's a labor of love. Yes, I recognize that it's being given away for free. Yes, it took time to write. That's all noble. But it doesn't change the basic, ugly fact: "Pharo By Example" fails to get the job done.
At this point, I'm not at all confident that I will be able to program in Smalltalk after reading this book. More importantly, the book hasn't provided any real reason to become a Smalltalk programmer. It all looks a lot like IDE customization and tools for a language that doesn't seem to run anywhere except in the IDE itself. As an emacs user, I've already got one of those... :)
Seriously, I think some real thought needs to be put into explaining (1) why anyone would benefit from Smalltalk instead of more mainstream language and (2) how to showcase Smalltalk's strengths without getting lost in the weeds of the IDE.
Here's the curriculum that I suggest:
(1) tell us how to download, install, and run Pharo
(2) demonstrate how to build a few old school IO games--HiLO, Hammurapi, Trek, etc...--so we see how you can do IO. Along the way, introduce Pharo's syntax
(3) give a full, long-winded, boring as hell discussion combining and improving upon Chapters 4-6 where you admit up front that it's going to be boring as hell and then
(4) go back to saving stuff to Github and distributing the software.
(5) explore the various parts of the IDE in independent chapters while providing real examples of how those features make our lives better.
(6) go back and provide an entire section of webpages explaining, in great detail, the Morphic stuff that just gets a passing glance in the book for that LightsOut game. It really looks like there's something there, but who knows. That little chapter on Morphic in the back of the book doesn't remotely cut it.
(7) provide separate chapters on important libraries? that Pharo comes bundled with--the kind of libraries that all modern languages take for granted and expect.
(8) provide some real-world, well-commented, Pharo programs for us to dissect so we can see what they look like. For most languages, I can just download a few open source projects and read code until I'm sick of it. Does that even exist for Pharo?
Let me say again that I honestly think Pharo looks amazing. I really want to know how to make something in it, but I'm not sure I ever will because the amount of effort I'm describing is huge. I hope it happens though.
Finally, I recognize that my feedback was critical. I sincerely hope that you take it as constructive criticism rather than as an attempt to insult. The last thing I'm trying to do is insult anyone.
Your points about documentation are well taken. There seems to be a dissonance between the mainstream world and Pharoers in this regard. Mainstreamers pretty much expect documentation to be good and to be reliably available via the web (I expect this myself in most cases). In the mind of a Smalltalker, there's no need for a web page that lists classes, methods, and what they do because that's precisely what is available inside the image and what many of the built in tools are there to provide. Now, is that good enough? Clearly not. Outsiders might not know this is the case, especially if they are coming in completely blind.
I think it would be not too much work to parse out this kind of information (Class comments, methods and method comments, structure etc) and spit it out as a web page that could be hosted somewhere. Do you think this would help, at least somewhat, to bridge the divide with new users?
Your suggestion of parsing out the in-code documentation would go a long way towards documenting the libraries, provided the documentation is of high quality. However, that still doesn't address the bigger question: how do I program in Pharo.
There's a book, "On to Smalltalk" that actually did a decent job of getting you started, but it's decades out of date now.
It's more like "programming Emacs" instead of "programming in Emacs".
Try writing a mode for Emacs, something like Helm or NeoTree or Dired, in Emacs and you'll get pretty much the same experience you'd get from Pharo, although with a lot less visual feedback. Emacs is concerned mainly with text and it's naturally reflected in its APIs, but the fact that you can live-edit any function or advice and see its results change immediately after pressing C-M-x is exactly what Smalltalk/Pharo does.
It's magical, in both versions. Smalltalk was designed for GUI first, so its APIs for manipulating graphical objects are much like Emacs APIs for text manipulation: vast, rather complete, also a bit arcane due to decades of history. There's one thing that Emacs lacks and that would be support for restarting code execution from any place (possibly edited in the meantime) on the call-stack after exception: Pharo's debugger lets you do that, which is a thing worth experiencing at least once as a programmer. :)
I use Emacs, and I played around with Pharo, Squeak, and Cuis. I would go so far as to say the Emacs is an acceptable Smalltalk, but the Smalltalk environment’s defaults are far better. It’s worth playing with it to experience it (see just how good TDD can be)
Is it possible to integrate Pharo with KDE so the windows won't be trapped inside the Pharo window (I don't really like MDI) and would have system-set decorations (I love using "keep above", "keep below" and "shade" buttons I've added via the window manager configuration)?
A few years back Pharo's predecessor/sibling Squeak was garnering some interest due to its "Seaside" web framework, which used continuations and so made some interactions easier to program.
But after the rise of JavaScript, this became a lot less important.
Looks interesting. Getting a weird error when installing it via Homebrew, though: "“Pharo6.1-64” is damaged and can’t be opened. You should move it to the Trash."
I think this is some BS that has to do with OSX's "security" and that applications like this are required to be in the Applications folder. I could be wrong.
These are commercial vendors, but there are industrial uses of Pharo itself, and as Pharo gets better a lot of companies are moving from their commercial dialects to Pharo. In particular from Cincom Smalltalk to Pharo.
I deployed a few web apps running on gemstone based on their community edition starter license.
You can get a lot going just based on that and it really isn't as expensive as Oracle.
The Oracle example was more a kind of figure of speech regarding the kind of clients that are willing to pay for commercial Smalltalk, based on the listed customers use cases.
Well, I never got to needing a paid license so it never was a worry. I found the database size tended to grow more slowly than what I expected from past experience with MariaDB/MySql and PostgreSQL.
All and all I found the killer really was the ability to store situations where an exception was raised and being able to replay it later. It saved a ton of time for debugging.
There is steadily growing industry backing for Pharo formalised in the Pharo Consortium - companies putting hard cash on the line to support its open source development.
http://consortium.pharo.org/web
I have Pharo installed on my laptop to try some stuff out with it, but I haven't gotten around to it yet. Maybe this is as good a time as any to start it up again.
Pharo is the most actively developed and used Smalltalk environment. There’s plenty of evangelism and information on the Web about it in a similar way to Lisp. Pharo takes the “integrated” in IDE to a whole new level, which is one of its selling points. You can find plenty more information about how Smalltalk-style OOP is superior to Java-style OOP, so I won’t rehash that here.
One of the key words in that statement was "actively developed". Cincom, Instantiations, and GemTalk have some great people working on them, but Pharo7 had 75 different people contributing - including probably almost as many full-time people as the commercial developers (maybe more).
I love Pharo, so don't take this as me trying to take anything away. Cincom "actively develops" VW as well. I keep in touch with that side just for my own information. Pharo is doing a phenomenal job.
It's a Smalltalk. It's half language, half environment. The language itself is one of the inspirations for Ruby, and you will find in Pharo a purer expression of much of Ruby. The whole, 'everything is an object' applies, but so does 'everything is message passing,' and in a much more thorough way. The language's syntax is almost reminiscent of LISP in its simplicity (not its actual form, but there is so little of it that you start to feel like you're working directly with the objects, rather than programming them).
The other half is the environment. It's possible to run Pharo code, e.g., from the command line, but if you do all of your Pharo coding and debugging from a traditional editor+terminal combo, you're missing out on most of the reason to use the environment in the first place.
The environment is 'live' while you code. The objects are live, and the environment itself is an object you can interact with. When you add code, your code executes within that very same environment. There is no separate runtime. The runtime and the codetime are the same. Your code simply gets saved as part of a Pharo 'image' you are editing, and this image can be reloaded and resumed from where you left off.
The most common idiom is to program with a "TDD on steroids" approach. You create a skeleton of a few tests, and start it running. The debugger will stop and tell you the object you are sending Message X doesn't respond to that message. So while the debugger has paused the environment, you add the method with the help of the integrated GUI. Smalltalk (the original Smalltalk) pioneered the use of a 'class browser,' which does what it says on the tin. Pharo includes and extends this concept. Once you've added your method (or even, added the class entire), just hit resume and the (incredible) debugger will take you to the next bit that needs fixed. This is a more powerful edit-and-continue that actually works.
Having said that, while I enjoy playing around with the environment and using it to prototype some class hierarchies, I've had a tough time finding a professional use for it. The very qualities that make it mind-expanding to learn and play with, seem to limit its use "in production," so to speak. Who knows, maybe I'm unique, but I couldn't see myself in a hundred years being able to convince my employer to use it.
But it really is an eye-opening experience to learn. Just like learning LISP pushed my personal boundaries although I don't use LISP at work, similarly Pharo has pushed my boundaries in a way that I highly recommend experiencing.
Mostly consider it a programming language and deeply integrated development environment. However its a flavor of Smalltalk which ran as the operating system on mini-computers circa 1980s. Pharo retains some of that influence. For example the whole runtime state of your application can be saved to disk and moved around like you would move a VMWare image.
"Pharo is a mininal, elegant, pure, reflective object language with a goal to deliver a clean, innovative, free and open-source immersive environment." [1]
> Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback.
and seeing the initial screenshot on the announcement, I thought that this was a joke post. How you can call this "focused on simplicity" while showing that horrific hodge podge of a screen shot is beyond me.
That's a pretty chaotic postcard. I think I get the point that it's trying to make, but at first glance it doesn't exactly convey the idea of simplicity.
It's a totally separate domain. Pharo/Smalltalk is essentially pure OOP in the way that Scheme is pure FP/LISP. So for me personally, I've used to increase the depth of my understanding of programming. It can also be good for prototyping class hierarchies and the like.
You can find examples of people using Pharo in production (and far more examples of people using other, more industrial-grade Smalltalk dialects), but I personally haven't been able to think of a way to use it on real projects. But that doesn't mean that it isn't worth studying.
One reason would be for trying out the environment, which represents a totally different approach to programming than the traditional file based and textual approach, instead of having your coding and runtime as part of the same environment, where you're communicating with live objects.
Every time I look at a programming language, and at the HN it is every second day, I think about what kind of problems can it solve, and for what kind of platforms these compile/run their runtimes.. and surprisingly not many programming languages inform properly about the most basic feature, and prefer to go deeper into their.