Igneous Linearizer: semi-structured source code
domain-j.com
Igneous Linearizer: semi-structured source code
1–10 of 42 posts
Re: Igneous Linearizer: semi-structured source code
#2that 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?
Re: Igneous Linearizer: semi-structured source code
#3this 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?
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.
Re: Igneous Linearizer: semi-structured source code
#4Re: Igneous Linearizer: semi-structured source code
#5This is neat, but it does seem like a lot of work to get part of the way to what a Smalltalk already gives you.
Re: Igneous Linearizer: semi-structured source code
#6One 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.
Re: Igneous Linearizer: semi-structured source code
#7This is neat, but it does seem like a lot of work to get part of the way to what a Smalltalk already gives you.
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!
Re: Igneous Linearizer: semi-structured source code
#8Re: Igneous Linearizer: semi-structured source code
#9this 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?
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.
Re: Igneous Linearizer: semi-structured source code
#10This is neat, but it does seem like a lot of work to get part of the way to what a Smalltalk already gives you.
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…
https://lepiter.io/feenk/introducing-lepiter--knowledge-mana...