mediKanren VS gui

Not really production, but probably THE most impressive biomedicine research work I've seen (and I'm an academic MD):

https://github.com/webyrd/mediKanren

This is a FOL theorem prover that uses medical research articles as terms. They use it to do genetics and drug repurposing metaresearch. It's like the wet dream of all the biomed machine learning fanboys out there, except that:

1. it's not machine learning

and

2. it really works

And wow, he uses logic programming to deduce a diagnostic from the facts https://github.com/webyrd/mediKanren .. and used to find out what his son had https://www.statnews.com/2019/07/25/ai-expert-writing-code-save-son/

Hi Kamaal!

I know Cisco is using core.logic, which is David Nolen's Clojure variant of miniKanren, in their ThreatGrid product. I think the Enterprisey uses of mediKanren are a bit different than the purely relational programming that I find most interesting, though.

Having said that, we are now on our second generation of mediKanren, which is software that performs reasoning over large biomedical knowledge graphs:

https://github.com/webyrd/mediKanren/tree/master/medikanren2

mediKanren is being developed by the Hugh Kaul Precision Medicine Institute at the University of Alabama at Birmingham (HKPMI). HKPMI is run by Matt Might, who you may know from his work on abstract interpretation and parsing with derivatives, or from his more recent work on precision medicine. mediKanren is part of the NIH NCATS Biomedical Data Translator Project, and is funded by NCATS:

https://ncats.nih.gov/translator

Greg Rosenblatt, who sped up Barliman's relational interpreter many order of magnitude, has been hacking on dbKanren, which augments miniKanren with automatic goal reordering, stratified queries/aggregation, a graph database engine, and many other goodies. dbKanren is the heart of mediKanren 2.

I can imagine co-writing a book on mediKanren 2, and its uses for precision medicine...

Cheers,

--Will

The Precision Medicine Institute that I now run produces mediKanren: https://github.com/webyrd/mediKanren

It's an open source logical reasoning engine (read: 1960's AI) for drug repurposing that we deploy routinely to help patients.

There is always a need for better relationalization of biological data sets that feed such tools too.

For example, SemMedDB is really showing its age for NLP of the scientific literature and yet it is still astonishingly useful for helping patients even as is.

> The problem with learning Lisp is `(a ,b c)

If you can understand "String ${interpolation}", you can understand list quasiquoting.

> But the problem remains: it only takes one wizard to make reading code impossible by outsiders.

This really is a Lisp meme. There are plenty of Lisp wizards like Guy Steele, Rich Hickey, and Matthew Flatt. The wizards perform the magical act of making code legible and intelligible. I have stumbled around several Clojure and Racket code bases and never felt like "I should understand this code but the features of Lisp make it impossible to know for sure." "Infinite power" macros and whatever are really only used sparingly and generally when it's impossible to achieve a goal otherwise. No one is doing (define + -).

> But this means no-one outside of the language/system developers know the language, this means Lisp tends to be write-only by design - not in the line-noise meaning, but in the obscure foreign language meaning.

I, as a Racket novice, have been able to add candlesticks [1] to the plot library without learning much about it. I have also debugged DrRacket (an IDE) to uncover that Racket GUI operations performed significantly worse if non-integer scaling was used [2]. At no point when I was going through Racket internal code did I ever feel it was write-only. In fact, it was quite convenient to modify Racket internal source code, rebuild, and test changes in a way that would be much more difficult in Java or C++.

> You certainly can not do that, but if you choose to not do that, why pick Lisp?

Built in rationals.

The ergonomics of defining [XML / JSON / etc] data as S-expressions and doing things like pattern matching on that data.

Great, coherent integration between GUIs, plots, statistics functions, and all the other bits of Racket's batteries inclusions.

You still have access to all the other great features that other languages have borrowed from Lisp like REPL development, package managers, good IDE tools, etc.

It is nice to learn the meta-syntax of parentheses once and know that the code will always look like that. No need to consider if some feature is implemented as a syntactically different new keyword, annotation, function call, or whatever. It'll always be a (feature).

> something you have to conciously work for with Lisp.

Plenty of languages have style guides, linters, static analysis tools, etc. to make sure the code conforms to certain restrictions. Lisp feels no different in this regard.

[1] https://docs.racket-lang.org/plot/renderer2d.html#%28def._%2...

[2] https://github.com/racket/gui/commit/20e589c091998b0121505e2...

Please file a bug report at https://github.com/racket/gui/issues

https://github.com/racket/gui/issues/207#issuecomment-753406612