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

Igneous Linearizer: semi-structured source code

domain-j.com

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Igneous Linearizer: semi-structured source code

#31

Post by seagreen »

thyrsus wrote: post #22
seagreen wrote: post #18

Earlier quoted context omitted.

Hazel and Unison are two of the big ones. I'm friends with some of the Unison folks so I'm biased, but I really like how few features there are in the language. In general I'm just a huge sucker for subtractive improvement: if you can have a small number of awesome things (eg abilities) instead of a bunch of special case things (exception handling, monad trickery, dependency injection machinery) sign me up. I know le…

Is this the unison you mean? https://www.unison-lang.org/ Unrelated: what has your experience been using igneous-linearizer to help understand other people's code?

That's it. And the linearizer is only one way-- you write text with [[links]] and turn that into plaintext.

Re: Igneous Linearizer: semi-structured source code

#32

Post by igouy »

ralferoo wrote: post #30
igouy wrote: post #29

Earlier quoted context omitted.

> experienced programmer who's probably happiest writing and seeing their code as a big chunks of text Not if you're a Smalltalk programmer. "ENVY/Manager augments this model by providing configuration management and version control facilities. All code is stored in a central database rather than in files associated with a particular image. Developers are continuously connected to this database; therefore changes are…

I kind of feel that we're talking at cross-purposes here. To me, whether the code is in a database, in-memory, serialised to a file isn't all that important as they're all just representations of the same AST. For me, the label "source code in database" is in comparison to "source code in linear files that need not have any inherent structure". Also, perhaps my use of the phrase "experienced programmer" is being inte…

> I'm using it as a shorthand for "experienced programmer of a traditional text-based language".

And I was telling you that experienced Smalltalk programmers don't work with "big chunks of text".

Small snippets of text, presented in context.

Sorry I'm not seeing enough clarity to wish to continue.

Re: Igneous Linearizer: semi-structured source code

#34

Post by skeledrew »

seagreen wrote: post #20
couchbed wrote: post #10

Earlier quoted context omitted.

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

Of course! I should have just guessed they'd already have something like this. 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'd say the porting is better. I've gone a ways into using GToolkit, and it has some very nice things. I especially like the infinite nesting of editors, which is like transclusion on steroids, and the driller. And it's already language agnostic and very extendable.

But when it comes to actually extending it, that's where the sharp edges start to cut. I was able to do a fairly quick, enhanced Python support extension, but one of the issues is getting proper class equivalence, and the back-and-forth passage of data is a major performance suck. Also things will grind to a halt if you push and try to process too much data at once on the Smalltalk side. Maybe having a fairly beefy machine will help with that though.

Re: Igneous Linearizer: semi-structured source code

#35

Post by thyrsus »

seagreen wrote: post #31
thyrsus wrote: post #22

Earlier quoted context omitted.

Is this the unison you mean? https://www.unison-lang.org/ Unrelated: what has your experience been using igneous-linearizer to help understand other people's code?

That's it. And the linearizer is only one way-- you write text with [[links]] and turn that into plaintext.

You may have encountered leo [ https://leo-editor.github.io/leo-editor/ ]. I use it to pull in or write code and break it up into comprehensible pieces. It works, but it feels overcomplex. I'm open to something simpler, and will give this a try.

Re: Igneous Linearizer: semi-structured source code

#36

Post by seagreen »

thyrsus wrote: post #35
seagreen wrote: post #31

Earlier quoted context omitted.

That's it. And the linearizer is only one way-- you write text with [[links]] and turn that into plaintext.

You may have encountered leo [ https://leo-editor.github.io/leo-editor/ ]. I use it to pull in or write code and break it up into comprehensible pieces. It works, but it feels overcomplex. I'm open to something simpler, and will give this a try.

I had't seen it! The "clones" feature is cool, it sounds like they're way ahead in figuring out how to use transclusions effectively when coding.

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.

Re: Igneous Linearizer: semi-structured source code

#37

Post by WorldMaker »

seagreen wrote: post #21
nohat wrote: post #12

Earlier quoted context omitted.

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.

I wish you could just use Obsidian Publish to host sites, but due to the indentation issue you have to control the rendering, which is a bummer. 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

The typical Markdown answer to needing indentation preserved is the "code fence" (triple backquotes ```), though I imagine the problem with that is that Obsidian by default stops dealing with Wikilinks inside fenced code. I don't know Obsidian that well, but maybe there's a way to use a code fence and have it support Wikilinks inside?

A different direction to explore might be to explore proportional font coding techniques that rely less on whitespace. Lisp can be a good language to play with those ideas given whitespace isn't syntactic. Though idiomatic Lisp has certainly relied on semantic whitespace in coding styles for a very long time.

Re: Igneous Linearizer: semi-structured source code

#38

Post by igouy »

ralferoo wrote: post #30
igouy wrote: post #29

Earlier quoted context omitted.

> experienced programmer who's probably happiest writing and seeing their code as a big chunks of text Not if you're a Smalltalk programmer. "ENVY/Manager augments this model by providing configuration management and version control facilities. All code is stored in a central database rather than in files associated with a particular image. Developers are continuously connected to this database; therefore changes are…

I kind of feel that we're talking at cross-purposes here. To me, whether the code is in a database, in-memory, serialised to a file isn't all that important as they're all just representations of the same AST. For me, the label "source code in database" is in comparison to "source code in linear files that need not have any inherent structure". Also, perhaps my use of the phrase "experienced programmer" is being inte…

fwiw

> big chunks of text

"Lines of Code" / "Total Methods" = 7

https://dl.acm.org/doi/pdf/10.1145/74878.74904

Re: Igneous Linearizer: semi-structured source code

#39

Post by specialist »

igouy wrote: post #27
ralferoo wrote: post #23

Earlier quoted context omitted.

I remember reading an article on Source Code In Database back in the early 2000s, and it's been knocking around my brain ever since as something I ponder every couple of years. I just can't shake the feeling that there's the gem of a future paradigm where everyone wonders "why we didn't always do it that way?", but then every time I try to follow those thoughts through to a conclusion, it always feels like it'd just…

> Source Code In Database ? https://www.google.com/books/edition/Mastering_ENVY_Develope... https://gemtalksystems.com/products/gs64/ https://en.wikipedia.org/wiki/MUMPS

InterSystems Caché has some MUMPS like qualities.

It is easily the worst developer experience conceivable. Easily tied for last place in the pantheon of turrible ideas realized thru turrible implementations.

Sure, you can bork a SmallTalk env with some ill-advised changes to the runtime.

Caché is so brittle, you can bork your env with a compiler error. And there's no feedback. And since the env is a blob, there's no version control.

https://en.wikipedia.org/wiki/InterSystems_Caché

Re: Igneous Linearizer: semi-structured source code

#40

Post by seagreen »

WorldMaker wrote: post #37
seagreen wrote: post #21

Earlier quoted context omitted.

I wish you could just use Obsidian Publish to host sites, but due to the indentation issue you have to control the rendering, which is a bummer. 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

The typical Markdown answer to needing indentation preserved is the "code fence" (triple backquotes ```), though I imagine the problem with that is that Obsidian by default stops dealing with Wikilinks inside fenced code. I don't know Obsidian that well, but maybe there's a way to use a code fence and have it support Wikilinks inside? A different direction to explore might be to explore proportional font coding techn…

> I imagine the problem with that is that Obsidian by default stops dealing with Wikilinks inside fenced code

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 .

Post reply on HN