You can try - I certainly did - but it's inferior, in nearly every way: performance most of all, usability, interfacing with the host OS, availability of libraries, APIs, interactive documentation, discoverability, customization..

The fact that Emacs has been in use (for decades) as a tool aimed at primarily solving everyday problems, means that it's been optimized for practicality to a ridiculous extent. That's not the case with Squeak, since it still has a very strong academic/research focus and a much smaller userbase than Emacs.

That's not to say that Squeak is useless, I'm a hardcore Emacs user and I do use Squeak too, but it's nowhere near as practical. It does however offer by far the best environment to experiment with Smalltalk and image-based development.

On the other hand, I don't recommend Pharo, as I found it even less practical than Squeak with frequent braking changes and a -seemingly- complete lack of focus that has pulled the project in widely different directions over the years. At least, Squeak is cohesive and hasn't broken with Alan Kay's vision.

> On the other hand, I don't recommend Pharo, as I found it even less practical than Squeak with frequent braking changes and a -seemingly- complete lack of focus that has pulled the project in widely different directions over the years. At least, Squeak is cohesive and hasn't broken with Alan Kay's vision.

Nonsense! Pharo's focus is to make writing Pharo more Pharo and easier for Pharo users. Mind, if your app isn't a Smalltalk VM and IDE, then, yea, it's full of tumult and turmoil. Aren't they on their 3rd or 4th GUI toolkit rewrite now? I mean, credit where credit is due, they eat their own dog food to be sure, but as a meal, that's just not as inviting to others.

  > At least, Squeak is cohesive and hasn't broken with Alan Kay's vision.

what are the big differences between squeak and pharo?

There is a Glamorous Toolkit (Pharo not Squeak) project called Lepiter that is conceptually similar in a lot of ways to org-roam and org-babel. It comes with support for working with Javascript and a couple other languages. That might be of interest depending on how you spend most of your emacs time. (I agree that in a dream alternate reality something like full-on emacs would have grown out of Smalltalk.)

I once worked with a guy who did all his coding in Squeak the way some do in Emacs.

He shipped enterprise code this way. Implementation language was Perl.

This man must make some videos.

That's wild. I've been wanting to do the same thing with Ruby for years.

Well, that makes sense, since Ruby is the cronenberg that emerged from mashing Perl and Smalltalk together...

If Ruby had ever come up with a Pharo-like coding environment then I would have already done it. But just trying to find a simple-enough editor written in Ruby to build on is tough.

That seems incredibly odd lol. What advantage does that have over Notepad++?

Presumably he could write his own code- and data-munging tools in Smalltalk and invoke them straight from the running image -- kinda like what you can do with Emacs Lisp.

That's fascinating. At least Emacs comes with an editor, can't say as much for Squeak. I mean, it has AN editor, its just not very good compared to something like Emacs or vi, and I'm talking editor functionality, not everything else. It's more like a lightly enhanced Text Area.

But maybe he put a lot of work into it to be a better Perl editor.

That was my point as I'm familiar with Smalltalk and Emacs/Vi.

For them, presumably the same thing that emacs has over Notepad++ for me (though not IDEs, universally, just most editors). Emacs (as an environment) is almost fully extendable in user code with much greater ease than most other editors. And not just in a "write this plugin, place it in the right directory, and restart the editor" sense. In the more extreme sense of you can extend it live, even just temporarily. Squeak, as an environment, is very similar to that experience, probably even more extreme than what emacs offers in some ways. If it had a larger community behind it (to use in this style), I'd certainly entertain it.

Its not keyboard driven enough.

I feel that every time I reach for the mouse a kitten dies in some distant universe far far away.

With Emacs I am less concerned with editing than managing my work related data and work flow, and still think Smalltalk is better for it. I see myself getting back to Smalltalk after I get some more experience with Emacs.

Both Emacs and Smalltalk though are in serious need of native SQL or some kind of good database support not for applications but managing the workspace itself. You can only get so far with plists, collections, hash tables and what nots.

Even the org-roam guys have switched to SQLite to manage the data.

That's a thought that pops up regularly whenever I run into Pharo/Squeak. They seem to have a more homogeneous system from top to bottom. The graphical layer of emacs is really "small" and restricted.

I have not seen Squeak (or other Smalltalk environments, e.g. Pharo) being used like and IDE, which is what I infer you mean by "developer... emacs replacement".

It certainly seems possible and could potentially make for a great IDE foundation, I just haven't seen it done, other than the Glamorous Toolkit - https://gtoolkit.com

Interesting statement, given that modern IDEs trace back to Lisp and Smalltalk graphical workstations.

Clarification: I meant using those environments for other languages, like people do with emacs, which is what I inferred the person I responded to was asking.

Was that how IBMs visual age products were?

IBM Visual Age C++ on OS/2 installed an extension dll for the system Notepad to add syntax highlighting and jump-to-error, among other IDE features.

In 1991-ish, it was very cool to me.