The docs for using QMK are pretty good, but trying to actually understand the code made my head spin; that's why I decided to write my own firmware. Right now it doesn't have any of the fancy features of QMK, but it currently clocks in at under 200 lines, so I have a suspicion it'd be easier to implement those features from scratch in Microscheme than understand their current implementation in QMK.
There's a middle ground. One wants to take advantage of the prior work supporting all these keyboards, while improving and/or making more understandable the core keystroke processing logic. Develop a user language for this logic, that translates to C code that can be included in QMK?
If the root problem with QMK is that there are too many moving parts, adding a completely new language and compiler into the mix seems like a step in the wrong direction.
The extra features that QMK has and Menelaus doesn't aren't really all that appealing to me to begin with.
That's a good point, but it ignores two other notable descendants: Orestes (who is legendary for establishing the precursor to the modern judicial system and who I named my firmware written in Forth after http://github.com/technomancy/orestes) and Paul Atreides, who as you may know was Muad'Dib and was capable of seeing the flow of cause and effect unfold across spacetime.
That article goes into more background but it's based on a much earlier version of the firmware; as of last week I've gotten it to be feature-complete and stable, and I've been using it as my daily driver.
I have been meaning to follow up the article with a part 3 that covers the rest of the features, but in the mean time I have added copious comments to the source link above such that it covers almost everything you need to know. (This is probably the most heavily-commented piece of code I've ever written with a 1:1 code:comments ratio.)
If you've looked at building an Atreus before but gotten intimidated by the soldering, we have a kickstarter for a non-DIY version that's significantly cheaper than the kit: https://www.kickstarter.com/projects/keyboardio/atreus
Thanks; the title is fine. The current link is probably a better starting point; I've added links to the most recent revision so folks can see the final product if they want.
The Dactyl is definitely neat. It's designed for a different use case tho; you wouldn't take a Dactyl with you when you're out and about, while the Atreus is specifically designed for travel.
It's still a work-in-progress, but being able to tweak the input parameters and recompile to get the board regenerated is really handy! The circuit board already uses programmatic alignment for placing the switches and diodes: https://github.com/technomancy/atreus/blob/master/atreus.rkt
Atreus creator here. It doesn't happen often, but occasionally I have customers run into trouble putting their kit together, and I'm committed to always stepping them thru the process of troubleshooting and walking thru the fix. The last thing I want is for you to buy a keyboard and never get it working properly.
There are a few factors at play that make a language good to learn: simplicity, learning materials, and suitability for learning projects.
On the first point, Fennel is simpler than any other lisp I know, beyond "my first interpreter" type Schemes. But you'll find much better learning materials for some other lisps; in particular Racket is exemplary in this regard.
So I would say it comes down to the learning projects you might want to build; this is always the trickiest part of learning any language. If you want to learn by creating a game, Fennel is a great choice. Likewise if you want to extend an existing program that already has Lua support, such as AwesomeWM or Redis. But for most "industrial" type projects that access external APIs or write to existing file formats, you'll have a better time in Racket due to the better library ecosystem.
I don't find it particular simple or a good Lisp. I don't think it is a Lisp at all. It does not even know about QUOTE or basic list processing. If Fennel is supposed to be a Lisp, than the concept of 'being a Lisp' is meaningless.
Actually the best Lisps are those who are actually Lisp (actually implementing the particular syntax and semantics of Lisp) and not a transpiler to another language. This other language leaks on all places.
Fennel is neither a Lisp nor a good learning environment for Lisp. Fennel is actually some kind of Lisp/parentheses-inspired layer on top of Lua. That's nice but not Lisp.
There are a lot of small Lisps which make learning Lisp much more easier. Start with any small Scheme implementation and that's much nearer to Lisp than Fennel will ever be: s-expressions, list processing, evaluator, code as data, macros, data representation, tail/recursion, procedural abstraction, first class functions, lambda calculus, etc etc. There is a lot of excellent material in the Lisp world to teach that. There is even material how to do useful things with that. None of that applies to Fennel. It does not do list processing, its code as data is weak and Lua leaks everywhere.
> why does fennel description insist on macros as compile time feature?
This just means that it's possible to ship the compiled code on its own and have no dependencies on Fennel at runtime. It doesn't mean you can't ship the compiler if you want to; the choice is up to you. In fact, I strongly recommend in most cases shipping the compiler so you can write and refine your code interactively as the program runs. It's helpful to think of "compile time" as a subset of runtime; it's just that portion of runtime when the function that's running happens to be the compiler!
Fennel is very well-suited for live-coding; I used this heavily when writing my entry to the Lisp Game Jam this spring. I blogged a bit about how live-reloads interact with the Lua module system here: https://technomancy.us/189
> So, since many mediawiki systems use lua, does this mean that you can code in Lisp (or Fennel), transpile to Lua, and then run the code as a module in a media wiki system?
Yes, easily.
With a little bit more work you could load the Fennel compiler up server-side so it could do the compilation for you and support Fennel "natively". I have done a similar process with TIC-80 despite knowing very little C: https://github.com/nesbox/TIC-80/pull/597
> What about Common Lisp libraries? would they be transpiled too?
No, Common Lisp is a completely different language with little in common with Fennel.
tl;dr Urn is a much bigger language that happens to compile to Lua as an implementation detail. Fennel is much closer to Lua and is dramatically simpler, only diverging from Lua semantics when the changes can be implemented purely at compile time. (immutable locals, blocking accidental global references/setting, etc) The compiler output from Fennel tends to be pretty readable and looks a lot like the input.
If you need to write code that runs in the browser, Lumen is one choice, but you can also run Fennel in the browser using Fengari: https://fengari.io/ I know next to nothing about frontend development but was able to integrate Fengari into https://fennel-lang.org to get the live REPL working with ease.
Yes, I had a comment in that older HN thread. I think this has me moving towards Fennel when compared with Urn, since I want a smaller language, but the examples of Lumen in this HN thread:
are swaying me to spend some time with Lumen this weekend to understand how it compares to Fennel. The Lumen examples were pretty impressive and it works for JavaScript too.
