This is really exciting - congratulations to the team and all the contributors.
For those who already know "what smalltalk is all about" but are looking to get into Pharo and get something done, I recommend Pharo by Example and Deep into Pharo - between those two books, any developer should be able to figure out the workflows Pharo expects you to employ to be productive.
My only advice would be to go in without preconceived notions based on your years of using other languages. And the community is super helpful.
It's a tall order. My observation with people with mastery, who switch to a new tool, is that usually: A- something external has forced the change, in which case it's hard for them to be patient/charitable. or B- they like their current tool, but have some ultra specific complaints that they hope the new tool will address whilst leaving the rest intact.
Basically, the common circumstances around these things leads to some biases.
I think one way to address this, is to simply be aware of ourselves. Another would be to ensure people use a large variety of tools early on in their education/career. The meta-skill of navigating to a new tool is something we get better at with practice.
The page seems to be going out of it's way to not mention the word "Smalltalk". Does anyone have an idea why that is? Does Smalltalk have such a bad reputation nowadays or has someone trademarked the term?
Maybe the most succinct explanation of what this means comes from their vision document[1]:
> What we want to say is that if there is something that can be improved but does not conform the ANSI Smalltalk, we will do it anyway.
This really does seem to be a fundamental value within the Pharo community, and it distinguishes them from the rest of the Smalltalk community. When observing the communities around Squeak or the commercial Smalltalks, I often get the impression that they view themselves as a sort of Jedi order that's trying to preserve an older, better tradition amidst a decadent modern world. The Pharo community, by contrast, actively acknowledges that Smalltalk was not perfect, and is working hard to improve many things about it, including some of the fundamentals. For example, Pharo's made active steps to make their platform more amenable to source control, and, by extension, collaboration among larger groups of people.
I know a buncha literal rocket scientists who swear by Smalltalk with a heavy bias toward the Squeak VM as bein' the best thing since sliced bread, but I honestly rarely hear about it outside those particular circles. Mostly I hear about Javascript, .NET/Mono, and Python in other programming language circles I frequent.
Smalltalk is just a simple meta-language (like Lisp and Forth). In your system, you may have the same or very similar syntax and keep some degree of compatibility but be very different in many practical aspects. For example, Pharo has Collections API very similar to Smalltalk but very different Files API or UI API. It has another class building strategy with stateful traits, slots, some syntax extensions, different source files format etc.
I've noticed that as well - it's a bit strange given that Pharo is a fork of Squeak, which does proclaim its ST origins on its front page.
I wouldn't say Smalltalk has a bad rep nowadays, but it used to be knocked for being too expensive (the cost of ST licences back when was beyond a joke), too slow, and producing nasty-looking non-native GUIs. These have almost all been fixed.
It has basically two reasons. First, it is to prevent conflicts like: "Pharo is Smalltalk, look, it is written on its web page! How do dare you to change this? You are allowed to improve this if and only if all the other Smalltalk implementations do that too!" [exaggerating]. Pharo has many differences from standard Smalltalk (different File API, class definitions, traits, slots, small grammar changes...).
The second reason is that the general knowledge about Smalltalk is very poor, and most people only remember that it is something old and long dead. Try to sell a dead fish.
Interesting, thank you. It still seems weird to me, though. I feel Smalltalk is mostly mentioned with positive connotations (as opposed to, say Cobol) and would guess more people have heard of Smalltalk than Pharo and it would help orientation. So I was assuming something nefarious :)
Is there an overview of the differences somewhere?
I sometimes ask young programmers or people interested in old computers if they know Smalltalk and what they think of it. Try it too, you might be surprised at the results.
I don't know of any such list of differences, and I don't think it's of much use either.There is ANSI Smalltalk, which is very limited and most implementations go well beyond its scope, so you have to compare each implementation separately anyway.
$199 was a very reasonable price for a powerful dev tool in 1988. A lot of software at the time cost much, much more. Look up historical prices for just about any contemporaneous commercial software.
You can still argue they would have done better in the long run by marketing themselves as "Turbo Smalltalk" at $69.99. But that's a different argument than "wow that's way overpriced," which simply wasn't the case.
Most tools were modified to use Spec framework so they can use the native look (using GTK) as well as the non-native one. (plus, in future, Web and Console backends). This transition should be finished in the next release.
"ParcPlace VisualWorks Smalltalk emulates all the supported operating systems GUIs in Smalltalk …
Digitalk (now ParcPlace) Visual Smalltalk uses more of the underlying operating system GUI, for better performance but at the price of only supporting a common subset of GUI controls …
IBM Smalltalk maps the Motif GUI widgets onto the underlying operating system widgets.This means you get a very rich kit to build your GUI, but the widgets operate at near native speed. You have the best of both worlds."
Maybe Smalltalk sounds old like COBOL. It's hard to re-kindle interest in old tech in the eyes of new devs. It seems every generation of programmers want to have their "own" tools, even if they're worse than the previous ones.
I always had positive connotations of Smalltalk. Seemed it was talked about as if it was OOP “done right” before Java messed things up. That’s just me though.
COBOL's big problem has always been verbosity rather than age. Fortran and Lisp are older yet both have a more positive image. Fortran and Lisp are each far more succinct languages than COBOL.
(Contemporary Fortran and Lisp have evolved a lot since their initial version, but the same is true of COBOL.)
C never really fell out of favor, though. And it's also the only available choice apart from assembler in many circumstances. But trying to revive interest in Ada, D, Sather, Prolog, etc would be a lot more difficult.
It was already out of favour in the early 80's, hence C.A.Hoare turing award speech against it in 1980, but then UNIX took over the world anyway, and the FOSS wave with GNU Manifesto helped to take it further.
Apparently people don't have any issue hanging to an OS about the same age as COBOL.
>"Apparently people don't have any issue hanging to an OS about the same age as COBOL."
Why should they? It works for many cases and has mountains of apps, tooling, libraries, hardware support and whatnot. It takes decades for the new OS/ecosystem to mature.
Equating OS and its ecosystem to a single language is not very wise approach I think. In any ways you are obviously free to find fresh and shiny OS of your liking and use it.
It surely is, UNIX and C are a symbiotic relationship, born out of each other, one in 1969, the other in 1972.
I surely have, hence why I have gone back to Windows, where the focus is C++ and .NET, macOS where the focus is Objective-C and Swift (UNIX is there for historical reasons only), Android where the focus are Java/Kotlin and C++ (with Linux kernel being an implementation detail).
UNIX is not a thing anymore, nobody writes UNIX code. People use various compatibility layer or straight up use kernel abis. And they are all improving over time. So no they are not all stuck in 80s. Even linux kernel devs are willing to add rust code in the mix.
> Windows, where the focus is C++ and .NET,
Microsoft is huge organization they have multiple focuses. You seem to be mixing the kernel/userland layer and making very weird argument against UNIX(that nobody uses).
I am not familiar with COBOL is there any effort to improve COBOL?
For me it is Windows desktop and Linux servers. So far I had no business case to develop for other mobile and somehow do not feel sorry for it as I am in no rush to bend over to things like approval from App stores etc.
From 1980 to the late 80s or so people were struggling just to get Smalltalk to perform at reasonable speeds on microcomputer class hardware, so saying 1980 isn't really fair. And most of the research that went into getting Smalltalk (and Self) to perform well on those platforms was then used to get Java to perform.
In actuality, Smalltalk gave Java a headstart.
That said, Smalltalk just doesn't in general "play well with others"; its image based development environment, especially.
>people were struggling just to get Smalltalk to perform at reasonable speeds on microcomputer class hardware
I've heard this before, but it confuses me as apparently the majority of the systems at Xerox Parc (Window manager, word processor, etc. ) were written in Smalltalk. So how could these sophisticated GUI apps perform there but not on other platforms, was the hardware really so different?
Yes, they were drastically different. Xerox built their own systems. Look up the Dolphin and Alto, they were basically minicomputer-class systems with custom CPUs built out of 74 series and bitslice components, no single-chip microprocessor. And very expensive.
It wasn't until the mid to late 80s that microprocessor systems built around the 68k series were able to run Smalltalk 80 well. And that was with Tektronix and others spending thousands of man hours developing techniques to implement the VM well. And many of those systems were still basically dedicated to Smalltalk and cost a fortune.
The simple answer to this question is that not all software at Xerox PARC was written in Smalltalk. In fact, Smalltalk was just one out of a few different languages and programming environments that Xerox PARC used. For example, the Bravo word processor was written in BCPL (https://en.wikipedia.org/wiki/Bravo_(software)). Mesa was also developed at Xerox PARC and was commonly used as an implementation language. Interlisp was also largely developed at Xerox PARC.
This is not true. Even the Smalltalk-80 Blue Book wasn't released until 1983.
> If you can't build adoption with a 15+ year head start
Historical context is important here. FOSS etc were not nearly as prevalent as they are now, and most major development environments had a price. The main Smalltalk players probably got it wrong by pricing out expensive licensing fees. But the head start does not matter when the next thing that comes along is released for free, which is what happened with Java.
There was also the issue of "viral pricing". As the application was grown as a extension of the image, people were supposed in some schemes to not only pay for their own copy, but also for every copy of the software they wrote and shipped to customers, as it piggybacked on the original image. While free software thrived on copyleft, the first Smalltalks withered on "payleft".
Java was able to ride the wave of the web's rise in popularity, particularly with their marketing of applets and the "network as the computer", with the idea of downloading Java code as needed to supplement the software you're using at the time. That and there was lots of talk about how the JVM was going to be the runtime of the future for all languages.
It's funny how Javascript and the web have turned out to be a more popular target. Nobody back in the late 90s/early 2000s would have thought that. JS was a toy and html was going away in favor of Flash or Java applets or .NET.
At any rate, timing is a really important part of gaining widespread adoption. Smalltalk was way ahead of its time in the 70s, but too early to really take advantage of networking, as their target was stand-alone personal computers.
Actually language developers consistently underestimate the importance of large corporations pushing languages no matter what developers think about them.
> VisualAge Micro Edition, which supports development of embedded Java applications and cross system development, is a reimplementation of the IDE in Java. This version of VisualAge morphed into the Eclipse Framework.
It's true, and a huge point. Until Squeak came along I as a hobbyist -- who was really interested in Smaltalk -- simply couldn't get my hands on a Smalltalk (other than GNU Smalltalk which doesn't count). All through the 80s and early 90s I salivated at screenshots and descriptions of it, but never got to play with it.
That said, When I did finally get Squeak, I found it pretty neat, but it just never blew me away like I thought it would. I just didn't have anything to do with it.
It's more accurate to say it hadn't really come alive yet.
But still as late as 96, 97, 98 you could still find job postings advertising for Smalltalk developers. I know, because early-20s me really wanted to do be doing that, but I wasn't qualified.
Within a few years Smalltalk had vanished from the few industry pockets it had, and was replaced by Java in most cases.
Fun fact: I know one company in Russia which built aerospace-grade product in Smalltalk as late as 2010s. I don't know, maybe they still use it right now, maybe it had been replaced, all my friends in this company changed job in last 10 years.
AFAICT the big benefit of Pharo is on-the-fly introspection and the tooling to support dynamic introspection.
quick q: I can see the benefit for creating developer tools like the IDE and maybe for creating domain specific languages (DSLs)... but what "regular" applications benefit from this?
in particular, I can see (widespread use of...) introspection making it difficult for a developer of one large Pharo codebase to understand and maintain a different Pharo codebase...
also, Python has (arguably) "good enough" introspection and DSL support and mindshare/marketshare of millions of developers. When is python not good enough?
There are a lot of cases where good enough is actually good enough. Python, Java, C#, Go, TypeScript, they are not 'pure enough' to 'too OOP' for some, but at the end of they day, they are good enough to realise the potential that the business process they support requires.
It depends one's lifestyle. I have my own company and work from home for 20 years already. So the PCs with the big 4K screens are always around. When I go to my summer's office it is the same thing. So I read/watch videos from the PC.
Yes there were few situations when I knew I'd sit in a car and wait for someone for quite a while. So I downloaded book on laptop and read it. I tried reading from a smartphone but my brain simply can not digest properly from this size of a screen. When I read I follow the line but I also glance at the whole page. Not sure why but this is how it works for me.
Nothing rare about most of these features as they came from Squeak. What's really rare is how slimy they're being in at least implying most of these features are unique to Pharo in their marketing of it. There is not a single mention of Squeak or Smalltalk, which their project is derived from[1], on the page. It's unfortunate as they have put a lot of effort in expanding on the previous work and created a nice UI to make the environment more productive and accessible which they can legitimately take credit for.
[1] I don't mean 'inspired by', they literally started off with a fork of the code of both the VM and image. This is perfectly legit per the license, but it's hardly a completely original work.
Just a heads up the pharolauncher does not seem to be working for me, at least for pharo 9. Manual download of vm + image 64bit works but 32 bit does not.
I have been making pharo raylib bindings and plan to make a video soon about why Smalltalk is an interesting choice for game development, it's a very 'live-coding' feel, i.e. you run your game while the editor is still live, you have free reign to at any time modify the methods of all game objects, execute random code, etc. without restarting the game...
Yeah, the more usual wording is "given a free rein", which makes it a little clearer. A monarch isn't given their reign, it's theirs by right (well, with a bit of hand-waving. Or possibly sword-waving, but not since Henry VII).
James II entertained the same delusions as Charles of being absolute monarch. He had a kinder fate, being carefully allowed to escape twice on his journey to France.
Giving 'free rein' comes from the pragmatic practice of allowing a horse to chose the best path over difficult terrain on the grounds that the animal would know better than the rider.
A few years ago i was actually considering making a Smalltalk "dialect" (which i called Gametalk :-P) just for gamedev - some modern engines remind me a lot of Smalltalk in how they work, but they obviously stop at the resource editing level. So i thought that making the entire thing "live" and in itself would be the next obvious step.
(the reason i decided for a dialect is that modern Smalltalks carry a TON of baggage they collected over the decades - sure the language is tiny but they carry more objects than a transatlantic freighter :-P - and i wanted something lean with only the stuff i needed)
I never went beyond the prototyping phase but probably will pick the project up again if i end up getting annoyed by my current language and framework choices :-P.
Yeah i've seen Cuis at the past, it is certainly a leaner Smalltalk compared to Pharo (though TBH i am not a fan of Squeak's UI). If nothing else it can serve as inspiration.
Also now that i think about it, Cuis might be a good Smalltalk environment for starting out or learning about the language in general since i always get the feeling that the more feature packed dialects like Pharo are a bit intimidating.
Juan has done some really impressive work on Morphic3, which uses a vector graphics engine of his own design. He's also pared down Cuis' version of Morphic to its most basic elements, so one could change the appearance of the UI to whatever, theoretically
there was a problem with the PhL, that took more time to update of what we thought. Now it should be working... but please take into account that 32bit versions are deprecated (unless you're working on ARM)
It turns out to be the capital 'X' in X86 that is the problem. The same URL but with a lowercase 'x' works fine. Presumably someone in the Pharo team need to fix whatever image metadata the Pharo launcher is working from.
Are you on macOS? I installed Pharo 9 yesterday and had to use the command line install method. The Pharo Launcher puts images and other files in ~/Documents which I find problematic. I created a folder ~/Pharo, cc’d to it, and ran the curl command line installation option.
I wish that there were a Common Lisp with a Pharo like UI, like my old Lisp Machine.
Are there any good general examples for Pharo in the wild?
I've seen it a few times in some niche industries used as a replacement for Visual Basic or some proprietary 4GL stack.
And, frankly, this just reinforces my overall opinion of Pharo. Pharo is really amazing, they've been working on it, actively, forever, and make great strides.
But I'm convinced that Pharo is an amazing development environment and eco-system designed to make amazing development environments and eco-systems. All of the folks are putting work in to improving IDE to make a better IDE.
They're on their, what, fourth(?) iteration of the "widget" set that folks still find difficult to use and under documented. As recently as Pharo 7, when I last looked in any depth to the matter, their rendering model is straight out of the 80s. Vastly less capable than Java2D or Canvas in the browser. It's my understanding it's on their todo list, but I don't know how far they've advanced on this.
What focus there is on applications seems to mostly come from Seaside, the web server application framework.
If you look at their "success" page, most (not all) are web apps.
It would not surprise if someone, somewhere, is fusing Pharo and some Electron-esque rendering front end and using it to create a "desktop application".
And it's not unreasonable to say "Well, web is where it is, desktop is dead." There's certainly arguments in that direction.
In the end, it's moot. The devs have their itches to scratch. Nature of the game. Their itches are not my itches, and an "advanced" rendering model and modern widget set is something I want to use, not write. So, I'm at their mercy waiting for whenever that day may, if ever, come.
If was interested in writing IDEs, then perhaps Pharo would be a place for me. Instead I'm interested in writing hobby desktop apps, and it's not there yet.
There is certainly some truth to what you say. Threading is... just not (afaik it's a sort of green-threads thing) and UI is, as you point out, a crapshoot. However... ;)
If I'm going to write code for my own amusement, I want to work in Smalltalk and a Smalltalk environment. Ever since I first encountered it in the early 1980s, it's been my environment of choice. IMHO there's still no other programming environment that approaches the flexibility, liveness, debuggability, white-boxness of Smalltalk. To paraphrase Guy Steele, "All languages will evolve until they become Smalltalk". (Steele said something of the sort about Lisp.) That said, and jokes aside...
Where Smalltalk beats every other language environment I've ever worked with or seen is at exploratory programming: Programming where you don't quite understand the problem, the domain and/or the solution space. It's more a tool for thinking about problems and how to solve them than something for a fixed, final answer. I suggest, further, that a very great deal of software development is exploratory in nature, so using a Smalltalk is a win, at least until you've understood everything in sufficient depth to "just implement a solution". At that point go to something with better runtime performance, deployability, etc. by all means. Caveat being that sometimes (quite often, really) the exploration never, ever reaches a conclusive terminus, so you may want to stick with a Smalltalk.
tl;dr: Use Smalltalk to explore and understand, and then finally to deliver an executable, test-driven specification.
That IDE looks amazing, but it looks like I'd need to be proficient in Smalltalk to use it for any language. Watching the video on the site and it's impressive what the presenter is doing with live representations of code.
I've often heard two statements online from older programmers.
"Delphi/TurboPascal was the peak of developer productivity"
And
"Smalltalk was the peak of developer productivity"
I've only been programming about a decade so both of those languages were long before my time.
Can anyone who has experience programming in Smalltalk share what was so special about it/what made it so productive to write programs in versus other languages?
It seems like this unique playground-VM thing makes it sort of unwieldy for non-graphical tools. IE can you use it for scripting tasks system, or for writing networked applications?
There must be something unique about Smalltalk for so many of it's developers to reminisce about it and claim it's been unparalleled since.
I haven't used it much myself, but I've watched a lot of Alan Kay videos and I've read his "Early History of Smalltalk" which I highly recommend. My take is that it is largely about creating a computing system from the smallest yet most fundamental/powerful building blocks. In smalltalk, "everything is an object", which means everything has the semantics of a "whole computer". These computers are networked together and can send/receive messages back and forth with each other. This creates a drastically different paradigm than simply creating a pipeline of functions to send data through (for example). It excels at modeling complex systems, it's really "OOP done right".
Of course there are other interesting features worth talking about, such as "images" and the introspection capabilities. Which are both great and often sorely missed in todays systems. But I think the big idea is to try to understand what Kay had in mind with OOP.
Another aspect of smalltalk that is important, beyond just the "language" is to recognize its role in advancing "personal computing". Smalltalk was essentially an operating system that empowered the user to create new media and tinker with the system.
If you want to see a modern web-browser based smalltalk-like system that uses javascript, check out Dan Ingalls' Lively Web. That will give you an idea into how smalltalk systems were meant to be used, in terms of "personal computing".
The bit towards the end (around 5 min mark I believe) where he gives the IDE (is that what you call it?) an input + desired output and asks it what message would produce the result he wants is pretty damn cool.
The rest of it is "interesting" I suppose. I can imagine that, at the time, this sort of interactive/live visual environment was revolutionary. This would be 1972-1990's I think, and during those early years there was nothing even remotely similar, right?
Towards the end Rapid Application Development (RAD) IDE's would start taking hold and then came the Pascal-powered heydays for a bit.
I think that maybe just due to familiarity bias, I still prefer a text-based IDE which has hot-reloading and live eval results.
Something pretty neat I use personally is an extension called "Quokka" which places the results of each line next to them, live as you edit (similar to a REPL)
Jetbrains IDE's have a similar thing with "Worksheets" for languages like Kotlin, Python, Scala, and likely a few others. (Also "Metals" extension in VS Code can do this for Scala incredibly well)
Speaking as someone who had experience programming in Smalltalk in its heyday, it had at least as many downsides as upsides and those who claim it was a peak are either looking at it through rose-tinted nostalgia or are Alan Kay.
One favorite advantage was that as much as possible of the system was written in itself and the development environment was an integral component. Any developer could see and change anything. The approach was that you took the Smalltalk system and built your application as an extension onto it. "Playground-VM" is a pretty good description.
Unwieldy? Not if you bought into it entirely, in roughly the same way that certain people I know bought into Emacs: Use it as your login shell and do everything through it. It was bad for creating stand-alone programs or scripts; instead, you add objects and methods to do whatever you wanted to do today.
Nevertheless, as the front page the the Benchmarks Game is careful to mention, benchmark performance is 1) not necessarily representative of real-world performance and 2) not even always important in the greater context!
Still, it's sad that Smalltalk & company haven't received the VM optimization attention that JS has. What would our world look like if Brendan Eich had gone for Smalltalk instead of creating a language from scratch?
> Still, it's sad that Smalltalk & company haven't received the VM optimization attention that JS has.
Well...if you consider that the heritage of V8 in Node.js kind of goes back to StrongTalk, I'd say Smalltalk has received more of it than perhaps many people think. Unfortunately StrongTalk didn't really succeed on the market for the same reasons as many other Smalltalk implementations - proprietary nature and exclusivity doesn't really help you in the long run against worse-but-cheaper-and-more-accessible solutions.
Those benchmarks are quite old, from Pharo 5 in 2017. It would be interesting to see a updated version. Eliot Miranda and Clément Béra are working on speculative inlining for the JIT compiler. From http://www.mirandabanda.org/cogblog/about-cog/ - "With Clément Béra I’m working on adaptive optimisation (a.k.a. speculative inlining) at the image level, optimising from bytecode to bytecode. We call this project Sista, which stands for Speculative Inlining Smalltalk Architecture. Clément’s image-level (entirely in Smalltalk above the virtual machine) adaptive optimizer is called Scorch. Sista should offer about a -66% speed-up (3x) for conventional Smalltalk code. The combination of Spur and Sista should yield almost a 5x speedup over the original Cog."
I'm sorry. You're right. I did a stupid mistake by confounding the vm version with Pharo version. I can't edit my post anymore, but please, anyone reading this, disregard the "Those benchmarks are quite old, from Pharo 5 in 2017" part.
This looks like an amazing environment and interesting language. The first thing I thought of was a version of Croquet [1] using Pharo. Another thing it reminds me a bit of is HyperCard.
Thank you very much for explaining what Pharo is in one sentence on the linked page. Seriously, other projects and submissions should take notice because the general attitude is as if everybody knew exactly what your project is and what can be used for.
Is a generic purpose language, and there are generic usages, and a lot of examples :)
But here you have a huge SaaS made with Pharo: https://yesplan.be/en, and here you have a small mobile app made also with Pharo: https://plc3000.com
[edit] technically is not a mobile app, but runs in any browser so... yes :P
weird, it loads correctly for me.
Yes, a bunch of companies (some of them very important in their fields) are backing Pharo... but Pharo is a community effort, made by hundreds of people.
It seems like the code/system browser has essentially stayed the same since Smalltalk-80. See Figure 17.11 on page 298 (PDF page 320) of the blue book [1]. I've often wondered about "modernizing" it, or at least exploring other options for interacting with the source. Have there been attempts at this? This is pretty far down on my list of things to fund even if I were to win the lottery some day. But I like to think about it anyway.
There was a lot of attempts, Glamorous Toolkit is exploring one alternative approach now. But the basic concept seems to be very solid. Think of the code base as the fractal system you want to explore. Then the browser provides several well-placed views with increasing zoom levels. It is hard to beat it. When you explore, for example, senders of a given message, you jump to another position in the fractal that conceptually looks similar. And you need to keep track to do not lose orientation. Exploring a classical source file is like moving in fractal on a fixed zoom level.
I remember while learning Smalltalk how surprised I was when if statements and loops weren’t syntax of the language, but methods on objects. True and False are singletons of a Boolean class, which has a method ifTrue:ifFalse which take lambdas as arguments. For loops, a lambda which returns True or False has a method whileTrue: which takes a lambda as an argument.
Although I like Python, and I don’t know JS well, I really enjoyed learning Smalltalk, even though I will likely never use it professionally.
JS is for me clean and comfortable, sometimes more than C# and for some others Python is, and everyone has their own answer to "what makes them so".
Everything being an object may do the trick for you or not. I don't mind a marketing page (even for a programming language) being opinionated, as long as not borderline delusional.
True, but personally I think JS and Python would have benefitted from being more consistent about being object based. JS in particular, since it's prototypal, but has function constructors and class syntax, along with other things added over time that make the language more complex.
Yes and the comment I replied to vaguely suggested that it didn't make python and js comfortable to learn and everyone focused on the fact that in these languages not everything is an object.
Apparently everyone keeps forgetting that after the new class type declarations were introduced and the primitive types made subclasses of them, everything in Python is an object as well.
For example, in Python, are activation records objects you can manipulate? Seaside uses this in Smalltalk to implement continuations. If not, then not everything is an object in Python.
There were "perceived shortcomings" although Smalltalk use seems to have grown in the decade following.
IBM taught "object-oriented software technology to experienced procedural programmers" and studied that experience — 'We read and heard many stories about confident and experienced programmers' plunging into self-study tutorials, only to give up in frustration after several hours, still wondering, "Where is the application code?"
… New programmers often became lost in the hierarchy or spent considerable time in unfocused exploration of the interactive tools.'
Technical shortcomings, September 1988 — "… currently unrealistic to expect that an excellent rapid prototyping system can also be an excellent application delivery system."
To really take advantage of its strengths, one needs to adopt to a completely new IDE and way of working, which puts a lot of people off.
On the other hand, if it were adopted to behave like all other environments, there would be objections again, "It's exactly the same as what I'm using now. So why switch?"
It should be added that Pharo addressed most of the small problems that the original Smalltalk had.
So, Smalltalk is radically different from other programming languages, and has a very different vision for what it means to program.
Imagine that you download the binary for the programming language, and then you don't know what to do with it so you double click it or try to execute it from the shell, and you are very surprised to see a window open up, showing something looking like a blank desktop.
What is this? You go off to read some tutorials, they show you some ways to click inside the window and so forth.
It slowly dawns on you: this is your program. It is running as we speak. You are livecoding it, those button clicks are mutating it to do new things. The reason it's not doing anything is you haven't written it yet, and it's inviting you to, and when you do it'll recompile and show you the new thing instantly.
So your programming languages have always been designed like a circuit board or a 3D printing rig. Lots of files of blueprints, and then the robots will assemble it for you. Smalltalk is different, the mental model is more like clay or Lego, the thing is already built and running in front of you, what are you going to mold it into being?
This different vision means that usually you are editing text not from vim or emacs or VS Code, but from the editing widgets inside of the programming language. Those are part of the clay, and are editable too. Similarly, Smalltalk version control was typically exposed inside of the running system rather than outside.
My favorite example of this, the thing that is maybe the most outrageous if you're in a normal programming language, is Object.become().
This is a runtime dependency injector. “I want to instruct the programming language to take all of the traffic that it was sending to that object, and send it to me instead. I will become that object.” If you are used to Java where my constructor instantiates some dependency object and I save it to a private variable in this object, surely you see this as a safety violation. “What do you mean, that anybody who gets a reference to this object can tear it out of my private property and replace it with some other subclass? I made it private so I could control when that field gets set! How dare you?” It’s not, of course.
And this is available for every object in the system, which is why you can do this modeling by clay. They tried to write as much of Smalltalk as possible in Smalltalk and so you can just see the source code of the programming language in the source code browsers that you can call up from this window, and you can live edit any of that, and Smalltalk will compile your new object and swap it into where the built-in object was.
Put a different way, it's not a safety violation because this is how modern development with microservices and kubernetes actually works. Security is people's ability to surprise you, measured in dollars: part of this definition is, Smalltalk developers are not surprised by their ability to do this. Every “object” is thought of as a separate server with an API, and of course I will replace old servers with new ones and tell the load balancer to send traffic my way.
Pharo, like its siblings Cuis, Squeak, and NewSpeak runs on a VM called Open Smalltalk. It is written in a stylized version of Smalltalk so can be debugged with the tandard Smalltalk tools (i.e. you can have the modified VM you're working on load and run an image - but your VM is running in a debugger!)
Then when you're happy with your revised VM, you can spit out portable C code, compile it, and BAM you've got a production VM! Most plug-ins and primitives are also written in the Smalltalk subset (called SLANG), so they will likely be similarly portable.
There is also an FFI for interfacing beyond the standard model.
For example, Pharo github repo doesn't have any C code at all, and to build it I need Pharo VM already running. It is Ok for building new version for existing platform, but what should I do if I want to build VM for other platform (OS)? Hardware platform is supported already, so, I think, I don't need to have new assembler / JIT / Whatever, but I need new glue to new libc, kernel, etc., and new executable file format, am I right?
Purely object oriented languages did fall out of fashion lately. While the environment looks sophisticated, I have the feeling I would bet on a limping horse?
Personally I do not give a flying hoot about fashion. The only thing that matters to me is how one particular tool helps me to make what I want. I've never "bet" on any tech. To me those are just tools. Nothing to get excited about.
I think OO has fallen out of fashion because there's a perception it can more easily lead to confusing code. While one can write confusing code using FP, it's not as easy to do.
I really do not care why is something in fashion / not. There are many software paradigms and one simply has to know which one is the best for particular situation. Trying to bring everything down to a "there can be only one" level is not very wise. Unfortunately for some reasons many programmers get really religious about language / framework / paradigm / whatever.
Also writing confusing code is incredibly easy in any language / paradigm. One just has to be inexperienced thinker.
Yet all major GUI frameworks are OO, even component based ones if one would actually bother to read OO CS literature, before announcing them as some magic solution.
> While one can write confusing code using FP, it's not as easy to do.
Yes, it is.
It is in some situations easier to write non-confusing code in FP (though in other situations its easier in OO.)
Also, OO hasn’t really “fallen out of fashion”, its still, AFAIK, the dominant paradigm. It’s just not as hyperdominant as it was from the mid-90s through the -00s.
It could be the priorities of these unpaid volunteers that you are not paying for do not align with yours. I’m sure they would invite you to contribute your improvements.
Snarky? No. It's open source. If it doesn't have feature <X> then you're free to add it. It can simultaneously be the most important feature for you, and entirely irrelevant to other contributors. You're not prevented from adding it, as you would be in a closed source product.
I'm sure you know all that but it bears refreshing. This is software that's free to use and free to modify. If you've an itch then you're at liberty to scratch it - just as other contributors are equally at liberty not to.
There is a GTK3 backend now, hopefully that should make HiDPI work, support Wayland, etc. – depending on how it's implemented of course.
Doesn't look like it's ready to handle all the UI (?) though – in the promo screenshot there's one GTK window on top of a more classic Pharo window (?)
it doesn't yet support the whole IDE (because it has some other complications, we will solve in next release), but it supports application development with it.
It's the MVP of native GUIs. Should a purely-Win32-based UI arrive later, the additional work would at least be validated and trailblazed by the first Gtk implementation. You can't expect a small set of people do everything at once just because you want them to.
Actually they do. A relatively cheap 13" laptop with a Full-HD screen is already considered HighDPI by Windows 10, where it uses a default of 125% scaling (or maybe 150%, not sure). Applications not supporting HighDPI (aka Retina) properly will likely have a relatively bad appearance (blurry icons, possibly blurry fonts, etc.). Even some integrated Windows features (hardware manager, to name one) have this problem... :-(
Blurry is one thing, I get teeny tiny mouse cursors too that I just can't find half the time. Incredibly annoying, especially when it's inconsistent within the same application.
There isn't a proper definition for HiDPI. Displays used to be around 100ppi.
Nowdays, the majority of notebooks - even cheap ones - feature a FullHD display.
For example when i list all notebooks on gh.de and limit the maximum price to 600€ of the 599 listed laptops 389 of them have a pixel density of 150ppi or higher.
For a price up to 500€ it lists 306 laptops with 176 having 150+ppi.
But not real HiDPI. AFAIK Windows 10 just treats FullHD (1080p) as HiDPI and scales everything up to 125% by default but I always switch it back to 100% so I have reasonable screen space capacity. If the 13-inch displays were 4K that would be HiDPI.
Ok, if it would be 2560 vertically on a 13" screen that's fair to consider it HiDPI but for 1280p on 15" this is questionable yet Windows does just this.I understand this is good for the vendors (who can claim they are selling you HiDPI - FullHD doesn't sound impressive enough anymore) and visually impaired people (that's actually great they are treated as the primary audience now). Perhaps this also is good as some sort of transition period so the technology gets introduced gradually while the screens still are not too dense and non-aware apps don't just become unusable instantly.
Ok, I thought we were talking about vertical an included the p specifically to disambiguate this. Practically 1080p just means 1920×1080 unambiguously (I know what does the p actually mean).
It doesn't help that some laptops are 16:9 and some 16:10 so the vertical numbers get even more mushy.
Anyway, my point was that even though "4K" as a concept has good mindshare, that's overkill even for a True Retina(tm) experience in the typical OSes on a 13". Around 100 DPI is what those UIs were foundationally designed for (starting in the 1990s) and all numbers unfold from that decision.
Traditionally we had 85-100ppi monitors for example
* 15 inches 1024x768 (85ppi)
* 17 inches 1280x1024 (96ppi)
* 19 inches 1400x1050 (92ppi)
I'd argue that everything that is beyond ~140ppi needs adjustments in software and could be considered HiDPI. You could also argue that 200% scaling should be the threshold, if we're starting with 85ppi that would be 170ppi.
It also depends on the viewer distance of course. Larger displays are usually viewed from a bigger distance.
Yes, for bigger distances this makes a lot of sense.
I want everything be as small as possible to fit more when I'm using my laptop but I would really appreciate decent unscaling on my RaspberryPi i use siting on the couch in about 3 meters from a 42-inch 1080p panel.
For those who already know "what smalltalk is all about" but are looking to get into Pharo and get something done, I recommend Pharo by Example and Deep into Pharo - between those two books, any developer should be able to figure out the workflows Pharo expects you to employ to be productive.
My only advice would be to go in without preconceived notions based on your years of using other languages. And the community is super helpful.