"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
