ferocity VS marshal.ts

The advantage of the static import DSL is that it is more composable: anyone else can define operators that interoperate with my operators without the complexity of the scheme linked above not to mention more generality. This goes not just for the low level operators like "filter" that you might want to supplement but the many more operators you can write that are implemented out of mine.

I prototyped an API that works in the same direction as streams by having something like

https://paulhoule.github.io/pidove/apidocs/com/ontology2/pid...

in that it wraps all Iterables returned by my methods and has not just the teardown facility but also all the operators attached as instance methods which lets you write the chaining style you ask for that I know is in demand.

If I was going to go any further on pidove it would have involved more use of code generation and this system

https://github.com/paulhoule/ferocity

which was supposed to be a code generator for writing code generators, and it could code generate stubs that would let you write expression trees in Java as S-expressions and build them up into methods and either compile the code to real Java source code or execute the methods by evaluating the expression tree in place.

Like common LISP you can write syntactic macros in that that metalanguage because an Expression> can be evaluated at compile time, one of quite a few concepts like "quoting" that I encountered in that spike.

The idea was ferocity would get to the point where it synthesizes a more complete and perfect pidove.

but you can't have an overload that takes two differently parameterized expressions, this lets you write Java code in a lisp-like syntax that can be metaprogrammed on:

https://github.com/paulhoule/ferocity/blob/main/ferocity-std...

that project got me thinking a lot about the various ways types manifest in Java and I made the discovery that when you add Expression types you practically discover an extended type systems where there are many things that are implied by the existence of ordinary Java types.

I find this alien to my point of view. On the other hand, my side projects aren't driven by FOMO but are more like the "special interests" of autistic people.

Most of the time I have three side projects going on, maybe two of which are really getting the attention they deserve and one that is languishing. (See my profile to see about my current three.) Occasionally I get inspired to spend 1-4 weekends on some sudden inspiration, of which

https://github.com/paulhoule/pidove

came to completion but

https://github.com/paulhoule/ferocity

probably won't. The project I'm working the hardest on now is something that I was baffled that it didn't exist 18 years ago but felt compelled to do something out because of the Twitterinsanity last December and it turned out the technological conditions right now make it the perfect time to work on.

I have hacked off and on on this

https://github.com/paulhoule/ferocity

which lets you write extended Java in a lispy syntax. It generates stubs for the standard library and other packages you choose, unerasing types by putting them into method names. It works pretty well with IDEs but there are still problems w/ type erasure such that some kinds of type checking can't be done by the compiler working directly on the lispy Java, probably I wouldn't implement newer features such as pattern matching that are dependent on type inference to work, though lambda definitions are feasible if you give specific types.

The 'extended' bit was almost discovered instead of invented in that it is pretty obvious that you need quote and eval functions such that you can write lispy Java programs that manipulate Java expressions. Said expressions can be evaled at runtime with a primitive interpreter or incorporated into classes that are compiled w/ Javac. The motivation of the thing was to demonstrate Java-embedded-in-Java (an ugly kind of homoiconicity) and implement syntactic macros from Java which I think that prototype proves is possible but there is a lot more to be done on it to be really useful. Enough has been implemented in it right now in that you can use it to write the code generator that builds stubs. It might be good for balls-to-the-walls metaprogramming in Java but I think many will think it combines all the worse features of Java and Lisp.

There is this project

https://github.com/paulhoule/ferocity/

which I might finish up when I'm done with the report I'm writing. It is possible to create Java expression trees with trees of static method calls that look a lot like S-expressions and stick them together into statements, methods and classes.

You should be able to do the same tricks people do with LISP macros and it could work code generation miracles but it would have that "LISP curse" problem in spades.

The plan is to generate a code generator that is sufficient to generate the full DSL implementation (ferocity0) and use that to generate the full implementation (ferocity.)

I have some tests for ferocity0 writing .java files to get fed to javac and for ferocity0 running expression trees with a primitive interpreter. Already the type system is enriched over the type system because interpreted ferocity0 can handle Java expressions as a type at run time so you get issues like quoting and unquoting in LISP.

Internal or external?

I think Java is just fine for internal DSLs, see

https://www.jooq.org/

I was also hacking on this project

https://github.com/paulhoule/ferocity/

which was about making Java homoiconic. Namely in ferocity you can write

   Expression literal = of("Hello World");

You could process that Expression in a few different ways, for instance you could evaluate the tree using reflection or you could turn the tree into source code and compile it with javac.

Going down that path I found it was more about discovery rather than invention. That is, you will discover the issues that come up around quoting in LISP and develop some answers to them. Also for the exercise to be interesting at you will get into an execution model that is a bit bigger than the original language : for the metaprogramming to be fun at all you want to be able to write Expressions that manipulate Expressions so you end up introducing types that don't really exist in the base language. These are almost trivial to handle using the primitive interpreter style but could be more of a challenge to compile to source code.

Some source code is here

https://github.com/paulhoule/ferocity

It's been a long time since I worked on it and I need to see if I have more notes explaining the plan behind it, but the idea was to develop "ferocity0" which was a version of the DSL that was good enough to build stubs for some of the language and a large part of the standard library, and then use code generation techniques to create "ferocity1" which would be like "ferocity0" but would cover 100% of the Java language.

