Nowadays I mostly use Kawa. I used to be a dedicated Guile user, for which I developed the (grand scheme) glossary, and I still use it occasionally for small things, but I'm now developing a project that relies heavily on Kawa (#GRASP).
I sometimes use Racket, especially when I need some GUI.
I also use Emacs Lisp occasionally.
What non-Lisp programming languages do you use?
I mostly use C at my day job. I also write some code in Dart and Go as well as bash scripts and makefiles. I sometimes also use Python. I also have professional experience with PHP, JavaScript, C++, C# and x86 assembly
What is your favorite Lisp programming language? Why?
For a long time I was very happy with Guile, especially as I was using it with my (grand scheme) glossary - it really made the language terse.
But after using Kawa, I find the lack of checked type annotations (in macroexpanded positions) really annoying. Also, I like it that Kawa provides access to Java-like OO system (that I like way more than GOOPS that comes with Guile).
I think that porting the (grand scheme) glossary to Kawa would be nice, but that would probably require some changes in the compiler.
What is your favorite non-Lisp programming language? Why?
I occasionally look at solutions to Advent of Code in various different languages, and beside my solutions in (grand scheme), I enjoy the ones in F# the most.
(They are usually quite similar in their spirit)
I also pretty much enjoy using Dart - I think that its designers are doing a great job.
What is that one thing about your favorite non-Lisp language that you wish to see in your favorite Lisp language?
I really wished that Kawa offered Dart-like object system, which in practice would mean things like mix-ins and extension methods, and more decent generics.
While working on #GRASP, I occasionally try analyzing #Interlisp's #SEdit (because I'm curious about its internal representation), but I always end up not being able to understand literally anything from that code base.
And that makes me wonder: are the sources of GRASP so much easier to understand to me because I'm their author, or do the programming practices that I use (such as type definitions and plenty of examples) actually make things easier to read?
(A while ago, I did have a look at implementations of some things in #Emacs. The "undo" mechanism is understandable, but it owes this understandability to comments which make up for a missing type system. On the other hand, I've found Emacs' implementation of window splits much more difficult thant in GRASP -- in large part because GRASP is written in #Kawa#Scheme, and has a Java-like OO system, and I feel that classes and objects do a really good job at grouping related things together.)
I just implemented evaluation gesture in #GRASP, and unlike in the eariler Android-only Java version on #GRASP, it now works contextually (i.e. the first and the last touch point must be on the same level, and the expression is evaluated relative to that level):
@rml@hugoestr
I was once indignant at Wadler's simplistic title, until I realized that some time before Sussman wrote a paper 'Why Conniving is Better than Planning'.
Anyway, I loved the argument that Miranda is better than Scheme because you can make Scheme as verbose as Miranda (IIRC it concerned lambda-expression evaluator)
Other than this, I am still a bit puzzled about Lisp's quote operator, which evaluates to "the quoted thing" when you invoke 'eval' on it, but behaves differently when you reduce Scheme step by step (which is something I ran into when I was implementing visual stepper for #GRASP)
@mykhaylo i don't want to take it away from Emacs, but I'm developing my own Emacs-inspired structural visual editor #GRASP, and I'm considering whether to add this feature or not
I would love to start developing for smartphones, creating a proper #emacs client totally reimagined for the smartphone is long overdue and a project I could really sink my teeth into. You know the popup keyboard on your phone? You think Steve Jobs invented that? No he didnt, Richard Stallman did, it's called a minibuffer. Emacs was doing all this stuff in the 80s, and way better, even.
But I can't help but hate all the frameworks surrounding mobile development, ie React Native, Swift, Flutter etc, but also from my experience as a user, the apps I've tried that were made with alternative #fp frameworks like #LambdaNative, which had to downsample and skew the resolution to fit my phone's screen, so it didn't seem to even feature responsive design; maybe ok for the hospital software they designed it for but not something for creating applications that the people will use out of their own volition.
I'm pessimistic that "there is no alternative" but seeing how nicely #FDroid is coming along, I'm hoping that I may be wrong. Is there anything promising out there in the #mobile#gui#foss space?
@rml Emacs has actually been a huge inspiration for the design of #GRASP (although it is not a "text editor", but a "structure editor"), and while it may yet not be usable, I think that there's already some value in it (and it's actually not that far from being usable), so if you'd like to contribute (or at least give it a try and smash it with criticism), you're very welcome
Is #Kawa working on support for Project Bloom (native continuations and TCO in openJDK)? Looking at the website the NEWS hasn't been updated since 2020, but I would think that its top of the agenda. After all these years, Kawa can become a real #scheme.
The implementation itself is fairly mature, but sometimes weird bugs happen.
When I report those bugs, I sometimes get a response from Bothner (and sometimes those bugs even get fixed), but on other occasions he seems to completely ignore my reports.
On the other hand everything is open-source, so in theory I could try fixing those things myself - and not that I haven't tried, but there are so many things that I just don't understand.
The reason why I chose Kawa is that you don't really have many options if you want to target Android from Scheme. I think there were some successes with Gambit (there's even a project called LambdaNative based on this), but it produces native code, so you'd need to maintain binary versions for all architectures supported by Android (I think it currently means x86, x86_64 and a few flavours of ARM).
Then again, I think that there's a lot of really interesting features in Kawa, and that Bothner had a fairly good taste (or at least fairly consistent with my taste) when extending Scheme. Also, there aren't that many options if you want to target JVM-like things from Scheme (I hear that you can generate JVM code from Bigloo - but it seems less focused on the interoperability with JVM)
So at least the history with #GRASP was fairly organic: I wrote the first version in Java (after I figured out how to build Android apps on Android), and then I hooked the Kawa interpreter to evaluate expressions - which mostly worked fine.
But then I realized that if the core GRASP is written in Java, I will never be able to use it to edit itself - which (after some experiments with using Kawa to build Android apps) made me rewrite (and extend) GRASP to Kawa.
And so far I feel that it was the right decition, despite all the aforementioned drawbacks.
Now I hope that once GRASP is finally released, it will be a sufficiently convincing argument for someone to take over the maintanence of Kawa (and this someone could even be me - but I think I'd rather maintain a fork, because I'd be tempted to introduce some backwards-incompatible changes).
I also hope that I could somehow port Kawa's extensions used in GRASP to, say, Chez Scheme, and then maybe write a port that would use the Cairo graphics library (because although I see a ot of decent aspects of JVM - in particular stability, availability and backwards compatibility - performance isn't one of those things)
@rml@daviwil
I OTOH tend to build my own dialects of Scheme - such as the (grand scheme) that I built for Guile a few years ago, where I redefined some forms such as lambda or define :D
Currently I have also built a specialized language in Kawa for building #GRASP (it doesn't have any official name, but I sometimes call it Javor in my heart)
IMO immutable hash tables are an overkill for most applications, but I also don't like SRFI approach to hash tables.
As I develop #GRASP, I have implemented a few flavors of "mutable lambdas":
(define-mapping (fib n)
(+ (fib (- n 1)) (fib (- n 2))))
(set! (fib 0) 1)
(set! (fib 1) 1)
I also have a nice system of extensible records, which is preferable when I want to have a print representation, and when the keys are known upfront. (It also works with my pattern matcher)
Friday Social: What is your favorite non-Lisp language?
Friday Social is back! So we know we are all Lisp programmers here and we love the language and use it....