Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Smalltalk Squeak 6.0

raw.githubusercontent.com

Post reply on HN
Print view View original

31–40 of 73 posts

Re: Smalltalk Squeak 6.0

#31

Post by Jtsummers »

7thaccount wrote: post #17
bitwize wrote: post #14

Earlier quoted context omitted.

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.

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

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.

Re: Smalltalk Squeak 6.0

#32

Post by vfclists »

guessbest wrote: post #8

Could a developer use Squeak as an emacs replacement?

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.

Re: Smalltalk Squeak 6.0

#33

Post by musicale »

Shouldn't this be Squeak Smalltalk 6.0?

I'm glad that Squeak continues to embrace the Smalltalk name, community, and history - and doesn't take the Pharo approach of trying to pretend that they aren't Smalltalk.

Re: Smalltalk Squeak 6.0

#34

Post by whartung »

metroholografix wrote: post #28
guessbest wrote: post #8

Could a developer use Squeak as an emacs replacement?

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…

> 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.

Re: Smalltalk Squeak 6.0

#35

Post by whartung »

bitwize wrote: post #29
7thaccount wrote: post #17

Earlier quoted context omitted.

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.

Re: Smalltalk Squeak 6.0

#36

Post by andrekandre »

metroholografix wrote: post #28
guessbest wrote: post #8

Could a developer use Squeak as an emacs replacement?

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…

  > At least, Squeak is cohesive and hasn't broken with Alan Kay's vision.
what are the big differences between squeak and pharo?

Re: Smalltalk Squeak 6.0

#37

Post by vinceguidry »

bitwize wrote: post #30
vinceguidry wrote: post #20

Earlier quoted context omitted.

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.

Re: Smalltalk Squeak 6.0

#38

Post by andrekandre » 

  > This is the first Squeak that supports high-resolution displays on all major platforms and offers a flexible UI scale factor through improved support for TrueType fonts.
nice, been waiting for a while on that one

Re: Smalltalk Squeak 6.0

#39

Post by igouy »

Rochus wrote: post #15
kabdib wrote: post #11

Earlier quoted context omitted.

Don't know if it's true, but it makes a fun story: ST80 used reference counting with counts saturating at some low number (like 127), and of course there are problems collecting circular references. A comprehensive analysis of a modern image, with Xerox PARC lineage, discovered garbage that had been uncollected for 20-30 years.

It is true, that there is uncollected garbage in the original Xerox ST80 image. I've built some tools to analyze the image and also a VM which can be interrupted at any time to analyze the current state of the image (see https://github.com/rochus-keller/Smalltalk ). There are two zombie processes (OID 6662 and 19ba). There are also a couple of BlockContext and MethodContext which have a nil sender and a reference to…

Is there uncollected garbage in the Smalltalk Squeak 6.0 image?

Re: Smalltalk Squeak 6.0

#40

Post by igouy »

Rochus wrote: post #25
floren wrote: post #22

Earlier quoted context omitted.

It's things like this that always made me look a bit askance at Smalltalk. It feels a little like "Document_Final_FINAL_v3_(2).docx", a little like a dirty old whiteboard where you can still see outlines of notes from last year. Might not be a fair assessment, but as an outsider I've always felt this way about image-based systems.

Deploying an application was always an adventure. You could never be completely sure that it didn't contain things it shouldn't.

For some meaning of "contain things it shouldn't":

Given that the base image we started working with didn't "contain things it shouldn't" why could we not be completely sure that base image + source code fileIn didn't "contain things it shouldn't" ?

Post reply on HN