My current side project is being sidelined by supply chain problems so I might go back into that one.

zod or yup gets you quite a bit of the way there in practice - when you would reach for a Typescript type, making it in zod instead is more verbose but gives that runtime layer.

But for those who actually want full-stack non-stripped runtime type reflection based on Typescript syntax alone... https://deepkit.io/ - https://deepkit.io/blog/introducing-deepkit-framework - is a really promising and cool project.

It patches the typescript compiler (which pointedly considers runtime type information out of scope) with its own type compiler that emits a bespoke bytecode that is executed in a bespoke VM to communicate runtime type information to both server and client as needed. https://docs.deepkit.io/english/runtime-types.html

And from that baseline, there are very cool things you can do like an ORM entirely based on type annotations https://docs.deepkit.io/english/database.html or strongly-typed RPCs https://docs.deepkit.io/english/rpc.html .

It's very much in the alpha stage, but it's really well thought out - there's a tremendous degree of care the developer is taking towards code cleanliness and developer experience. I'm torn between wishing this project to have a fully funded team and take the world by storm, vs. "letting them cook" so to speak and seeing the developer experience unfold organically. Either way, it's a breath of fresh air into the Typescript ecosystem!

Deepkit (listed in the article) is a fascinating project and really deserves to be more popular.

It also demonstrates that what is being asked for is actually practical.

https://deepkit.io/

Checkout deepkit One of the things it has is a really fast BSON parser, that is faster than the JSON one to my understanding. Interesting work with TS types too

Hello HN community! I’m one of the founders of Magma, a multiplayer art platform. You might recall our earlier post (https://news.ycombinator.com/item?id=30869131), and today we’re sharing a significant update with our artist-focused, multiplayer AI assistant, a first in the realm of collaborative creative tools. Hope you’ll like it!

See how it works in this YouTube video: https://www.youtube.com/watch?v=ZESJfjwxLjk. For in-depth understanding, here’s our documentation (https://help.magma.com/en/articles/6711598-beta-ai-assistant) and our AI manifesto (https://magma.com/aimanifesto) which is a guiding document for us.

We're inviting you to get hands-on with this new feature. Join any of these canvases (up to 50 live contributors each): https://magm.ai/qnss, https://magm.ai/ei74, https://magm.ai/38mr, https://magm.ai/z1ti, https://magm.ai/zdub, https://magm.ai/ed93, https://magm.ai/1l84, https://magm.ai/xvu5, https://magm.ai/gd9j, https://magm.ai/pu6e. All of these canvases have extra feature flags enabled but if you’d like to go beyond them, feel free to join our beta community https://magm.ai/magma-beta-artspace-invite

Our artist-first approach is rooted in our belief that human creativity should remain the heart of artistry. With our AI handling routine tasks, artists can focus on true creativity. Importantly, our AI preserves artists' copyright as it provides a clear distinction between human-generated and AI-generated content.

Beyond just art, Magma is a powerful tool for game dev and animation, offering powerful design & review tools for all stages of the creative process. Our Slack/GDrive-like workspaces (we call them Artspaces) expose API and even shell tools. One can even render any artwork in the terminal. :)

Technically speaking, our collaborative drawing engine is powered by Typescript, Node.JS, WebGL, with a hint of WebAssembly for hand-optimized performance that even Chromebooks can handle. The backend also leverages a high performance Typescript Deepkit Framework https://deepkit.io

Our AI assistant runs on a worker-based architecture akin to Gitlab CI workers, currently leveraging Stable Diffusion 2.1. Future developments will allow connecting your own AI worker, training custom models within Magma, and plugging in API keys from other AI backends.

Feedback, questions, thoughts? Let's discuss! Happy creating with a helping hand of AI!

P.S. A shout-out to the HN community, our last post here helped us connect with an amazing technical angel investor who has made significant contributions. Looking forward to more such productive connections!

Take a look at restfuncs then. Or deepkit or telefunc.

Both work out of the box very well with Deepkit. You can either construct your own types in runtime or mix TS types with runtime information. See for example https://github.com/deepkit/deepkit-framework/blob/master/packages/framework/src/crud.ts where this is done

Yes, you can directly use the interfaces and types as is with Deepkit (https://deepkit.io) and the library deepkit-openapi. You get also full route documentation if you use the deepkit/http router where you can use interfaces and type aliases plus validation thpes for route parameters (query parameters, body, etc). It still in alpha, but approaches soon beta.

https://deepkit.io/ may be of interest to you! It deeply patches the TS type compiler to make all types visible at runtime, enabling a lot of annotation-style workflows and dependency injection possible completely within the type annotation system: https://docs.deepkit.io/english/runtime-types.html

Previous discussion: https://news.ycombinator.com/item?id=31663298 - it's downright mindblowing that all this seems to be the work of primarily a single developer.

For a less intrusive solution, https://github.com/jquense/yup is a great library to reach for whenever you're defining the shape of a network-transmitted object and don't want to introduce compilation stages.