Pharo 8.0(pharo.org) |
Pharo 8.0(pharo.org) |
1. You can download a single zip file (Pharo Standalone) and it will give you all the tools of a modern IDE without shitting all over your system and with faster startup than Atom, VS Code or even LINQPad.
2. The environment retains all its state across restarts. The editor stuff, the running state of the program - everything.
3. You have the same capabilities as the people who developed the language. You program, the run-time environment and the editor itself can be browsed and edited by the same set of tools, without any extra hoops. There is very little "magic".
4. The syntax of the language is designed so that you can create DSLs without using macros or pre-processors.
5. It's the only environment in my recent memory where I can do stuff without opening the web browser to search for something every 5 minutes.
6. IMO, breaking the system into four-tier structure made the whole thing much more tractable than infinitely nested directories or namespace hierarchies. I also like that there is no need to manage files with code.
Since Ruby was largely inspired by Smalltalk, you'll find similarities in their views of OO and code. Where they fundamentally differ is in the environment since Smalltalk is based on a monolithic persistent image so it can do things like have the debugger, and other GUI tools, built in. All that video was showing was built in stuff from the Pharo image... other dialects have their own takes on the tools.
[1] You can create a distinction by removing the development tools and replacing their functionality with non-interactive logging/error handlers for production deployment.
Pharo by Example should be a good starting point.
Developing in Smalltalk is unlike EVERYTHING else. As noted by seandenigris standard assumptions about things like "hello world" don't apply.
Except that I see a big error page.
Isn't CloudFlare supposed to help with this? The message on top seems to indicate that, but when I (back in the day) tested with CF on my domain it just proxied every request and failed when my server didn't respond, having zero advantage over just using my server directly (in fact, even having the downside that Tor users now couldn't reach my site anymore). Seems like that's still the case.
Edit: maybe try https://github.com/pharo-project/pharo-changelogs/blob/maste... ?
I can see that the "radical: always-debug, always-on might need a real VM, but it's apparent there isn't enough base for this to produce a true VM.
Is it really impossible to port to the JVM, the javascript VMs, or something similar? Otherwise I fear this is doomed to toy status.
1) YES smalltalk _has_ been ported to the JVM https://www.redline.st/ AND you can also run it in the GraalVM https://www.graalvm.org/
2) I'm pretty sure the initial JVM was a clone / extension of a Smalltalk VM. Having trouble googling the details, but while you may be having trouble getting it to work on your particular Windows install you might want to consider that you're possibly ignorant of the fact that the Smalltalk VM is not only one of the best available but battle tested over decades.
I would guess that what you're seeing is a particular windows issue that has nothing to do with the VM itself.
Wikipedia for Pharo says they have a VM with JIT, etc. I have never heard a peep about the Smalltalk VM in any circumstance as a performant target for any language. Ever.
If it's battle tested and great, why isn't it used for anything else than Smalltalk ports? Is there a python, ruby, javascript, java, etc port to the smalltalk VM?
If it sounds like I'm being dismissive, that's not the point. The point is the Smalltalk ecosystem, like Lisp derivatives, likes to have its own top-to-bottom stack completely isolated from "real" execution platforms.
For Lisp it's so bad that Clojure is rejected by some Lisp purists because it can JVM / JS compile.
IMO, for example, Ruby made a strategic error writing their own VM rather than just embracing the JVM as the main VM, although when Ruby was writing their VM invokedynamic hadn't been added to the JVM. Well, and they should have added some optional typing.
Once you get used to it, Smalltalk is really the most amazing development environment. It's hard to describe how it feels to work with live objects - it's an incredible speed boost, because instead of grepping logs or stepping through code, you just interact with the objects directly, you can examine the state of instance variables, add new methods, or change code while the code is running. The feedback loop is so short, you get amazing productivity.
There's a great video floating around somewhere of someone debugging an Asteroids game while the game is running.
From what I've read, the downside is that working on larger programs in a team is challenging. It takes a lot more communication to keep the code base consistent and structured.
That would be this: https://www.youtube.com/watch?v=L2rD2YSTMV4&list=PL62E3E45E6...
I don't think that's an inherent limitation of image based development -- just that the current systems don't offer facilities for syncing etc.
He got the job. :)
I did some work in Smalltalk (working on a mod of Scratch 1.4, which was written in Squeak Smalltalk from the turn of the century). Once you got used to it, it was amazing. The environment is lively, and you can debug into everything.
The tech is great; it is just that the community of people who know it is relatively small. If you wanted to develop an open-source project in it, you may have a harder time finding other developers to help.
On the other hand, if you wanted to make a cross-platform desktop application that doesn't look native (which, given the prevalence of Electron, doesn't seem to matter too much to people), this would be an excellent choice.
I wish I could do more development with Pharo. I also think the web framework Seaside would be fun to work with. http://seaside.st/
We just need to go back in time to twenty years or so and take a different fork ...
Yeah, as if people are going to install a whole virtual machine to run a chat application...
Wait...
I'll just mention that the announcement (which is now down) and the readme mentions spec2:
> Spec 2 (preview) - UI building framework with multiple backends
The announcement (main hn link) mentioned spec2 and native look together.
Pharo would be the one Smalltalk environment I would not use for non-toy stuff because it has historically been so unstable. This is at least somewhat by design since the developers have always stated they didn't want to be constrained by backwards compatibility... and they have never let themselves be. It's a great environment for playing around with ideas, not for developing code you expect to work as is a few years from now without some (potentially serious) work. In fairness, all the Squeak dialects have this issue to varying degrees. It just seems to me that it's more extreme with Pharo.
Playing with it in 2006 was like using magic. Sure, it is not REST, but whenever I show it off to someone used to handling a lot of stuff client side they still have to pinch themselves :)
If I'm writing a native windows app I'll go with dolphin smalltalk which imo is much nicer to work with and gives you a native gui. I have to say though pharo is getting better all the time and has an active community.Especially if with the "live in the debugger" type of development where you write a test and get the debugger to tell you the next step.
Try it, you might like it.
Projects screenshots look way better than I expected.
I don't see any page where it says this is the most requested feature. If it was, it would've been developed by now.
It's kinda funny, few hours ago there was a post on the frontpage by burntsushi on the terrible way FOSS developers are treated. And here we have a live example of the usual drive-by commenters who take one glance at the project and decide their own niche requested feature is the most important one.
Pharo’s rendering layer is complicated, to say the least. I made a few approaches in attempting to figure out how it works and perhaps starting adapting it to hidpi screens... but it is a really complicated endeavor. I am not demanding anything from Pharo developers, I am just saying it is a pity I can’t use this beautiful, innovative Smalltalk system. Pixelated UI among the smooth lines of other apps make it unusable for me, and I am not smart enough to fix it.
Generally speaking unless there is a big company behind the scenes that pays the developers for an open source project, it doesn't matter how many people ask for something if the developers themselves aren't interested in working on it and your best bet is to do it the old fashioned way (yourself :-P).
[0] https://gs.statcounter.com/screen-resolution-stats/desktop/w...
Also, statscounter doesn't account for high resolution displays at all, grouping them all as "other". And these are around 20%.
It'd also be interesting if they were even checking physical resolution or virtual (scaled) resolution.
A huge system like WordPress can't do dynamic content for more than a small number of visitors per second no matter how beefy the server and has to hackily convert content from dynamic to static content. Which is fine since it uses a lot less power to do static content instead of buying beefier and beefier servers, but it is not how WordPress meant its blogging software to have to be (maybe they gave up by now and do static rendering by default, but it used to be all plugin based). By writing my own tiny blogging software I implemented what I needed and it worked just fine on an Intel Atom CPU, even on the HN homepage.
I've never worked in a team in a Pharo projects, but I imagine it works well somehow. There's ~75 contributors to the 8.0 release.
"The resource content type was not cached by default and your current Cloudflare caching configuration doesn't instruct Cloudflare to cache the resource. Instead, the resource was requested from the origin web server. Use Page Rules to implement custom caching options."
[1] https://support.cloudflare.com/hc/en-us/articles/200172516-U...
We give onsite candidates affordances to install any environment that makes them feel comfortable, or to allow them to bring their own machines. The interview machines get wiped on a regular cadence, so installing packages is no big deal.
If candidates send us a list of the software they want beforehand, we usually try to set it up for them in advance. If not, it's fine for the schedule to run over a bit for them to tweak things as they like.
Interviews are stressful enough. We want everything working in a candidate's favor so they can do their best.
The funny part is that even though VSE isn't a very good Smalltalk, it's one of the most productive environments I've ever worked in.
Wow, any chance you've written about the upgrade process?
Also, Smalltalk offers a much more transparent development environment. So, you're not writing code that goes into a black box and produces results. You can see what's going on in the box and make sure its doing it correctly.
also, the Squeak by example book (i think Pharo by example is a fork of this) very quickly starts showing people how to write tests. So the mentality isn't "oh, yeah, i guess i could add tests" it's "oh hey, tests are part of making smalltalk code" so you've got that going for it too.
combine those things with the smaller community, and thus a much more narrowly defined set of "needs" for a web framework and yeah, it doesn't get poked constantly.
but that's ok.
If statscounter isn't up to your liking, then check:
https://www.screenresolution.org/ (typical desktop HiDPI resolutions like 3840x2160 are at ~0.1%)
https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw... (gamers tend to have higher specs in their computers and 4K is a big trend in places like /r/buildapc and /r/pcgaming yet 4K is at just 1.51%)
https://www.statista.com/statistics/487487/leading-desktop-s... (only for UK and a couple years old but the likelihood of the statistics going dramatically up is very low)
Look, if all you work with is Macbooks and similar computers, it is very likely that your view is biased (pretty much like the people who wonder why others are making a fuss about Electron applications when they can run several of them without issues). According to this (1 year old):
https://www.cultofmac.com/618730/q1-2019-pc-market-apple-mac...
...Apple only had around 7% of the global market share of computer sales between big brands and not only that is very low but also it doesn't include local brands that assemble the computers themselves nor custom built computers (even though i do not believe this is a big number, considering the size of the custom built market that exists, it still is a significant number). And it is about all Mac sales, including the lower end iMac (that have a regular DPI monitor) and monitorless desktops like Mac Mini that can be connected to a regular DPI monitor.
HiDPI on desktop might be a mainstream thing in 10 years or so, but right now every single statistic available shows otherwise. On mobile is a different story though (which is why i tried to avoid any statistics page that focuses on mobile).
When I first saw a hidpi display (on iPhone 4), this was a game changer for me. Since then, I don’t understand how it is even possible to settle for something with visible pixels. iPhone 4 was releases 10 years ago.
You can of course use Wine/Wineskin and there are guides on how to get this done for Dolphin apps, but I just wont bother for my clients. Not one has ever mentioned compatibility with anything other than Windows 10.
True, but more and more software is delivered using web-based technologies - from desktop apps like Slack to most SaaS offerings.
You can install an application that launches the VM with the desired image and the user will never know the app is running inside a Smalltalk VM.
I'm sure you could do it with https://www.amber-lang.net/ ;-)
Amber.js was the original name of Ember.js (so named after the style of beer one of its creators was drinking when they were searching for a name; if memory serves it was also the result of pulling bits and pieces out of SproutCore.js). When it came time to release the project, the authors of A/Ember were notified that they were encroaching on the name of a pre-existing project and changed it.
And again if it's simply the resolution the browser reports it is post scale so a 2560x1440 laptop at 150% would show as 1920x1080 anyways. It's web stats, they only care about the size of the viewport.
If you can go by with 150% this isn't HiDPI (and on most laptops 150% for 1080p is too big anyway, at least on Windows, you want something around 125%). HiDPI is something that you need at least 200%, like Apple's 2560x1600 at 13" where anything less is unusable. Using 100% scaling on a laptop at 1080p is perfectly fine (this is my laptop configuration and how i use it).
Remember that "HiDPI" was the generic term that was used in place of Apple's trademarked "Retina" and what is i am talking about.
The entire discussion is about why HiDPI isn't supported and the answer is simply that few people need it (as shown by the stats i linked above and below) and fewer are in a position to implement it.