[HN Gopher] Igneous Linearizer: semi-structured source code
___________________________________________________________________
Igneous Linearizer: semi-structured source code
Author : seagreen
Score : 18 points
Date : 2024-06-25 15:44 UTC (7 hours ago)
(HTM) web link (domain-j.com)
(TXT) w3m dump (domain-j.com)
| zacgarby wrote:
| this is great! i've been thinking about exactly this (though
| styled after Logseq rather than Obsidian) but not gotten as far
| as implementing anything.
|
| that being said, the thing i haven't been able to convince myself
| of yet is why these are different to just normal (in-line)
| functions? as in, why should i have to write [[foo]]: would it
| not be better to have all identifiers automatically linked?
| fwip wrote:
| As a language-agnostic thing, I suppose you need to prevent the
| machinery from pulling in keywords and variable names
| accidentally (or the insides of strings or comments).
|
| 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.
| seagreen wrote:
| > As a language-agnostic thing, I suppose you need to prevent
| the machinery from pulling in keywords and variable names
| accidentally (or the insides of strings or comments).
|
| 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.
| seagreen wrote:
| > this is great! i've been thinking about exactly this (though
| styled after Logseq rather than Obsidian) but not gotten as far
| as implementing anything.
|
| 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.
| arnsholt wrote:
| This is neat, but it does seem like a lot of work to get part of
| the way to what a Smalltalk already gives you.
| skulk wrote:
| or emacs/org-mode
| seagreen wrote:
| I love Smalltalk, and have done a reasonable amount of messing
| around with Cuis (which is awesome and everyone should try it).
|
| 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!
| couchbed wrote:
| Lepiter is a Pharo-based notetaking app within the Glamorous
| Toolkit. I'm not sure it's mature enough to compete with
| Obsidian/etc., but it does allow linked and embedded code
| like you were thinking.
|
| https://lepiter.io/feenk/introducing-lepiter--knowledge-
| mana...
| groby_b wrote:
| Sure, but not all of us work in Smalltalk, and "but Smalltalk
| already does it" doesn't move legacy code bases either.
| JonChesterfield wrote:
| This is an interesting direction.
|
| One thought is that obsidian can execute web assembly and a
| parser / sema checker written in something that turns into wasm
| can therefore be run on the source files. Can probably tie that
| to a syntax highlighter style thing for in-ide feedback.
|
| The other is that markdown is a tempting format for literate
| programming. I do have some notes in obsidian that are fed to
| cmark to product html. With some conventions, splitting a
| literate program into executable code embedded in a html document
| is probably doable as an XML pipeline.
|
| In a much simpler vein, I'm experimenting with machine
| configuration from within obsidian. The local DNS server sets
| itself up using a markdown file so editing an IP or adding a new
| machine can be done by changing that markdown.
|
| I hope the author continues down this path and writes more about
| the experience.
| nohat wrote:
| Yeah, I definitely see using this for literate programming. Not
| quite sure the best way to organize it. Maybe use a static site
| compiler to auto host documentation version.
___________________________________________________________________
(page generated 2024-06-25 23:00 UTC)