111–120 of 236 posts
A few years back Pharo's predecessor/sibling Squeak was garnering some interest due to its "Seaside" web framework, which used continuations and so made some interactions easier to program. But after the rise of JavaScript, this became a lot less important.
does it have decent hidpi support yet? I remember trying out pharo 6 briefly and being unable to get it usable on my laptop.
Squeak and Pharo are great but the font rendering is terrible, I can't stress how bad it looks on hidpi screens. That makes it unusable for me since it gives me headaches. It's a shame too since they have spent a lot of time working on related frameworks (athens?, brick?, bloc?) that alas don't seem to go anywhere (or nobody is in the position to bring everything together). Last I checked they were trying to use a native library from Mozilla (Moz2D which is the backend of Firefox!?!?) to do all rendering, which is highly problematic and disappointing if it ends up being used. The clusterfuck of libraries that they have layered together should clearly point out that this is not the right approach.
On macOS, the graphics stack looks like: CoreGraphics Alan Kay would have a seizure. Aliaksei Syrel: What happened to keeping things simple?
I really hope the graphics issues get resolved since I'm pretty sure they are costing them a lot of users. The regular Pharo devs by virtue of using Pharo every day are (probably) not in the position to realize how a new user coming from environments with great font rendering, UI speed/smoothness, reacts to Pharo. Initial impressions are everything.
After reading this line: > Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback. and seeing the initial screenshot on the announcement, I thought that this was a joke post. How you can call this "focused on simplicity" while showing that horrific hodge podge of a screen shot is beyond me.
Thanks for your feedback. Maybe it would be better to show the three tools in separate screen shots rather than overlapping. One aspect of simplicity is its minimal syntax... https://en.wikipedia.org/wiki/File:Pharo_syntax_postcard.svg
Earlier quoted context omitted.
It feels like an alien world moving into the Smalltalk live environments and the patterns I've built up over the years and tools like Vim, etc are indispensable when it comes to moving around and modifying code. Of all the reading I've done on it, the entirety of the language is contained inside images. I know that the Pharo guys have engineered this marvel, and I think it's on the verge of a breakthrough with a lot…
It is an alien world.... but a better one by most measures. I come from Emacs (20+ years when I first encountered the Smalltalk IDE), and find aspects of code editing irritating sometimes, but the overall value of the IDE more than pays for that irritation. One of the coolest things is TDD carried to an extreme level. I build my test, and it fails because there's no such method, so I get a debug window and tell it to…
Please do show some measures.
Earlier quoted context omitted.
You certainly can use Pharo with normal tools. You just write (and version, and whatever else) your code normally in files, then you "file in", or load, those in Pharo. You'd need ~3 lines of a wrapper if you don't want to do it manually. I share your concerns, actually - the truth is, the code editing part of Pharo is its least compelling feature and just cannot compare to my Emacs setup with years of tweaking behin…
The small size of methods is a feature, not a bug :-). And this partly explains why the lack of [your favourite editor] bindings isn't so important. You don't typically spend as much time as you're used to typing in code - and make progress faster as a result - counter-intuitive as that may sound. The integration and the debugger are most of the reason why.
For 99% of programmers out there, programming IS typing on a keyboard. Clicking around with a mouse is only something that non-expert users (or children, e.g. Scratch users) do, because it is approximately 10x slower to get anything done by laboriously pointing and clicking than by typing. For example, finding the largest file in my home directory through the GUI takes 5 careful targeting operations and 5 clicks, a click-and-drag, and then some scrolling, and then I have to do more dragging to move the window around so I can see what's under it. Using a keyboard I type "ll -S" and I'm done in half a second (and immediately able to issue the next command). You simply can't compete with that.
Even though it isn't the same way you are used to operating, I think it will be necessary to take into account the needs of that audience if you want to bring them on board.
As a thought experiment, what would it take to make the environment comfortably usable with only a keyboard, including discoverability of all the necessary keyboard controls? You could treat it as an accessibility issue; what if the user is unable to use a mouse?
does it have decent hidpi support yet? I remember trying out pharo 6 briefly and being unable to get it usable on my laptop.
This has been a point of contention for lots of people, including myself. From what I remember, it was supposed to happen for Pharo 7 but now I see that it didn't. Squeak and Pharo are great but the font rendering is terrible, I can't stress how bad it looks on hidpi screens. That makes it unusable for me since it gives me headaches. It's a shame too since they have spent a lot of time working on related frameworks (…
The Pharo website has zero mention of its relation to Smalltalk, although the Wiki article calls it a dialect. So how close are the two in reality? Is the syntax from your standard Smalltalk-80 textbook largely portable/compatible to Pharo, or is Pharo merely "inspired" by Smalltalk?
It seems that simply mentioning that Pharo is based on Smalltalk would immediately convey a lot of useful information to people who are new to Pharo.
Earlier quoted context omitted.
For what it's worth I think these are decent questions to ask, even if others think they're worthy of a downvote. As far as I understand it: it doesn't necessarily compile in that sense. You are constructing an 'image', which is basically a living environment that your program runs in, and maybe it corresponds somewhat to a VM. But you're not really treating the code that the VM runs as separate to the VM itself. In…
Smalltalk system consists of a VirtualMachine and an image. An image is just some Smalltalk code compiled into a form suitable for VM to read it into memory. The initial image contains all the standard classes of Smalltalk plus the GUI and various tools. When you add a method to some class inside the GUI, it gets compiled and added to the image held by the VM in memory. Later, you can dump the modified image to disk,…