pharo VS teliva

Smalltalk (https://pharo.org/)

Smalltalk also did this. These days my impression is the most active tendril is https://pharo.org/.

What I find especially interesting about that relative to this Python distro is that the Pharo executable runs in a host OS (e.g. whatever your daily driver is) and can maintain different image files for different Pharo system states. So not only do you have the integrated language/OS (which is very cool on its own), but you also have something that feels like Docker containers.

And it even goes beyond containers because those image files really are the state of the system at the time they're saved, which means you can ask for that file in a bug report and get guaranteed bug reproduction, which is pretty incredible.

It is the initial alpha release end-user can test. It is a complete port from Pharo to Cuis-Smalltalk. Likely bugs will be find.

I've recently started learning Pharo^1 and I think there is a lot to like about it. It hurts to say as a Lisp and Emacs fan, but using the Pharo IDE feels like using Emacs/extending Emacs with Emacs Lisp, but somehow with a more tightly integrated language and environment. Being able to easily inspect the code related to the UI widgets, modify it and make changes on the fly are unlike anything I've experienced in other languages. I think a whole OS built on top of Smalltalk would be so cool and really play into the strengths of Smalltalk. I'm also amazed that SmallTalk had a lot of these IDE like features since before the 80s^2. I know there are a lot of issues with image based languages, and I admit I haven't been using one long enough to have experienced all the Gotcha, so what does HN think of Smalltalks and it's derivatives, and what are you all doing with them?

1. https://pharo.org/

2. https://youtu.be/uknEhXyZgsg?t=2366

Cool! I program for around 7 months in Pharo now at Yesplan [0]. We're hiring a devops engineer and a software engineer. While the Pharo website [1] avoids mentioning it, it's a Smalltalk descendant.

What I like about Pharo:

1. Programming in the debugger makes things feel much quicker

2. Evaluating expressions inside your code editor makes programming feel much quicker

3. The ability to quickly browse classes and methods makes programming feel much quicker (e.g. I type Date somewhere, select it, press CMD+B and now I browse the Date class).

Don't get me wrong, Pharo has downsides, especially when it comes to using it in production (IMO). With that said, the language feels fun to use! I definitely like it now as my first language for side projects as it is more graphical, more playful, and feels quicker for iterative development (e.g. when consuming APIs). It's why I wanted to learn it in the first place, it has shown me a different philosophy on how programmers interact with a programming language and IDE.

[0] https://yesplan.be/en/vacancies

[1] https://pharo.org

Of course, Alan Kay's Smalltalk 80 is for many the quintessential lost paradise of personal computing. Some modern descendants are Squeak, Pharo and Cuis. Then there's Lisp machines, or for something more Unix-like, there's Plan 9.. so many cool systems deprived of mass adoption for no good reason.

> You know, that "assembling things live in the sky" Lisp feeling (Yegge's phrase, not mine). The only other computation environment that is right there en par in flexibility and conveyance of the same trippy feeling is, of course, Emacs.

Do you know Pharo? The experience you describe is also typical in the Smalltalk family. See https://pharo.org/

Smalltalk could be used as the "ideal" tool (balance between Code & No-Code). It starts out with a simple graphical interface for doing everything, but it also encourages you to customize everything by modifying the underlying code. Of course, the disadvantage is that it's quite niche - very few people actually use it nowadays.

In Smalltalk there is no such thing as source files. Your program is an image which can be freely modified and dumped. Look at Pharo[1] which is a modern Smalltalk environment. You start it up and create classes in the IDE, but never do you create "source files".

[1] https://pharo.org/

Thanks for reply and for have shared your project first!

> I think we can refresh some the things that make it powerful with a fresh coat of paint, to make it more accessible to a “younger generation.”

That's what scare me, again in general: I see regular small complaint of modern absurdity, posts like:

- https://tiramisu.bearblog.dev/your-desktop-is-not-a-destinat... | https://news.ycombinator.com/item?id=33838697

- https://mjg59.dreamwidth.org/61535.html

- https://vermaden.wordpress.com/2022/02/07/epitaph-to-laptops...

- https://rsapkf.org/weblog/q2z/

- https://tomcritchlow.com/2022/04/21/new-rss/

- https://jfm.carcosa.net/blog/computing/usenet/ | https://news.ycombinator.com/item?id=33510169

- https://dianne.skoll.ca/projects/remind/ | https://news.ycombinator.com/item?id=28363453

- https://github.com/akkartik/teliva

- https://akiflow.com/

- https://onezero.medium.com/the-document-metaphor-desktop-gui...

- https://den.dev/blog/user-hostile-software/

- https://www.charlieharrington.com/smart-phone-dumb-terminal/

- https://mattmower.com/2021/08/02/what-we-lost/

and COUNTLESS others, similarly many "new stuff"/innovations appear and are actually partial, limited and limiting solutions to problems already solved decades ago in a more broad and superior way.

Emacs itself is a bit horrific in the sense that it's codebase is hard to be kept up by modern developers who have troubles knowing it, but at least represent the classic model. If we lost the memory of the past it will takes decades to reach the level of evolution we have already achieved witch is really a shame.

Anytime I see new software, yours, LogSeq, some "new shiny file manager", Tiidly Wiki and so on, witch actually are a BIG effort to achieve something already existing with far less efforts thanks to an already made ecosystems who makes their development easier I have a sore smile: end users suffer from limits of modern software, DEVELOPERS suffer equally because craft something on top of modern systems it's equally terrible but we seems to be unable on one side to reach again a critical mass of users to being able to innovate again, on the other sides most people simply ignore the past so ignore what's lost.

A stupid example: link an email in SB means essentially or support a specific MUA, tracking it's evolution since breaking changes might happen all the time or add an MUE inside SB. In Emacs it's just a simple function since anything is already there. In Plan 9 to cite a project often considered hostile from and to Emacs write an MUA is damn simple limiting mails to Plan 9 itself, an MUA it's just a specific viewer of some text stream read form some user-configured filesystems mounts and so on.

The sore part is that's I can easy state the above, even in my poor English, but I have no practical solution because resurrecting the classic model for present times demand an effort ONLY a public funded body or a large community can made. We have dismissed "for business reasons" essentially all public research and we have essentially pushed to irrelevance all communities...

I question the need for scale in 90% of the places where the tech industry has cargo-culted it. Clearly I'm still failing to articulate this. Perhaps https://news.ycombinator.com/item?id=30019146#30040616 will help triangulate on what I mean.

> Can you clarify what you see as the alternative? Implementing everything from scratch seems absurd and so costly that there’s no point in considering this an actual option.

Not using, reimplementing and copying are the closest thing to solutions I have right now. You're right that they're not applicable to most people in their current context. I have a day job in tech and have to deal with some cognitive dissonance every day between my day job and my open source research. The one thing I have found valuable to take to my scale-obsessed tech job is to constantly be suspicious of dependencies and constantly ask if the operational burdens justify some new feature. Just switching mindset that way from software as asset to software as liability has, I'd like to believe, helped my org's decision-making.

> We have probably invested dev-millennia into managing copies. This is exactly what source control does. This is not a new area of investment. Merging is a giant pain in the ass and very possibly always will be. Accepting merge pain better come with some huge benefits.

Not all copying is the same. We've learned to copy the letter 'e' so well in our writings that we don't even think about it. In this context, even if I made a tool to make copying easier and merges more reliable, that would just cause people to take on more dependencies which defeats the whole point of understanding dependencies. So tooling would be counter-productive in that direction. The direction I want to focus on is: how can we help people understand the software they've copied into their applications? _That_ is the place where I want tooling to focus. Copying is just an implementation detail, a first, imperfect, heuristic coping mechanism for going from the world we have today to the world I want to move to that has 1000x more forks and 1000x more eyeballs looking at source code. You can see some (very toy) efforts in this direction at https://github.com/akkartik/teliva

> It’s untenable to have, e.g., everyone who works on Windows be an expert in every part of the code.

It's frustrating to say one thing in response to counter-argument A and have someone then bring up counter-argument B because I didn't talk about it right there in the response to counter-argument A. I think this is what Plato was talking about when he ranted about the problems with the newfangled technology of writing: https://newlearningonline.com/literacies/chapter-1/socrates-.... I'm not saying everyone needs to be an expert in everything. I'm saying software should reduce the pressure on people to be experts so that we can late-bind experts to domains. Not every software sub-system should need expertise at the scale at which it is used in every possible context. My Linux laptop doesn't need to be optimized to the hilt the way Google's server farms do. Using the same scheduling algo or whatever in my laptop imposes real costs on my ability to understand my computer, without giving me the benefits Google gets from the algo.

There are options between those possibilities, though. Here's my preferred point[1] in the state space:

It's impossible for people to effectively use software over the long term without learning about its internals. Software can help people learn about its internals.

https://github.com/akkartik/teliva#readme

I work on ways to write programs that help outsiders understand their big picture (rather than insiders understand incoming contributions).

The goal: you (any programmer) should be able to use an open-source program, get an idea for a simple tweak, open it up, orient yourself, and make the change you visualized -- all in a single afternoon.

More details: http://akkartik.name/about

What I have so far: https://github.com/akkartik/teliva

Lately I'm spending a lot of time on the sandboxing model. It's nice to be able to download and run untrusted programs. How to permit this without letting them cause too much damage, by explicitly giving them arbitrarily fine-grained permissions that are still easy to take in at a glance.

Main project page: https://github.com/akkartik/teliva

It's hard. Building Mu has given me more of a flavor for just how hard it is. Some limitations of Mu:

* It still requires firmware. There's a whole lot of C down there. How deep do you want to go?

* No mouse. This is just my own ignorance. I can't get the damn IRQs and interrupts figured out.

* Doesn't work yet on real hardware. I live in Qemu. Debugging that is a whole new set of skills I need to learn.

* No networking, almost no persistent storage. Mu has a very simple and slow driver for ATA disks, but that probably won't suffice on most real-world machine configurations. There's 0 network drivers right now. I probably need a dozen to get any sort of coverage.

The stuff you mentioned around graphics and OS file dialogs, that feels easier once you're willing to put up with constraints like Mu's 1024x768 and so on. But yeah, there's major challenges on this road.

Partly due to these challenges, I've actually started to hedge my bets and make some compromises. My new project is https://github.com/akkartik/teliva which doesn't try to eliminate C, just minimize it. Linux kernel, libc, Lua (12k lines of C), some libraries for https. A gemini client is actually on my todo list there. I think I have everything I need to build it.

with chromatic backgrounds deserve whatever happens to them."

That's a lot of cognitive dissonance in a work about UI design. Let's try to do better in making TUIs mainstream. That requires encouraging people to use the few features terminals _do_ provide.

I've been doing a fair amount of ncurses hacking recently[1], and I prefer to always explicitly specify colors. People won't get their preferred colors by default, but they'll always get a legible configuration by default.

[1] https://github.com/akkartik/teliva

Repo