adz5a
Joined 7 years ago
Joined 7 years ago
Dabbling into llms I think that lisps could be very interesting format to expose tools to llms, ie prompting a llm to craft programs in a Lisp and then processing (by that I mean parsing, correcting, analyzing and evaluating the programs) those programs within the system to achieve the user's goal.
[1] https://github.com/jasonhemann/microKanren
[2] https://mitpress.mit.edu/books/reasoned-schemer-second-editi...
[3] https://www.youtube.com/watch?v=irjP8BO1B8Y&ab_channel=Cloju...
[4] https://www.youtube.com/watch?v=y1bVJOAfhKY&t=10s&ab_channel...
[1] Clojure is known to being designed to be hosted within another platform, but like all Lisps it is also a valid (and productive) hosting target by itself. It should be known that many of the APIs in the Clojure ecosystem rely either on:
- literal data structures - macros reusing native Clojure patterns / forms such as `let`, `def` ... - the shape of native (ie: defined within clojure.core) Clojure APIs, such as `get-in`, `with`...
Some examples: specter, integrant, mount, clojure.core.logic, datalog (datascript, datomic, xtdb), clojure.spec ...
https://github.clerk.garden/nextjournal/clerk-demo/commit/8a...
i kind of think about this as a REPL assistant. very interested in other ways to use it (and the use cases, anecdotally I also used it to try and learn a little bit of COBOL using the same iterative approach)
I really fail to see how those kind of changes bring anything of value to the language, apart from creating complexity where there is much already: some codebases will try and use this before it's ironed out with different / changing / competing transpiler implementation while it is only stage 2. What happened with decorators (see babel-legacy-decorators) should be a warning against enthusiasm for these kind of things and remind me of the pitfalls of macros in the Lisp world...
I am not saying that you should stick with an idiom till the end of time but changes should try and lower that complexity while (in the case of EcmaScript) being backward compatible so as to not break existing stuff.
Btw I love RxJS and its variants, Ben Lesh's talks (as well as those by Matthew Podwysocki, Andre Staltz etc...) from around 2015 and then on were one of the reasons I got into JS as a professional.
Disclaimer: I am not the author of those tools, just a random Clojure dev.
- although figwheel is an awesome build tool, shadow-cljs with its near seamless npm integration is imo the most powerful Cljs build tool atm [1].
- cljs-bean[2], recently released by Mike Fikes is a really cool tool: it makes working with POJO really easy without too much performance penalty
- the new react hook API is imo a game changer for CLJS frontend frameworks: the decision to overload native function for componenents instead of using ES6 classes makes working with react componenent much more easier, imo this new API suits CLJS perfectly: hooks are just js functions that are called in the same order at each render pass.
- clojure.spec and clojure.spec.gen in a REPL are really powerful tools for frontend development that are unavailable in the wide JS world.
All in all I am actually much more optimist than a few months back about the future of CLJS frontend dev, those are still relatively new tools, clojure.spec is still a work in progress (although I would recommend to take a look at the metosin spec-tools which are really nice).
Edit: formatting
[1] https://code.thheller.com/blog/shadow-cljs/2018/06/15/why-no...
Would you have any example of what your trainees stumbled upon or found difficult in the language? That would be useful I guess when we try to onboard new people on the project.
Have a nice day :)