Seems like the argument is in the "Rune" part even more down below. I think it boils down to having specialized editors which you embed, and to a common interface that you may define over that. The point on ambiguity localization is kind of curious too.

I don't think there's an argument to be had for all structures, just that you can do it for each custom structure, and that's the point.

Maybe the editors of the old tried to bite off too much when they attempted embedded structures, and they didn't have the right abstractions in place. If you look at https://tylr.fun it shows that things that weren't being done back then, there are interesting approaches now.

> I think it boils down to having specialized editors which you embed, and to a common interface that you may define over that.

Emacs modes, in other words?

Like how, in Emacs, C-n nearly always does "move to next line" but it could mean "highlight next mail message" and "Enter" nearly always does something with the current line but it could mean "open currently highlighted message" or "newline and indent as per language-specific rules" or "send this line to a subprocess" or whatever.

Modes don't do embedding. Try having a fully-seperate mode for a comment section in your code. Try to do that contextually, too.

Modes don't do that. Neither do they let you control the underlying structure, they give you no ability to treat structures as objects. Yes, they do provide a common interface, but that's where the pros end. Ofc its emacs, and there are projects like Multi-Major-Modes that at least try to subdivide a document into editable areas... speaking of ridiculously slow.

> print debugging

Curiously:

https://project-mage.org/overcoming-the-print-statement

> general

You keep using that word. I do not think it means what you think it means.

I am perfectly aware what that word means, and it is exactly the word I wanted to use. Instead of being a condescending asshole, perhaps you can explain what you disagree with.

Soviet products might not have been very pretty, but they were made with durability and, indeed, quality in mind. The electrical components from the Soviet era are still working. Any mechanical/metallic stuff is very solid.

Yeah, designs were utilitarian. And they had to make a million of everything. But there was no good reason to aim for low quality.

Counter that with any product of capitalism, huh: buy a shiny thing and wait for it to break in 2 years.

Not trying to glorify communism, but what you said in your comment is complete bullshit mixed with questionable sentiment.

I remember how I did something similar back in 1983...

This is my favorite comment. Not even close.

... in Org Mode ...

> python

> last forever

whatever you say.

... and God granted zoomers homoiconicity, macros and parenthesis.

"No," said the zoomers, "we want to write XML, build scaffolding tools and eat shit."

"Your language will never be a LISP," was the God's reply.

I'm clueless. How do these fix the scaffolding problem?

If I start a new Python project I have a short checklist I go through

1. Poetry (dependency management) 2. pyenv and pyvirtualenv (execution environment management)

Just these two are somewhat of a headache to get going. Once they're up, though, they do the job they're supposed to in an admirable fashion.

How would a language with homoiconicity and macros handle this?

I am not too knowledgable about Python to tell you exactly.

But let's take Common Lisp for an example and why I don't feel the need for a scaffolding tool. Well, actually I do need _some_ very basic scaffolding, namely: create two directories called src and tests + add two very short project files with my names and project names embedded in them, along with a couple of package files. Nothing fancy and certainly nothing that's particularly problematic. Everything that's part of the project code (such as package description with imported symbols and such) maybe be done by using a macro from an external library (ex: certain functions of some library that I import in each of my projects).

But you are right anyway, not everything is a language-specific problem here, only the stuff that gets repeated in code, from one project to another. In CL that includes documentation and the testing framework (from the article's points). Well, the build/project description is just a macro too. Anyway, I didn't mean to diminish the major points of the article in any way. The author is right about the fact that generators are not aware of the user's changes and that can be problematic at times (as with his license and license metadata example).

Does it come from somewhere or you just made that up ? I have a really strong feeling of déjà vu but cannot figure out from where.

you may be thinking of rootless root, ESR's zen koan styled thoughts on software http://catb.org/~esr/writings/unix-koans/index.html

I just made it up. But I guess we both must be reading the same kind of memes or something.

I bet we could figure it out based on bot activity we see across social media. Same explanations given with similar language. Given this is HN, I imagine it is straightforward to train an AI to figure this out.

> If you change your processes too much it is hard to built up an identity other than as someone who is inconsistent.

nah

and why should consistency matter across songs anyway, unless you are writing a concept album?

What do you mean?

Just checked and this is still a problem. Try this code with Iterate:

  (let ((list '(1 2 3 4 1 2 3 4))) ;; or whatever other sequence
    (iter (for i from 1 to 10)
          (sum (count i list))))

It will error out on you. The same works fine with loop:

  (let ((list '(1 2 3 4 1 2 3 4)))
    (loop for i from 1 to 10
          sum (count i list))) ;; => 8

Now, that's a bit contrived as an example, but an iteration library should not break a standard library function call.

https://gitlab.common-lisp.net/iterate/iterate/-/issues/12 - Apparently it's known and they intend to remove it in 2.0, which isn't out yet.

good to know, thanks