Why Pharo Might be the Future of Software Development (2017)
blog.appacademy.io
blog.appacademy.io
His personal points of view are all you get, heavily disguised as assertions about Smalltalk and the environment being categorically better or easier than things with which nobody seems to be exhibiting any real problems. Because the assertions aren't backed up with evidence, it's hard to take seriously. Not to mention every single post on every single website just repeats the same things ad infinitum; it's basically spam at this point.
This is mirrored by some of the more rabid fans. Whenever Smalltalk is brought up on HN, there's invariably someone or other to come and espouse that live coding is better than compile-debug-rinse-repeat. Why? Because it is. In what way is it better? It just is.
I mean, why wouldn't I want to switch to developing apps in an unfamiliar way with little in the way of easy-to-understand documentation, contained within an alien user interface to my beloved macOS, limited to an unnecessarily difficult-to-use IDE, using a language that I can only use in the IDE, that can't integrate with damn near any other popular or modern tools and workflows, whose ability to target mobile (or hell, native platform-specific experiences) is either in its infancy (in 2018!) or completely non-existent, and whose proponents can't give a clear answer to what the big deal is?
Yeah, no. A million posts saying the same things won't make a damned bit of difference.
Programming language adoption is as much about the transmission of culture as anything else, it's hard to do that with Smalltalk at a distance.
One way in which many people here will regularly encounter "live" coding (i.e. with very short cycle times) is at the bash prompt - grep, awk, et al - (and my opinion of bash... is another thing I won't expand upon), but the ridiculous archaic "let's pretend it's a teletype" metaphor has an interesting thing going for it - as you work you leave behind a transcript of what you did, and what the result was.
You can copy and paste that into an email, send it to someone and ask for help - maybe a mailing list, maybe a newsgroup. You can write it up as a blog post and say, "hey everyone - look at the clever way I did this". You can illustrate your tools and your working practices easily, and transmit your programming culture far and wide.
I object to this characterization. I have real problems with these modern complex languages all the time. Go on StackOverflow and look at how many issues people have with any of these "modern" languages -- even just syntax.
For example, I'm using Swift right now (Apple: "Swift is easy to use", "The language for first-time coders"!), and I've got a simple data structure problem I can describe in under 10 words, and I can solve it in fewer than 10 symbols in Clojure, but I've been struggling for the past 2 nights to figure out how to get the Swift compiler to accept anything at all related to my problem. I can't get the overrides and generics and type constraints to play nice with each other, even though the Swift 4 press release says it should be better now.
I'm at the point where I'm debating whether to use "Any" and cast the *#@! out of it, or switch to Objective-C.
Swift isn't even particularly unique here. Every recent language I've seen is this complex, or nearly so.
> I mean, why wouldn't I want to switch to developing apps in an unfamiliar way with ...
This sounds almost like it could have been a description of the first Macintosh, written by a pre-GUI user. Do we hate Smalltalk just because it's different, while admitting we don't understand why?
I never said I hated Smalltalk. I love the language and have played around with GNU Smalltalk a few times. Plus, I cut my programming teeth on Objective-C, so I have a firm appreciation for the language.
It's the fact that I have to enter a foreign environment that irks me. Way back in the day, when GUIs were innovative and new, and people were still working out the kicks, and input devices basically all did the same basic set of things in the same way, it mighn't have mattered.
Nowadays, operating systems have moved on, input methods have moved on, the way we do even some of the more basic things have changed. You've now got features integrated into the operating system that things like Squeak and Pharos can't access. You've got user interface metaphors that are consistent across the whole system except within Squeak and Pharos. You've got (poor) attempts to integrate with the host with commercial environments such as Cincom VisualWorks that, at the end of the day, really amount to nothing more than a rootless version of Pharos with a crappy theming engine.
I know many amongst HN's userbase won't be particularly phased by a different user interface, particularly Linux users where dealing with slightly different paradigms between applications is a fact of life. For me, a macOS user, the fact that:
- inertial scrolling doesn't work
- my Magic Trackpad 2's multitouch gestures don't do anything
- windows can't be managed using Mission Control (which is particularly a pain given that the major environments' IDEs don't respect system conventions around multi-document windows)
- many keyboard shortcuts aren't properly mapped or imitate Windows rather than macOS
- the environment doesn't let me type using macOS' Japanese keyboard, and none of the characters render properly by default without some tweaking
- the environments use their own fonts rather than system fonts, meaning my font collection is being ignored
- fonts are rendered non-natively, meaning they're all the wrong sizes and they're rendered differently than how I expect — particularly troublesome for CJK characters which are beautiful on macOS and hideous on everything else
- Pharos doesn't bother to render in high DPI, so it's all blurry — absolutely hideous on a 27" iMac
- system accessibility settings are not respected, so the fonts are all way too small for my eyes and VoiceOver can't read any of it
- since the environment doesn't respect the system, neither it nor anything you make in it can take advantage of any system features like system-wide Services, Automator, Applescript support, fetching data during Power Nap, system-wide Dark Mode in Mojave, and so on.
See all of those things? On far too many posts, in far too many comment sections, and far too many times on HN have I seen the Smalltalk evangelists act dismissively about all of that, as though users don't really notice. Maybe Windows and Linux users, where every app you come across is either in a different toolkit or doesn't necessarily respect your chosen desktop environment's metaphors to the fullest extent, are used to that idea.
Bearing in mind that 87% of statistics are made up, I'm going to say that a good chunk of macOS' users have gone to length of buying much-more-expensive-computers-than-the-competitors running an-operating-system-with-much-less-commercial-support specifically because macOS does so many things for them, so yes, the platform and user experience very much do matter. Those evangelists who say the platform doesn't matter are wrong.
I know I much prefer using Xcode over other IDEs not because I think Xcode is great (because it's meh), but because Xcode gets all of those system-level goodies for free by virtue of being a good, well-behaved macOS app. It runs the way I expect any other macOS app to run, I don't have to adapt my workflow around it, and those quality-of-life things make coding in it much more pleasurable to me than having to figure out a system I can (a) barely see, (b) barely type in, (c) barely navigate, and (d) barely use.
I may only be speaking for myself, but I'm a better coder when I don't have to fight the system.
Maybe someone just has to come up with a macOS-first Smalltalk environment, something that manages to respect the system. Make the Xcode of Smalltalk, minus the bugs, still keeping all the good stuff like live coding and what-have-you, but that make native macOS apps that do things the native way. Then maybe it could start making iOS apps. And so on.
Instead, it seems like rather than trying to make Smalltalk relevant to the world as it has become, the most ardent fans are trying to push the world back into the past — or in the case of macOS users, Linux's present.
What makes articles like this one really annoying are the same old claims that seem to be a bit delusional if not outright wrong, such as:
"the Pharo IDE is much simpler and cleaner than Visual Studio and Eclipse. Even children can use it without difficulty!"
The accompanying screenshot surely doesn't support that claim.
They want to sell you courses.
I was not sure if they were joking or if they were serious.
At least in Java there's a pretty clear mapping from packages and classes to folders and files. In PHP, the mapping is not so clear.
Edit: I'm not saying I agree with the author, I'm just pointing out one aspect.
IMO A child would only find it easy to use if they were already a seasoned coder. The IDE looks overly complicated.
what i like about it though, is not the IDE but the image based development:
that i can debug and fix an application while it is running. that, for certain classes of errors, i can pause an application (or it will pause by itself), and simply resume after fixing the error.
maybe 10 years ago, and certainly 20 or 30 years ago, smalltalk's IDE was ahead of its time. today, many alternatives exist.
but image based development is limited to very few platforms. only smalltalk, lisp and a few others offer that.
i also like that smalltalks syntax is incredibly minimalistic.
the downside is that smalltalk effectively requires you to forget all the tools you worked with before. but this is again, where pharo development makes its mark. it is now well integrated with git for example.
we all know that git has its issues and a learning curve, and many GUIs are trying to make git more accessible. pharo managed to integrate git in a way that it works well with the traditional smalltalk development style while at the same time allowing it to take advantage of the strengths that git has to offer.
greetings, eMBee.
Im my generation children used assembly language without any problems, and those who didn't have assemblers just worked out the hex codes on paper and POKEd them in and CALLed them.
There are advantages and disadvantages to image development and I usually don’t even take advantage of image based development in SBCL Common Lisp anymore: I usually have a load file to fetch data I will need and load in my code and required libraries. In the same way, I no longer keep multiple Pharo images around.
That said, it is a large world and you don’t need too many companies and individuals using a software technology to keep the ecosystem supported and moving forward.
I was also a big fan of my Xerox 1108 Lisp Machine, but that was mostly viable because Xerox had one large customer, the CIA. The CIA had a custom work environment for analysts that took advantage of the platform. In a similar way, I can see Pharo as potentially being an integration tool for knowledge workers with interfaces to external tools like MatplotLib and TensorFlow. A highly customized Pharo environment could be effective for organizations that could support a small team maintaining a custom analysis setup.
I'm still a fan of the bold moves eve¹ did.