tylr VS manifold

Not directly related, but this made me think of something I've been interested in recently - structured editors. Instead of tokenizing text and then parsing to an AST, you effectively edit the AST directly.

Since the thrust of the post seems to be about the sum of compilation + run time, it's a potentially more efficient alternative to traditional code editing. Here's an example of one in action:

https://tylr.fun/

BTW, speaking of infix, there's this pretty cool demo from some research project (not by me): https://tylr.fun/

> eco

The eco article is quite interesting, it's a cool proof-of-concept. I don't know exactly how it compares, but there's also tylr, with an online demo you can check out [1].

> The example of splitting "Hello world" into a list of words is a pretty bad example;

I just wanted to set up some very quick easy-to grasp context with it for the discussion that follows. You are right, of course, the normal editors don't have much trouble with that level of detail. Maybe I will come up with something better later on, though not too complex...

> I'm currently working on knowledge management, which I think you have to split in different subfields;

My view on this is that you can't generally predict that, but what you can do instead is let the user compose the structure and features of custom documents, thus creating custom workflows suitable for the task at hand, whatever it may be. I will be generally taking that approach with Kraken.

> literate programming

I think computational notebooks take the core idea and make it practical, and I think it's fair to say those are literate programs, albeit without the web-tangle aspect.

> Again, good luck etc.

Hey, thanks for the feedback!

[1] https://tylr.fun/

Considering the Amount domain types, I like the manifold project’s unit expression[1] approach where the unit and domain type are integrated and always reconciled.

1. https://github.com/manifold-systems/manifold/tree/master/man...

> I am glad to see a project that provides a robust and elegant API for building rest services in Java.

Alternatives for _consuming_ REST services is perhaps an equally interesting proposition, particularly since there are potentially potentially many consumers per service e.g., the manifold JSON project[1].

Other areas where Springboot feels overbearing include JPA/ORM support. In my view this is its greatest weakness, but like the "no one ever got fired for buying IBM" cliche, the same can be said today about Springboot.

1. https://github.com/manifold-systems/manifold/blob/master/man...