seagreen

So I'm a believer in the principles. But I'm also curious about throwaway743950's question. What are the things in the Glamorous Toolkit that concretely make it better for this style of programming than traditional tools? You say "[it] just happens to be a nice system of tools that make it easy to make more little tools", but that's got to be downplaying it. Switching environments is an agonizingly costly thing to do. What rewards await those who make the jump? Rubies? Emeralds? Custom views-with-nested-sub-custom-views? Curious (but not yet won over) readers want to know.

> unordinary direction

Hahaha, this is a very polite way to put that=) But I do appreciate it.

Exactly. Interestingly enough autocomplete is still triggered by [[ inside of a code block which is kind of funny. So writing code blocks works fine, it's just that they won't display with links.

> A different direction to explore might be to explore proportional font coding techniques that rely less on whitespace.

I'm definitely open to proportional font coding techniques being interesting, but in this case with all leading indentation unusable I doubt they'd be enough to get a normal experience. Unless you only write assembly so you can stick to the left margin <taps forehead>.

Previously I'd thought of using transclusions for things like long-lived documentation. Now reading about Leo it seems like they'd be just as useful for creating short-term views into one's code. Eg start a refactor PR by transcluding all the relevant definitions into a doc. Now you can start writing PR comments in that doc before you even begin coding, and when you do all the relevant code is right there.

Obsidian Digital Garden[1] is FOSS, so it might be modifiable parse and output the code pages correctly.

[1] https://github.com/oleeskild/obsidian-digital-garden

We either need to port ALL of Glamorous Toolkit to mainstream langs or we need to convince all our employers to switch to Smalltalk. I am not certain which of those is possible or easier.

I appreciate it=) I definitely want to write some more stuff up, in particular how code organization changes when you can tag and add attributes to definitions.

I know less about Hazel, my understanding is that it's source-code-in-CRDTs, which is definitely structured source code though may not technically be in a database.

Exactly. But zacgarby's right that you would want some auto-linking, so this is where language-specific plugins come in.

The difference from today's world would be that those plugins would leave their results explicitly serialized in the source medium, so they wouldn't have to keep being reconstructed by every other tool.

> I like the idea (also a fan of Unison's approach to code-in-the-db), but I worry about the potential issues that come from effectively having a single global namespace. Could be that I just don't have the discipline for it, though.

I have lots of thoughts on this. I was initially disappointed that Unison kept a unique hierarchy to organize their code-- that seems so filesystem-ey and 1990s.

However, I'm now a convert. The result of combining a unique hierarchy with explicit links between nodes is a 'compound graph' (or a 'cluster graph', depending, getting the language from https://rtsys.informatik.uni-kiel.de/~biblio/downloads/these...). These are very respectable data structures! One thing they're good for is being able to always give a canonical title to a node, but varying what that title is depending on the situation.

I think that for serious work the linearizer would want to copy this strategy as well. Right now it's flat because that's all I need for my website, but if you were doing big projects in it you'd want to follow Unison and have a hierarchy. In the `HashMap` folder you'd display `HashMap.get` with a link alias that shows plain `get`, but if that function is being called from some other folder it would appear as the full `HashMap.get`.

You could still do all the other cool stuff like organize by tags and attributes using frontmatter, but for the particular purpose of display names having a global hierarchy is useful.

EDIT: What matters more than what the linearizer does is what Obsidian displays, so it's there that the "take relative hierarchical position into account when showing links" logic would have to occur. That could be a plugin or maybe Obsidian's relative link feature, I haven't used the latter.

Thank you! I think [[links]] will work out of the box with Logseq since they're the same as Obsidian. Transclusions will be in the wrong format since Obsidian transclusions look like `![[this]]`, but it would be quick to modify the linearizer to handle them.

You may not want transclusions though since transcluding code into other code is... very weird. I'm curious what use cases people come up with for it though.

However this gives you two things that Smalltalk doesn't:

1. It's language agnostic (boring I know)

2. It promotes keeping your code and written texts in the same system where they're both first class. That way they can link between each other, transclude each other, be published together, be organized the same way, etc. I really think this is the most interesting thing about the project, it really feels important to me.

Caveat: right now my written documents can link to/transclude code, but it doesn't work the other way yet. This is because the linearizer will see a link from code to documents as another definition and try to jam it in the source file. This would be an interesting use case for typed links, but Obsidian doesn't a have them AFAIK. Kind of cool since I haven't seen many other use cases for typed links in the wild.

EDIT: It occurs to me that I've never used a Smalltalk notetaking or word processing program. Are there any that are integrated with the System Browser, so that they can link to (or even better embed) code? If anyone has more info please let me know!

> Circuit switched analog POTS has been dead for a long time, but delays were limited to amplifier delays (almost nothing) and speed of light in wires or radio.

Two questions about this: it sounds like there are still a fair amount of landlines around if this article is accurate: https://www.cnn.com/2024/02/05/tech/landline-phone-service-p... Do you mean that people still have landlines, but they're no longer circuit switched analog? And would that only be for long distance, with local landline calls still using circuit switched analog, or would it be for both?

Also, as to your latter point about old school POTS having almost no delays other than speed of light: does that hold for long distance calls as well? I get the impression that there could be added latency for long distance POTS calls (but have had trouble finding sourced numbers on anything yet).

I often find the best way to understand complex things is to dig all the way back to when they were being thought up. In this case there's a blog post from 2017 that I still find useful when thinking about Unison:

https://pchiusano.github.io/2017-01-20/why-not-haskell.html

Key quote:

Composability is destroyed at program boundaries, therefore extend these boundaries outward, until all the computational resources of civilization are joined in a single planetary-scale computer

(With the open sourcing of the language I doubt it will be one computer anymore, but it's an interesting window into the original idea)

Personally I find there's a lot to this. It's interesting that we're really, really good at composing code within a program. I can map, filter, loop and do whatever I want to nested data structures with complete type safety to my heart's content. My editor's autocompleting, docs are showing up on hover, it's easy to test, all's well.

But as soon as I want cron involved, and maybe a little state-- this is all wrecked. Also deployment gets more annoying as they talk about a lot.

So I think Unison always had to have a platform to support bringing this stuff into the language, even though they built the language first.

I'd love to hear some opinions from outside Unison about how they like using this language, tooling and hosting.

I'd like to hear this too.

Also, it would be great if there was something like https://eugenkiss.github.io/7guis/ or https://todomvc.com/ for platforms that we could use to compare Unison, AWS, etc etc. Or is there already a 7GUIs for platforms that I don't know about?

That's a useful distinction and a good term.

So in total projects can be classified as:

    - Source available or not
    - Open source or not (a subset of source available)
    - Open contributions or not (also a subset of source available)
    - BDFL or community driven

PS: Regarding:

> 1: Yet hell will freeze over before Github lets maintainers turn off the PR tab which would lessen this problem a bit.

I wish there was a standardized way of declaring this, I always feel so awkward writing the "no PRs" disclaimer on my toy projects.

Sidestepping the meaning of the word "theft", our situation is as follows. There are 3 ways to finance intellectual work:

    1. $
    2. ads
    3. nothing (and rely on gift-style work)

EDIT: I should note that I don't think the anti-copyright movement was bad during its time. They were definitely on the right side of things like Authors Guild v. Google. But I think the internet economy has gotten more mature and we now need more nuance than they provided.

    On July 3, 1940, as part of Operation Catapult, Royal Air Force pilots bombed the ships of the French Navy stationed off Mers-el-Kébir to prevent them falling into the hands of the Third Reich.
    This is Austral’s approach to error handling: scuttle the ship without delay.

I was more asking about the tactics of the situation since it seems really different than the modal "would anyone even want this?" startup. It does seem like "show don't tell" is a good move.

1. Company starts to do X, makes it a wonderful experience

2. Users love it, it's successful

3. Company stop treating users well

4. New company steps into make X a wonderful experience again, with the advantage that the market is pre-validated.

How much of an advantage is it to know that users want what you're creating? Do you have any tips, like ways to reassure people you won't follow the same dynamic as the original company?

One question I have is which of these are fixed across Unicode standards.

(a) Byte count for storage and (b) code point count are definitely fixed, Unicode provides an explicit guarantee of the latter: https://www.unicode.org/policies/stability_policy.html

(c) Visual width will change depending on the system.

But what about (d) grapheme count? If I make a microblogging site which limits post length to 144 graphemes, can my database invariants break when I upgrade my version of Unicode?

Eg take web forums (not this one since there's weird lisp stuff down there and I don't know how it works, but the average web forum).

On the app (server) side they have access to everything, all of your posts in nice beautiful structured SQL.

On the user side you have access to none of that, just HTML soup and maybe some cached stuff in the "Storage" tab, or maybe not.

> Albeit the convention is clearly to not presume your browser app user will be interacting with their data at _all_ through the devtools, which I find regrettable but unavoidable with the current state of "computer literacy" and the state of "devtools-as-an-interface" (obviously the ergonomics aren't great for the average user today).

I really like your use of "convention" and "presume" here, because I think that's the essential lens to view these things through. It's absolutely possible for an app to provide all of a user's data in a nice structured form in IndexedDB, that will just be rare because it's not the convention.

This is incredible!

> enough maturity to implement essentially an entire operating system / virtual machine AS the browser

Yes, an operating system-- but one without user-facing persistence! Only per-application, networked, silo'd persistence, where the user sees a rendered form of data but not the data itself.

IMHO these two facts, that

a) Web browsers are BETTER than Linux, Windows, etc as an OS in a very important way, package management

and

b) They're missing one of the primary features of an OS, persistence

overshadow any other facts about them. What a strange tool they are.