Still working on CLIPS-related libraries. My most recent one is CLIPSmqueue[1]. I'm employed full-time, so progress is slow as CLIPS stuff comes second to that. However, I've got a much larger CLIPS-related project in the works that I've been taking my time on, and I'm excited for when I finally feel ready to release it.
I'm not sure these projects will ever "go anywhere," but at the very least I'm honing my craft as a programmer. I've learned so much, and I have so much more to learn.
Hey, HN. This is a small C library that enables usage of POSIX message queues (mqueue) in CLIPS. This enables IPC between multiple CLIPS processes using kernel-managed message queues, including load-balancing receives and priority-handling.
The repo includes a fairly full test suite as well as examples that demonstrate multi-process communication between CLIPS rules engines.
My purpose in providing this library (and other CLIPS libraries I've released) is to expand the usecases in which CLIPS can be leveraged. Feedback welcome.
Very cool. Neat how you managed to get logical symbols in to the language itself! When might someone use preconditions in Lean theorems?
This article caught my eye because it's focused on imperative programming, and I've been very focused on declarative vs imperative programming over the last few years. I implemented a version of your function in CLIPS, a Rules-based language that takes a declarative approach to code:
The theorem you write in Lean to prove the function kind-of exists in CLIPS Rules; you define the conditions that must occur in order to execute the Right Hand Side of the Rule. Note that the above simply prints `TRUE` or `FALSE`; it is possible to write imperative `deffunction`s that return values in CLIPS, but I wanted to see if I could draw parallels for myself between Lean code and theorems. Here's a gist with the simple version and a slightly more robust version that describes the index at which the matching numbers appear: https://gist.github.com/mrryanjohnston/680deaee87533dfedc74b...
Thank you for writing this and for your work on Lean! This is a concept that's been circling in my head for a minute now, and I feel like this article has unlocked some level of understanding I was missing before.
Location: Pittsburgh, Pa
Remote: Yes
Willing to relocate: No
Technologies: CLIPS, Ruby (on Rails), Go, JavaScript, C, SQL
Résumé: https://drive.google.com/file/d/1M-tC7qpehmsJfd3JBk3KtXEQ5wDJz89t
Email: mrryanjohnston (at) gmail
Website: https://ryjo.codes
12+ years of experience writing code professionally, active in open source, passionate about education and freedom of knowledge. Very interested in Rules Engines. Love working on teams of self-starters, enjoy pushing the boundaries of my understanding. Comfortable mentoring others as well as helping non-technical folks with difficult-to-grok concepts.
> Conventional programming languages, such as FORTRAN and C, are designed and optimized for the
procedural manipulation of data (such as numbers and arrays). Humans, however, often solve complex
problems using very abstract, symbolic approaches which are not well suited for implementation in
conventional languages. Although abstract information can be modeled in these languages, considerable
programming effort is required to transform the information to a format usable with procedural
programming paradigms.
> One of the results of research in the area of artificial intelligence has been the development of techniques
which allow the modeling of information at higher levels of abstraction. These techniques are embodied in
languages or tools which allow programs to be built that closely resemble human logic in their
implementation and are therefore easier to develop and maintain. These programs, which emulate human
expertise in well defined problem domains, are called expert systems. The availability of expert system
tools has greatly reduced the effort and cost involved in developing an expert system.
Really awesome. Thanks for this thorough write-up. I don't totally understand the deeper math concepts mentioned in this article around RNNs, but it's sparked some of my own thoughts. It feels similar to things I've been exploring lately-- that is: building your app interwoven with forward chaining algorithms. In your case, you're using RNNs, and in mine, I'm building into the Rete algorithm.
You also touch on something in this article that I've found quite powerful: putting things in terms of digesting an input string character-by-character. Then, we offload all of the reasoning logic to our algorithm. We write very thin i/o logic, and then the algorithm does the rest.
This is another reason I am learning CLIPS. It implements a form of the Rete algorithm. A Rete network provides the same benefits of a neural network without the bells-and-whistles, and thus would be a great candidate for anyone who thinks they could benefit from the reasoning power provided by LLMs.
Using debuggers makes a lot of sense in this case. If I had to switch context that frequently between relatively stable applications, it would be helpful to have a debugger framework for doing work.
`printf` statements are helpful when the error exists beneath the debugger: in the application framework itself.
> they're not always available
100% agreed. `printf` is "one tool" I can use to follow the control flow of a function call across frameworks, programming languages, and even operating systems. It's also something I can reliably assume my coworkers have in their tool belt, and thus provides a common language that even multiple different organizations can use to cross-collaborate a specific debugging session.
the longer i'm on a project, the more inclined i may be to get a debugger going, but often there's much more low hanging fruit to deal with that doesn't necessarily need a debugger to figure out.
I'm not sure these projects will ever "go anywhere," but at the very least I'm honing my craft as a programmer. I've learned so much, and I have so much more to learn.
---
[1]https://github.com/mrryanjohnston/CLIPSmqueue