Is there a resource which compares Lisps (expressiveness, limitations, available special forms, ...)? I often read about lisp 1 and 2.0, clojure being a lisp 1.5 (because of the callable keywords if iirc).
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.
The paper on microKanren [1] is imho the most approachable piece outside the "reasoned schemer" [2]. The thesis on which it is based is also interesting but is a thicker beast. Looking at stuff from the clojure world (clojure.core.logic and this talk [3]) is also interesting imho, especially from a dev perspective. From this point of view I found this talk [4] to be especially enlightening in how to build a database / query engine and concrete applications of MiniKanren / datalog.
Interesting project, showing how "easy" it is to host[1] another language within Clojure. Like others, I admit I see little value for myself or as a selling point for beginners. For experienced engineers however, like I wrote above it should serve as a case study into how to hook up everything together to produce a working tool. Then it is a matter of seeing if and when there is opportunity to reuse such techniques to build DSLs that compile to native Clojure.
[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`...
I would be very interested to read about the limits of conjure. In my mind it is a fabulous tool, with vim-sexp it is very productive to write clojure code with and a pleasure to use.
I agree. I used ChatGPT to boostrap a coding session in which I was using a library to describe data structures. My steps were
- ask for documentation and examples relevant to the task ahead.
- produce some examples
- tweak the example using domain-like data
- propose a solution using the lib as is
- ask for a solution using a different convention than the classic one
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)
Dot operators vs plain functions are just two different ways to call a function, binding the lexical context `this` to a different value, possibly `undefined` in a strict context (which is default in es6 modules). The two are not uncompatible and libraries like jQuery make a wonderful use of the first version (dot call). The fact is that everything is mutable in JavaScript and one of its main API (the DOM) is actually built around this concept.
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.
Anecdotal but I know at least one megacorp that is doing layoffs of manager level positions after noticing that their services/industrial processes worked well while them being on furlough during the lockdowns.
Hello, thanks for your submission this is really interesting. Out of curiosity have you thought about how this problem could relate to history navigation, in the sense that it can create context around a specific resource, ie : retrieve links that you read after reading a HN thread, in order to prioritise its reading order or link it to some topic?
I don't see it mentioned but there is a neovim plugin called conjure [1] that is written in fennel. This is a general purpose REPL client that works for Clojure (I use it daily for Clojure and ClojureScript) but also for fennel itself. So you can have a really nice neovim plugin dev experience using this tool. Conjure works with fennel out of the box, but if you want to go deeper you may be interested in another plugin called aniseed [2] which provides interesting facilities for the fennel language and that is used internally by conjure.
Disclaimer: I am not the author of those tools, just a random Clojure dev.
Hello, this is a really interesting comment although I disagree with some of its points.
I recently had my first full time Clj/Cljs job and it made me realise some points:
- 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).
Hello, this is an interesting take. Clojure has been a hobby of mine for some time but now I am a professional Clojure developper (clj/cljs). I knew the language before starting my new job but I found it really different than know the "platform": how a project is layed out, tests are written, some libs, how to pinpoint potential technical debt/suboptimal code accurately and so on... But I guess this would have been true if I had transition to any other new language.
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.
I (used to) play this game a lot and that is precisely what is interesting in it imo. In the game you can have some influence on events/characters by doing specific actions: choose the warden of your children with care, try to cultivate alliances with your neighbors through alliances (dynastic alliance etc...) but this is inherently a dynamic system in which the sheer number of factor make it really hard to have a total control of "history".
I frequently find myself playing the game at regular speed and watching events unfold in the neighboring kingdoms, plotting how I could take advantage and by the time my plotting is ready (whether it is engineering a casus belli, assassinating somebody or something else) more often than not the target either changed / disappeared or some more interesting event is taking place (crusades !). Also playing in "watch mode" let's you take the time to read the bios of all the "interesting characters" and learning a lot of stuff.
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.