💾 Archived View for republic.circumlunar.space › users › dbane › gemlog › 2023-12-17.gmi captured on 2024-02-05 at 10:28:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
I have made some minor changes to KLIC, although I have no plans to maintain a fork and am just waiting to contribute back upstream.. It is a perfectly capable language, but has raised some more philosophical questions.
My modifications to the upstream project
When dealing with tools, I've tried to avoid ending up responsible for the tool as well as the product that I really should be concerned with. This is surprisingly difficult. One example is where I would now refer someone to BBC BASIC rather than COMAL if they were interested in such a language. COMAL has nice good vendor-neutral standard, but BBC BASIC has two interpreters currently maintained by someone other than me. I'm coming around to the view that other than the core programming language, all other technologies should be "boring", where "boring" means maintained by someone else.
For more "professional" languages like Prolog, it's a bit more complex but the same principles apply. I personally think Prolog is unsuitable for production development although many others disagree. But I do think that descendents like Mercury and Concurrent Logic languages are suitable. Especially for the latter, KLIC has always been there and is now usable; FLENG is there but a bit non-standard and doesn't behave for me. It looks like the best option is to stick to KL1 after all, otherwise we end up having to write requirements & design documentation before the code again.
Of course, KLIC could always use some work too. For example, using later OS syscalls like kqueue, pledge and unveil. And maybe improving the efficiency of the generated C code.