Featured on Arraycast:
April, a compiler from APL to Common Lisp, releases version 1.0 - https://news.ycombinator.com/item?id=30192096 - Feb 2022 (3 comments)
April, an APL Compiler for Common Lisp [video] - https://news.ycombinator.com/item?id=24434717 - Sept 2020 (23 comments)
April: An APL That Compiles to Common Lisp - https://news.ycombinator.com/item?id=22225136 - Feb 2020 (11 comments)
Do any editors have a "translator" kind of tooltip or panel that explains what each symbol does in languages like APL or KamilaLisp?
I was thinking about how I'd go about learning the various symbols involved in such a language, and I learn best by reading and modifying existing code, so something that helps me understand what I'm looking at would be nice.
- Dyalog APL: https://tryapl.org/
- Kap: https://kapdemo.dhsdevelopments.com/clientweb2/
- ngn/apl: https://abrudz.github.io/ngn-apl/web/
- BQN (my language): https://bqn.funmaker.moe/
What are those used for?
malbolge-lisp: https://github.com/kspalaiologos/malbolge-lisp
HN discussion: https://news.ycombinator.com/item?id=28048072
She’s a genius prodigy.
A lightweight Lisp interpreter in Malbolge - https://news.ycombinator.com/item?id=38850961 - Jan 2024 (20 comments)
Lisp in an “impossible” language, the most complex Malbolge program to date - https://news.ycombinator.com/item?id=28048072 - Aug 2021 (73 comments)
cat data/demo.lisp | ./bin/stutter
The books explains that, but is not free. But you can get it somewhere else.
Quotes about Malbolge:
"The day that someone writes, in Malbolge, a program that simply copies its input to it's output, is the day my hair spontaneously turns green. It's the day that elephants are purple and camels fly, and a cow can fit through a needle's eye."
"There's a discussion about whether one can implement sensible loops in Malbolge—it took many years before the first non-terminating one was introduced. A correct 99 Bottles of Beer program, which deals with non-trivial loops and conditions, was not announced for seven years; the first correct one was by Hisashi Iizawa in 2005."
No memory side effects, all collections are persistent.
You're totally new to Lisp, right? There is no such clear boundary in Lisp languages.
> This can't be relevant when the objects referenced by these collections are mutable.
Why not? Explain your reasoning. E.g. why is not not relevant that we can make a longer list by adding an element to the front of a shorter list, without mutating that shorter list, if the elements are objects that support mutation?
An example would be if presence in a collection is dependent on mutable properties of its entries.
Edit: though I thought about it a little more. The more interesting question is regarding the standard library, rather than the compiler. Applying different licenses to the two is not unusual (gcc is GPL, glibc is LGPL). From what I can see, the standard library is embedded entirely into the compiler, and thus yeah, I do think programs that use this would actually have to be GPL. Not that that's a bad thing though :)
There is also an interesting question about license compatibility between GPLv3 and GPLv3 with RLE, but that is mostly ignored by everybody.
Programs that are not combined with KamilaLisp, only requiring an installation of KamilaLisp for their execution, almost certainly don't have to be GPLed.
I think the other "inconveniences" of Lisp could be more tolerable for beginners if learning the language didn't require learning a new IDE (or OS, depending on how you define Emacs!). But at that point you'd have to forego a major benefit of using Lisp (its REPL); you'd be back to writing "dead" programs, not image-based "live" ones.
Another problem I've faced with Lisp is lack of good documentation (except for Racket, but then again, Racket doesn't have Common Lisp's powerful REPL). Every website that teaches Lisp is in ugly HTML+CSS-only style, compare that to the more user-friendly websites of other languages.
Then there's the issue of up-to-date learning material. Aside from the fact that there are very few resources to learn Lisp, the ones that are available are too old too. "Practical Common Lisp" (2005), "Common Lisp Recipes" (2015), "ANSI Common Lisp" (1995), etc.
I like the philosophy of (s-exp) but modern lisps have ruined its simplicity for me by introducing additional bracket notations [like this]. It's confusing for me as a beginner to distinguish between (this) and [that], and honestly goes against the whole idea of "code and data look the same" motto.
You can use Medley which is Interlisp-D, a different, parallel strain of Lisp, a descendent of MACLISP, itself an ur-lisp ancestor of Interlisp, emacs lisp (older than EMACS, which didn’t start out as a lisp program at all), CommonLisp, Multics MACLISP and that even begat Scheme.
Interlisp didn’t even keep its code as text files (though I wrote an eMacs for it at PARC back in the early 80s) so you may find it more accessible.
(see more from https://github.com/CodyReichert/awesome-cl?tab=readme-ov-fil...
https://cl-community-spec.github.io/pages/index.html
and some more)
Here we have a conflict: Lisp survives, because it is different and ground breaking. Like Bach, Shakespeare, Einstein, ... But it is also old. If you study Bach, you'll find that he composed for instruments which are out of fashion, like the Harpsichord. When do we last have heard one of his compositions on an original instrument from the time he was living? His music has been reused, re-interpreted, but the original impression, live played on historic instruments is rare.
Lisp is also not "modern", it's not fitting into the "fast fashion" world of current software with ever faster hype cycles, where JavaScript creates hundred new variants frameworks every day and your software from a five years ago is no longer supported. Like our phone doesn't get any software updates after five years (if not earlier).
There, a book like "Paradigms of Artificial Intelligence Programming, Case Studies in Common Lisp" by Peter Norvig is outdated. At the same time it might be a timeless classic.
The tooling for it has been developed and accumulated over decades and can't be reimplemented every other year. It's not powered by Microsoft, a trillion-dollar company, currently fueling the AI hype. Lisp is not in the hype cycle industry.
Using GNU Emacs plus extensions like SLIME or SLY as a dev-environment is just an effect on the low amount of resources and the concentration on a tool, which is itself programmable in Lisp. None of the other IDEs (IntelliJ, Visual Studio, ...) is easily extensible in Lisp.
> not image-based "live" ones.
to have "live programs" doesn't need "images". Image-based development is something different. For example ECL has the usual Lisp tools embedded, but can't create or start images. SBCL can save and load images, but doesn't use it much, beyond being able to deliver applications with it.
The real image-based development tools like Interlisp/Medley (-> https://interlisp.org ), Symbolics Genera, LispWorks ( https://lispworks.com ), etc. few people have ever seen or used. None of those use GNU Emacs as a dev environment.
> learn Lisp, the ones that are available are too old
Lisp is old, too.
The newer versions are no longer Lisp. It is nicely in the web, but it is no longer Lisp, like SICP has shown
If only regular version numbers had some way to encode this relationship.