Comment by JonChesterfield | Hacker News Reader

Comment by JonChesterfield | Hacker News Reader

JonChesterfield

Flexibility interacts poorly with composability. When everything is specialised at the whim of the developer, tying different pieces together is difficult. A lot of the rigidity in programming languages is there because it gives programmers (and programs) common ground to work from.

Flexibility usually interacts poorly with performance as well. Specialisation to a domain is usually faster and can be dramatically faster, but the plumbing that makes the specialisation possible has a cost everywhere.

I'm curious whether lisp's macros are sufficient to splice together dissimilar code and provide the domain specific optimisations one would want to eliminate the plumbing overhead. I would expect not but it'll be interesting to be proven wrong.

It's interesting that you're starting with the user interface instead of the sufficiently smart compiler. "I'll rebuild the world in lisp" projects sometimes (usually?) stall in the first stage of writing their compiler. I think it's quite encouraging that you're building on an existing language implementation.

That would be a lot to build in five years. Good luck and happy hacking.

> Flexibility interacts poorly with composability.

> Flexibility usually interacts poorly with performance as well.

I disagree fundamentally. I believe there's such a thing as the flexibility of specialization.

In fact: the reason why everything is so slow is because we don't have /enough/ flexibility in our systems.

https://project-mage.org/on-flexibility

> It's interesting that you're starting with the user interface instead of the sufficiently smart compiler.

I think it's because I care more about the applications than anything else. Yes, they require the platform, but my motivation is to get something I can use, not just to build a tool.

> That would be a lot to build in five years. Good luck and happy hacking.

Thanks : )

I've been reading the The Power of Structure in chunks. Your Rune section was really beginning to sell me, but I'm confused about something.

I'm trying to imagine my existing Notes as a tree of objects instead of text parsed into an ad-hoc tree. Ok, that sounds good. I could imagine a leaf node being a "blurb", which itself could be something easy and familiar like a string. I could imagine it sitting beside a table, and nested under a bullet point.

I can imagine my up/right/left/down keybindings getting smarter, as I move from "left" or "outside" of a table then it might highlight itself, indicating that I'm selecting it like I would select any heading and can drill down into it.

I can imagine instead navigating up, to the text, and there being a seamless transition so that I'm editing that text just like I normally would in Emacs.

I can imagine navigating "out" and into the tree structure of the bullet points / headings. I already use packages to easily navigate my headings, and so I like the idea.

But when I read this:

> See, even words have structure. Are words objects? We wouldn't have a word for them if they weren't significant somehow. And that's how I would want to analyze and work with them: as words. For the plain text editor, a word is just a cluster of characters somewhere in a string, and there's a whole pile of mess built on top of that string to convince you otherwise.

and this:

> Your word was supposed to be an object that carries information about itself.

I start to worry about performance. Is this something like the old Flyweight Pattern from GoF? Is this level of granularity no longer expensive?

Good question. (Incidentally, it provides a good example for my words in the comment you have replied to.)

Words could be objects. But I will tell you more: you can start breaking words into characters and making them objects too, if you needed to. The key to performance here is to do the necessary stuff on the fly, on demand, dynamically. In other words, the word may become an object only when it needs to become a seperate entity. Suppose you use some data structure for storing sentences or paragraphs. Let's assume it's just a list. So, before a word needs to become an object that stores some information about itself, it can just be a string:

    '("This" " " "is" " " "a" "sentence" ".")

Now, if you wanted to tag the word "This" with some info (like stylization), you could turn that word into a more complex object:

    '(("This" :style bold) " " "is" " " "a" "sentence" ".")

In fact, if your application requires such an optimization, you could even store it as a simple string

    "This is a sentence."

You can choose whatever storage unit you like, as long as you can make your editor work with it. Structural approach allows specialization on the fly, you can just adapt to the granularity when you need it, since there's just full programmatic access.

Do you have examples of other "rebuild the world in lisp" projects? I'd be curious to see how and why historical attempts have foundered

Not great examples. Hazy memories of readme files for projects that sound interesting but fizzle out, sometimes decades ago.

Emacs is probably a success story in that genre. It's possible to use it as the first process booted iiuc. I certainly have days where it's the only process I run after gnome has booted.

Guix has replaced a lot of Linux userspace infra with scheme. Successfully as far as I can tell.

I think there are (non-emacs...) operating systems in various states of progress written in lisp.

Sometimes one finds a compiler written in lisp which doesn't have a runtime in C. Jitawa, Maru are the only two I know of. All the others I've looked at seem to be built on top of C. I think they're both finished/abandoned.

My rebuild everything project is still in the better compiler phase so I might be projecting. Hopefully I'll remember better anecdotes later.

Medley interlisp appeared on HN a few days ago.

https://journal.paoloamoroso.com/my-encounter-with-medley-in...

Reply on news.ycombinator.com