Pharo 9(pharo.org)
pharo.org
Pharo 9
https://pharo.org/news/pharo9-released.html
231 comments
> 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.
Honestly, if more people went into every language with that mindset, there'd be a lot less bickering and problem a lot more getting done in the world.
Honestly, if more people went into every language with that mindset, there'd be a lot less bickering and problem a lot more getting done in the world.
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.
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.
Great talk by deech on Pharo: https://www.youtube.com/watch?v=baxtyeFVn3w
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?
Pharo considers itself to be Smalltalk-inspired.
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.
[1]: https://gforge.inria.fr/frs/download.php/30434/PharoVision.p...
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.
[1]: https://gforge.inria.fr/frs/download.php/30434/PharoVision.p...
It follows Kay's advice:
https://pbs.twimg.com/media/EMJoLicXsAA7dej?format=jpg&name=...
https://pbs.twimg.com/media/EMJoLicXsAA7dej?format=jpg&name=...
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.
I guess maybe because Pharo has moved beyond Smalltalk-80, and is its own thing nowadays, just like Raket is no longer just Scheme.
But the language itself is still Smalltalk with some extra classes, right?
Kind of. At the very least you get traits, dynamic array literals and such that you don't get in "classic" Smalltalk.
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.
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.
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?
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.
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.
> cost of ST licences back when was beyond a joke
March 7, 1988
"Smalltalk/V 286 is available now and costs $199.95"
https://books.google.com/books?id=CD8EAAAAMBAJ&pg=PA25&lpg=P...
> nasty-looking non-native GUIs
The "non-native GUI" was quite important because Smalltalk was running on MS-DOS — not on MS-Windows.
March 7, 1988
"Smalltalk/V 286 is available now and costs $199.95"
https://books.google.com/books?id=CD8EAAAAMBAJ&pg=PA25&lpg=P...
> nasty-looking non-native GUIs
The "non-native GUI" was quite important because Smalltalk was running on MS-DOS — not on MS-Windows.
Well $200 in 1980s is something like $500 today. I don't think I own any piece of software costing that much.
That seems like an ahistorical objection.
$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.
$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.
"The list price is $150 each for Turbo Pascal, Turbo C, and for a bundle containing both Turbo Assembler and Turbo Debugger."
p8 October 1988 https://books.google.com/books?id=WSBVAAAAMAAJ&pg=RA18-PA8
Smalltalk/V 286 included source-code debugger, bit mapped WIMP for MS-DOS, BitBlt graphics, … Turbo Pascal + debugger already cost more.
p8 October 1988 https://books.google.com/books?id=WSBVAAAAMAAJ&pg=RA18-PA8
Smalltalk/V 286 included source-code debugger, bit mapped WIMP for MS-DOS, BitBlt graphics, … Turbo Pascal + debugger already cost more.
Adobe products can cost that much on a yearly basis.
And … ?
Dec 1988, MS Word 5.0 for MS-DOS, $450.
Dec 1988, MS Word 5.0 for MS-DOS, $450.
The animated screenshots on the website pretty much indicate that the Pharo GUI is still non native and looking very dated and ugly.
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.
hm, does Pharo have native-looking GUI now?
Well, let's say "better" :-) There was a Smalltalk with a native Windows GUI (Dolphin) but the developers couldn't seem to make any money out if it.
"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."
p87 "VisualAge for Smalltalk" 1997
http://www.redbooks.ibm.com/redbooks/4instantiations/sg24482...
aka What's the difference between Swing and SWT,
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."
p87 "VisualAge for Smalltalk" 1997
http://www.redbooks.ibm.com/redbooks/4instantiations/sg24482...
aka What's the difference between Swing and SWT,
see this thread: https://news.ycombinator.com/item?id=27843214
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.)
(Contemporary Fortran and Lisp have evolved a lot since their initial version, but the same is true of COBOL.)
You mean like C, born in 1972?
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.
>"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.
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.
Same conclusion can be applied to COBOL applications.
https://www.microfocus.com/en-us/products/visual-cobol/overv...
https://www.microfocus.com/en-us/products/visual-cobol/overv...
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).
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?
> 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.
Smalltalk never really got substantial adoption...
Thanks Java :(
Smalltalk first appeared in 1972, and was a stable commercial product by 1980.
Java didn't hit the market until over a decade and a half later.
If you can't build adoption with a 15+ year head start, then it's not the next generation's fault. It just wasn't going to happen.
Java didn't hit the market until over a decade and a half later.
If you can't build adoption with a 15+ year head start, then it's not the next generation's fault. It just wasn't going to happen.
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.
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?
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.
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.
[deleted]
> stable commercial product by 1980
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.
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".
Wouldn't that be payleftandright? ;)
Except it was happening, that is why gang of four book uses C++ and Smalltalk on their examples.
Had IBM kept selling Visual Age products instead of jumping into Java ship, history would have turned out much differently.
Or if the Strongtalk guys hadn't return back to Sun and basically turn a Smalltalk VM into a Java one.
JUnit was also born in Smalltalk for those not paying attention.
Had IBM kept selling Visual Age products instead of jumping into Java ship, history would have turned out much differently.
Or if the Strongtalk guys hadn't return back to Sun and basically turn a Smalltalk VM into a Java one.
JUnit was also born in Smalltalk for those not paying attention.
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.
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.
> … too early to really take advantage of networking…
So how do you explain "HP Distributed Smalltalk" ? :-)
https://www.hpl.hp.com/hpjournal/95apr/apr95a11.pdf
How do you explain "Gemstone/S" ?
https://gemtalksystems.com/products/gs64/
So how do you explain "HP Distributed Smalltalk" ? :-)
https://www.hpl.hp.com/hpjournal/95apr/apr95a11.pdf
How do you explain "Gemstone/S" ?
https://gemtalksystems.com/products/gs64/
language developers consistently underestimate the importance of "Algol-like syntax" in allowing mainstream adoption.
Actually language developers consistently underestimate the importance of large corporations pushing languages no matter what developers think about them.
Smalltalk lost the day IBM decided to join Sun.
https://en.wikipedia.org/wiki/VisualAge
> 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.
Smalltalk lost the day IBM decided to join Sun.
https://en.wikipedia.org/wiki/VisualAge
> 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.
some reading from that era: https://techmonitor.ai/technology/the_parcplace_digitalk_mer...
Java was free and open source and based on files rather than an image.
Free as in "free beer", but not open source until much, much later.
Interestingly enough the JVM hotspot compiler was done by Smalltalkers (checkout Strongtalk)
Interestingly enough the JVM hotspot compiler was done by Smalltalkers (checkout Strongtalk)
Java was free. (And marketed by a large organization.)
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.
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.
Java was an answer to C++, not to Smalltalk, which had already been dead for a while by the time Java started taking off.
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.
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.
"Ubiquitous Applications: Embedded Systems to Mainframe" (pdf)
https://www.davethomas.net/papers/ubiquitous1995.pdf
https://www.davethomas.net/papers/ubiquitous1995.pdf
Check out https://consortium.pharo.org/ - you will see:
"A clean, innovative, open-source, Smalltalk-inspired environment."
"A clean, innovative, open-source, Smalltalk-inspired environment."
If you look at the home page for Racket, you won't see the word "Scheme" anywhere.
Same thing, basically: neither language wants to be beholden to what's come before, nor to their peers.
Same thing, basically: neither language wants to be beholden to what's come before, nor to their peers.
It is mostly marketing bullshit.
Pharo IS Smalltalk in the same way Skoda is Volkswagen
Pharo IS Smalltalk in the same way Skoda is Volkswagen
This is a long list of rare features that make Pharo interesting:
https://pharo.org/features
https://pharo.org/features
I don't know if it's my eyesight declining but that postcard is hard to read. Wikipedia has a svg file with higher resolutions: https://en.wikipedia.org/wiki/File:Pharo_syntax_postcard.svg
Well, the light gray on white background has horrible contrast. I think that'd give most people trouble.
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?
(asking innocently - please don't shoot)
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?
(asking innocently - please don't shoot)
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.
> introspection and the tooling to support dynamic introspection (...) what "regular" applications benefit from this?
Ever use developer tools in the web browser? Do you imagine they make Gmail harder or easier to debug and maintain?
Ever use developer tools in the web browser? Do you imagine they make Gmail harder or easier to debug and maintain?
What is also rare is the quality of the site. Impressive.
Unless you’re on mobile…
For people who are actively using their smartphones for many tasks. They're in majority I guess.
I personally use smartphone as a phone, off-line GPS, camera (when I happen to not carry dedicated one) and to control various gismos like drones.
I do not use it for reading, viewing websites, computing, etc.
I personally use smartphone as a phone, off-line GPS, camera (when I happen to not carry dedicated one) and to control various gismos like drones.
I do not use it for reading, viewing websites, computing, etc.
What about music and videos/films?
I admit carrying a separate e-ink device is too much of a hassle, so I read books on the smartphone when am not at the PC.
I admit carrying a separate e-ink device is too much of a hassle, so I read books on the smartphone when am not at the PC.
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.
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.
[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...
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...
(incidentally: it's "free rein" as in horses, not "free reign" as in monarchs)
Not a lesson I was expecting to learn today, but here we are. I always thought it was the "reign" version because monarchs can "reign freely".
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).
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.
thanks, i've probably been making that mistake for years...
One of the more sensible eggcorns out there, admittedly.
What, really?
Welp, I've had that wrong my entire life.
Welp, I've had that wrong my entire life.
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.
(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.
Someone made a bridge between Pharo and Godot which looks pretty interesting. I've not dabbled in it myself yet, but they have a doc describing how it works: https://gitlab.com/chandler.justin.s/godot-talk-VM/-/blob/ma...
You might take a look at Cuis as a possible starting point. Its goal is to be a lean dialect of Smalltalk.
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.
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
It is called Objective-C. :)
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 (Pharo9 launcher I just downloaded) seems to want to launch my Pharo7 installation. Should I uninstall everything and try again?
Yeah, I'm having trouble with Pharolauncher too on Windows. Trying to launch any image (downloaded in launcher, or manually) results is an error. e.g.
Edit: "Templates: Pharo image (stable)" works (32bit v8)
Retry?
Error downloading 'https://files.pharo.org/get-files/90/pharo-vm-Windows-X86_64-stable.zip'
Cancel
Retry
Edit: "Templates: Pharo image (stable)" works (32bit v8)
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.
I wish that there were a Common Lisp with a Pharo like UI, like my old Lisp Machine.
Sounds very interesting, i look forward to your video. Where will i be able to find it?
I made a new youtube channel where the focus will be on Smalltalk game development
https://www.youtube.com/channel/UC9QoB2Ik54E1gEJsBixqJ9A
Alternatively I'll be sure to post it to the pharo discord and the smalltalk subreddit
https://www.youtube.com/channel/UC9QoB2Ik54E1gEJsBixqJ9A
Alternatively I'll be sure to post it to the pharo discord and the smalltalk subreddit
Please make a very small and simple game (a toy game :-)) first to help people get the clue before the things go complex.
And you just doubled your number of subscribers (I'm number two). Now you have to upload something for us! ;)
Raylib is fantastic fun, very much looking forward to seeing your progress.
it requires an update :)
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.
An interesting project for devs is Glamorous Toolkit (https://github.com/feenkcom/gtoolkit) as an experiment/exploration of better dev tooling.
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.
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.
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.
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.
"Delphi/TurboPascal was the peak of developer productivity"
"Smalltalk was the peak of developer productivity"
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".
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".
It's better shown than told. Just see this: 7 minutes of Pharo Smalltalk for Rubyists - https://www.youtube.com/watch?v=HOuZyOKa91o
I watched the whole video, thank you for sharing!
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)
https://quokkajs.com/
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)
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)
https://quokkajs.com/
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.
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.
It's a very noisy datapoint, but compare performance VW Smalltalk to NodeJS:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
VW Smalltalk is between 2x and 27x times slower than Javascript.
And Pharo is slower yet than VW Smalltalk:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
VW Smalltalk is between 2x and 27x times slower than Javascript.
And Pharo is slower yet than VW Smalltalk:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.
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."
> Pharo 5 in 2017
Seems to be tagged 2020 — 5.0-202002121043 Wed Feb 12 11:06:45 UTC 2020 gcc 5.4.0 [Production Spur 64-bit VM]
The pharo.version file contains — 80
Seems to be tagged 2020 — 5.0-202002121043 Wed Feb 12 11:06:45 UTC 2020 gcc 5.4.0 [Production Spur 64-bit VM]
The pharo.version file contains — 80
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.
The Pharo 9.0 vm from —
https://files.pharo.org/get-files/90/pharo64-linux-stable.zi...
— is the same as Pharo 8.0 —
5.0-202002121043 Wed Feb 12 11:06:45 UTC 2020 gcc 5.4.0 [Production Spur 64-bit VM]
https://files.pharo.org/get-files/90/pharo64-linux-stable.zi...
— is the same as Pharo 8.0 —
5.0-202002121043 Wed Feb 12 11:06:45 UTC 2020 gcc 5.4.0 [Production Spur 64-bit VM]
The person who receives the contact email usually allows posts to be re-opened.
Just run your smalltalk/self on the js vm... https://lively-next.org/
I wrote a post about this as someone who only discovered it in 2020 - https://nikhilism.com/post/2021/experiencing-smalltalk/
> … scripting tasks system, or for writing networked applications?
Sure. Back in the day, Smalltalk without GUI was known as "headless" so Google "headless smalltalk" and you should find info.
Sure. Back in the day, Smalltalk without GUI was known as "headless" so Google "headless smalltalk" and you should find info.
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.
[1] https://planetcroquet.squeak.org/
[1] https://planetcroquet.squeak.org/
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.
Similarly, they gain points for including a screenshot, but then lose those points for the bizarre photo-like cropping and skewing.
truth to be told, we learned that the hard way ;)
but we learned! :P
Could someone share a practical/industrial use case for this? E.g. can I build a SaaS, or a mobile app?
Seaside http://seaside.st/ is a web framework in Smalltalk that will run on Pharo (and a number of other smalltalk systems).
Also they have a GUI system ready so you can develop desktop apps (I'm not sure what the deployment story is like these days, but I assume it's fine).
Also they have a GUI system ready so you can develop desktop apps (I'm not sure what the deployment story is like these days, but I assume it's fine).
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
Here is another web application made with http://pharojs.org which runs on Pharo https://covid.cs.ryerson.ca/compare/
[edit - the link below now loads, very cool to see all the companies involved, especially given Pharo crops up here every few months]
I'd be curious about who, if anyone, funds Pharo development - especially if there are any medium-large companies backing it's development.
I found this link to the Pharo "consortium" but it's not loading for me https://consortium.pharo.org/
I'd be curious about who, if anyone, funds Pharo development - especially if there are any medium-large companies backing it's development.
I found this link to the Pharo "consortium" but it's not loading for me https://consortium.pharo.org/
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.
Loads for me now too. Wow, that is indeed an impressive list!
And yes, definitely don't want to detract from the community effort, the huge list of individual contributors is impressive in itself.
And yes, definitely don't want to detract from the community effort, the huge list of individual contributors is impressive in itself.
[deleted]
Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback.
“Pharo is a … and immediate feedback.”
The key that we should provide more often.
Bret Victor has been discussing for over a decade. Can’t find them demo that i’m thinking of but here’s an introduction into Bret
https://youtu.be/ef2jpjTEB5U
https://youtu.be/8pTEmbeENF4
His ideas go beyond “immediate feedback” …
The key that we should provide more often.
Bret Victor has been discussing for over a decade. Can’t find them demo that i’m thinking of but here’s an introduction into Bret
https://youtu.be/ef2jpjTEB5U
https://youtu.be/8pTEmbeENF4
His ideas go beyond “immediate feedback” …
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.
[1] http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....
[1] http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....
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.
>In Pharo, everything is an object. This purity and uniformity in the system and language design makes Pharo clean and comfortable to learn.
Does this mean Python and JS meet the same definition and are as "clean and comfortable"?
Does this mean Python and JS meet the same definition and are as "clean and comfortable"?
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.
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.
Python comes close, but what makes Smalltalk special is that flow control and loops are done with objects. There are almost no keywords.
Imagine that you could do something like this in JavaScript:
(name === "Mike").ifTrue(() => console.log("Hi Mike");
The implementation of this is done through a Boolean class, which has two subclasses, True and False.
True implements the ifTrue(fn) by invoking "fn", False simply returns.
The main advantage is that everything is predictable and inspectable.
Imagine that you could do something like this in JavaScript:
(name === "Mike").ifTrue(() => console.log("Hi Mike");
The implementation of this is done through a Boolean class, which has two subclasses, True and False.
True implements the ifTrue(fn) by invoking "fn", False simply returns.
The main advantage is that everything is predictable and inspectable.
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.
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.
Unlike most OOP languages, it's true, and not just marketing, for Smalltalk to make the claim that everything is in an object.
I was not talking about everything being an object. I was talking about that claim being the key to being nice and comfortable.
Many sibling comments, IMHO, miss the point of the parent and focus on the claim about python and js.
Python and js could perhaps have been completely object based. It still wouldn't make them comfortable for many.
Many sibling comments, IMHO, miss the point of the parent and focus on the claim about python and js.
Python and js could perhaps have been completely object based. It still wouldn't make them comfortable for many.
While Python wasn't born pure object based, it is definetly object based in its current version.
Python 3.9.5 (default, May 27 2021, 19:45:35)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 1
>>> type(x)
<class 'int'>
>>> dir(x)
['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', '__divmod
__', '__doc__', '__eq__', '__float__', '__floor__', '__floordiv__', '__format__', '__ge__', '__getattribut
e__', '__getnewargs__', '__gt__', '__hash__', '__index__', '__init__', '__init_subclass__', '__int__', '__
invert__', '__le__', '__lshift__', '__lt__', '__mod__', '__mul__', '__ne__', '__neg__', '__new__', '__or__
', '__pos__', '__pow__', '__radd__', '__rand__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__',
'__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__round__', '__rpow__', '__rrshift__'
, '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__sizeof__', '__str__', '__sub__',
'__subclasshook__', '__truediv__', '__trunc__', '__xor__', 'as_integer_ratio', 'bit_length', 'conjugate',
'denominator', 'from_bytes', 'imag', 'numerator', 'real', 'to_bytes']
>>>
>>> y = [2]
>>> type(y)
<class 'list'>
>>> dir(y)
['__add__', '__class__', '__class_getitem__', '__contains__', '__delattr__', '__delitem__', '__dir__', '__
doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__iadd
__', '__imul__', '__init__', '__init_subclass__', '__iter__', '__le__', '__len__', '__lt__', '__mul__', '_
_ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__', '
__setitem__', '__sizeof__', '__str__', '__subclasshook__', 'append', 'clear', 'copy', 'count', 'extend', '
index', 'insert', 'pop', 'remove', 'reverse', 'sort']
>>>
>>> def sum(a, b): return a + b
...
>>> sum
<function sum at 0x7f673429d1f0>
>>> dir(sum)
['__annotations__', '__call__', '__class__', '__closure__', '__code__', '__defaults__', '__delattr__', '__
dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__get__', '__getattribute__', '__globals
__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__kwdefaults__', '__le__', '__lt__', '__modul
e__', '__name__', '__ne__', '__new__', '__qualname__', '__reduce__', '__reduce_ex__', '__repr__', '__setat
tr__', '__sizeof__', '__str__', '__subclasshook__']
I think you are replying to the wrong comment. That's not even my point.
The sentence says that it makes Pharo clean and comfortable to learn. Not that it makes every language clean and comfortable to learn :-)
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.
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.
> Unlike most OOP languages, it's true, and not just marketing, for Smalltalk to make the claim that everything is in an object.
Its not uncommon in dynamic OOP (or even object-first multiparadigm languages); it’s true in Python, Ruby, JS, and others.
Its not uncommon in dynamic OOP (or even object-first multiparadigm languages); it’s true in Python, Ruby, JS, and others.
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.
Ruby is much closer to smalltalk than python and js (in the evything is an object sense, and partially in the clean and comfortable sense).
Maybe the closest "real world" examples would be Lua, and scheme?
Maybe the closest "real world" examples would be Lua, and scheme?
Ruby comes closer than Python or JS with it's blocks and consistent object model (including primitives).
When Pharo says 'everything' they mean _everything_.
Primitives in javascript are not objects.
> Does this mean Python and JS meet the same definition and are as "clean and comfortable"?
Are things like message sends or activation records accessible and manipulable as objects in Python and JS?
Are things like message sends or activation records accessible and manipulable as objects in Python and JS?
It sounds like a very fun environment . But what can I use this for?
Can it build GUIs? What about 2d/ 3d graphics? Does it interface with Java things? Databases?
It's a single threaded vm like python/nodejs with ffi support. So you can expect same things i.e. ipc/network to communicate with outside.
Smalltalk was born as a graphics based workstation OS, naturally it can do all of that.
> Can it build GUIs?
Yes. The GUI framework is called Spec (Spec2, to be specific) and supports multiple backends, including GTK.
Yes. The GUI framework is called Spec (Spec2, to be specific) and supports multiple backends, including GTK.
[deleted]
Are there any perceived shortcomings of Smalltalk that caused it not to take hold?
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.'
https://mitpress.mit.edu/books/making-use
Technical shortcomings, September 1988 — "… currently unrealistic to expect that an excellent rapid prototyping system can also be an excellent application delivery system."
https://static.miraheze.org/triplescriptswiki/4/49/Wirfs-Bro...
"Smalltalk, C++ knock heads. Computerworld 29, 45 (Nov. 6, 1995)
https://books.google.com/books?id=oKDIlxbMaS4C&pg=PA153
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.'
https://mitpress.mit.edu/books/making-use
Technical shortcomings, September 1988 — "… currently unrealistic to expect that an excellent rapid prototyping system can also be an excellent application delivery system."
https://static.miraheze.org/triplescriptswiki/4/49/Wirfs-Bro...
"Smalltalk, C++ knock heads. Computerworld 29, 45 (Nov. 6, 1995)
https://books.google.com/books?id=oKDIlxbMaS4C&pg=PA153
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.
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.
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.
Congrats !
Awesome. Seems like it can't find the Windows VM files though.
I wonder, how hard is it to bootstrap Pharo on new platform...
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.
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.
Are here any documents how to start?
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?
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?
For anyone that wants to learn about Pharo, I recommend this online course:
https://www.fun-mooc.fr/en/courses/live-object-programming-p...
It's available in English and French.
The videos from it are on Youtube.
English voiceover: https://www.youtube.com/watch?v=JUKIjdjGjBU&list=PL2okA_2qDJ...
French: https://www.youtube.com/watch?v=-Sk_35lB-EI&list=PL2okA_2qDJ...
English voiceover: https://www.youtube.com/watch?v=JUKIjdjGjBU&list=PL2okA_2qDJ...
French: https://www.youtube.com/watch?v=-Sk_35lB-EI&list=PL2okA_2qDJ...
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.
Not trying to rate any particular language here.
Not trying to rate any particular language here.
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.
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.
> ...if one would actually bother to read OO CS literature
It's true. I haven't read much OO CS literature AFAIK. Do you have a some recommendations?
It's true. I haven't read much OO CS literature AFAIK. Do you have a some recommendations?
"Component Software: Beyond Object-Oriented Programming"
https://www.amazon.com/Component-Software-Object-Oriented-Pr...
The first edition uses Component Pascal instead,
https://www.amazon.com/Component-Software-Beyond-Object-Orie...
Then even if it hasn't taken the world by storm,
"Designing Object Oriented C++ Applications Using The Booch Method"
https://www.amazon.com/Designing-Object-Oriented-Application...
Assuming you also feel like reading about UML design stuff
"Object-Oriented Analysis and Design with Applications"
https://www.amazon.com/Object-Oriented-Analysis-Design-Appli...
https://www.amazon.com/Component-Software-Object-Oriented-Pr...
The first edition uses Component Pascal instead,
https://www.amazon.com/Component-Software-Beyond-Object-Orie...
Then even if it hasn't taken the world by storm,
"Designing Object Oriented C++ Applications Using The Booch Method"
https://www.amazon.com/Designing-Object-Oriented-Application...
Assuming you also feel like reading about UML design stuff
"Object-Oriented Analysis and Design with Applications"
https://www.amazon.com/Object-Oriented-Analysis-Design-Appli...
Thanks!
> 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.
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.
And 10 years later still no proper support for retina displays. I really think you should get your priorities straight.
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.
I'm sure they'd welcome your PR.
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.
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 (?)
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.
Cool. How does it work, is it 100% native widgets? Are there any platform specific (x11 etc.) things used?
it works everywhere gtk3 works (we have production applications in windows, macOS and obviously linux)
Because GTK3 is so great on Linux, we should run it on macOS and Windows too...
I don't know what they were thinking. As far as I can tell, Pharo UI history has been one bad (as in not pragmatic) decision after another.
I don't know what they were thinking. As far as I can tell, Pharo UI history has been one bad (as in not pragmatic) decision after another.
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.
> I really think you should get your priorities straight.
The irony.
The irony.
Pharo handles the Retina display on my new MacBook Pro just fine.
Retina displays don't matter because the majority of your users don't have them. Problem solved :)
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.
Surely most decent laptops being sold are HiDPI at this point?
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.
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.
Traditional (~110 DPI, what Windows and MacOS were designed for) 13" resolution is 1280 or 1366. So 200% that is merely 2560+
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.
* 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.
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.
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.
We're talking horizontal resolution. No need for "p" obfuscation from the TV world!
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.
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.
It all depends on who the user will be. Will it be a developer or will it be someone with a work laptop that has an 1366x768 screen?
Not as far as I'm aware, no.
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.