>Lisp is a family of programming languages with a long history and a distinctive parenthesized prefix notation. There are many dialects of Lisp, including Common Lisp, Scheme, Clojure and Elisp.

>Emacs is an extensible, customizable, self-documenting free/libre text editor and computing environment, with a Lisp interpreter at its core.

>Emacs Resources
https://gnu.org/s/emacs
https://github.com/emacs-tw/awesome-emacs
https://github.com/systemcrafters/crafted-emacs

>Learning Emacs
C-h t (Interactive Tutorial)
https://emacs.amodernist.com
https://systemcrafters.net/emacs-from-scratch
http://xahlee.info/emacs
https://emacs.tv

>Emacs Distros
https://spacemacs.org
https://doomemacs.org

>Elisp
Docs: C-h f [function] C-h v [variable] C-h k [keybinding] C-h m [mode] M-x ielm [REPL]
https://gnu.org/s/emacs/manual/eintr.html
https://gnu.org/s/emacs/manual/elisp.html
https://github.com/emacs-tw/awesome-elisp

>Common Lisp
https://lispcookbook.github.io/cl-cookbook
https://cs.cmu.edu/~dst/LispBook
https://gigamonkeys.com/book
https://lem-project.github.io
https://stumpwm.github.io
https://nyxt-browser.com
https://awesome-cl.com

>Scheme
https://scheme.org
https://try.scheme.org
https://get.scheme.org
https://books.scheme.org
https://standards.scheme.org
https://go.scheme.org/awesome
https://research.scheme.org/lambda-papers

>Clojure
https://clojure.org
https://tryclojure.org
https://clojure-doc.org
https://www.clojure-toolbox.com
https://mooc.fi/courses/2014/clojure
https://clojure.org/community/resources

>Other
https://github.com/dundalek/awesome-lisp-languages

>Guix
https://guix.gnu.org
https://nonguix.org
https://systemcrafters.net/craft-your-system-with-guix
https://futurile.net/resources/guix
https://github.com/franzos/awesome-guix

>SICP/HtDP
https://web.mit.edu/6.001/6.037/sicp.pdf
https://htdp.org

>More Lisp Resources
https://rentry.org/lispresources

(setf *prev-bread* >>105427501)

Read Land of Lisp!
https://files.catbox.moe/77rqtw.pdf

>>105482630
For me it's Lem
https://lem-project.github.io

>>105527496
https://languagelog.ldc.upenn.edu/myl/llog/jmc.pdf
https://github.com/jart/sectorlisp

>>105527496
This article (also suggested by Gemini) should contain everything you need to know: https://norvig.com/lispy.html

>jart
oh no...

>>105427818
>Sawfish
Thanks, finally a fishy lispy WM for my OpenBASED machine.
https://github.com/SawfishWM/sawfish
https://cvsweb.openbsd.org/ports/x11/sawfish/

>>105527824
Can't wait until it gets an org mode

>>105527496
Well, technically you only need λ and nothing else. You can implement numbers via Church numerals and other inductive types (like lists) in a similar way (see Church encoding, there are others like (Mogensen-)Scott, but idk about tradeoffs). And fixpoint combinators (like the famous Y combinator) for iteration.

Of course, this isn't very practical, but there is at least one programming language that works like this (using de Bruijn indices notation instead of more common λarg.body or (lambda (arg) body)):
https://bruijn.marvinborner.de/

>night 3 of running home happy to work on lisp projects
i jump over the puddles too!

>>105529503
>>105527496
You should also look into interaction combinators for a parallel lambda calculus compiler. There's versions that add in GPU parallelization and hardware arithmetic operations. It's a lot of information and no one seems to have a locked down optimal setup yet, everything is flawed, overcomplicated, or just poorly explained.
In other words it's an excellent research topic if you actually want to make something new and interesting on the blleding edge.

On the other end of the scale look up binary lambda calculus, an implementation in raw bits that's insanely compact. Here's the entire interpreter, written in itself:
>pure binary version
01010001
10100000
00010101
10000000
00011110
00010111
11100111
10000101
11001111
000000111
10000101101
1011100111110
000111110000101
11101001 11010010
11001110 00011011
00001011 11100001
11110000 11100110
11110111 11001111
01110110 00011001
00011010 00011010
>byte encoded version
19468
05580
05f00
bfe5f
85f3f
03c2d
b9fc3f8
5e9d65e5f
0decb f0fc3
9befe 185f7
0b7fb 00cf6
7bb03 91a1a

>>105529596
Here's an example of(one possible) compilation of lambda calculus into interaction combinators

>>105529608
based oldfag

>>105523353
>If someone tries to claim that something is a dialect of Lisp, probably just because it has s-expressions of some sort, but it cannot run any similar volume of existing Lisp code, it's a flat out lie and abuse of terminology for what "Lisp" and "dialect" mean.
A statically typed Lisp probably wouldn't run any dynamically typed Lisp code. Sane programmers would still call it a Lisp dialect, while smug Common Lisp weenies would seethe at the mere sight of a type definition and claim it cannot be a Lisp dialect.
Despite all the differences everyone can agree that C, C++, Java, C#, Go, and Rust are all C-like languages (more specifically ALGOL-like), but when it comes to Lisp nobody can agree what a Lisp dialect actually is. Even the COBOL community is better at this, Enterprise COBOL cannot run most Visual COBOL code, but both are still considered COBOL dialects.

The Lisp community gatekeeping the definition of "Lisp dialect" to only mean "Common Lisp" is one of the most hilariously dumb things I've witnessed. Not even Scheme, arguably the simplest and purest form of a modern Lisp dialect, is safe from the smug CL weenies.

>>105529795
You can call Common Lisp from Coalton.

>>105529608
This picture reminded me about a guy I knew online who used Java pretty productively and (after a short detour to Clojure) got bitten by the Haskell bug. IIRC, he wasn't writing any kind of actual software, just learning type theory and stuff like interaction nets and dipping toes into category theory. Still, chatting with him was fun.

Also, representing big numbers concisely as a product of their factors is what people always do when programming in Brainfuck. The difference with interaction combinators seems to be that 2×2 is not a "normal form" (whatever that means for an imperative language) in Brainfuck, while it is in interaction combinators.

>>105529795
Common lisp is the ONLY lisp with a live image. From that point of view it's entirely different from every other language in the category in a fundamental way. Aside from that massive item, all the other differences between all the other lisps are just semantics that don't really change anything but performance and syntax.

I'd personally still call all s-expression languages lisp-like, even hacks like Hy that aren't lisp at all under the hood, but then we'd need some other additional category for CL aside from "lisp". And if we're defining CL as separate from all other lisps, then by all rights CL should be the default state and the others should be labelled separately.

>>105529890
A normal form is one that doesn't change with further evaluation. So in most languages that'd be a numeric literal.
It's not just factorization either, there's other methods involving exponentiation, etc... It's actually based on Kolmogorov complexity, a number is any program which is equivalent to that number when substituted into an arithmetic expression.
The interesting part is that there's an infinite number of possible ways to represent every number, all of which are in normal form, AKA they can't be automatically compiled or evaluated into a simpler form without additional arguments.

>>105529897
>if we're defining CL as separate from all other lisps, then by all rights CL should be the default state
Why should CL be labelled a Lisp but none of the other Lisps? That's ridiculous, it's like if C programmers claimed it was the only ALGOL-like and tried gatekeeping the term so no other language could use it. If CL needs its own category, then CL is the one that needs to be redefined, not all the other Lisps in existence.

Besides, Scheme is more of a Lisp than CL is, the latter incorporates so many paradigms and features that it simply cannot be called a "pure Lisp" anymore, while the former is the purest and simplest form of a modern Lisp we have today. If anything, Scheme should be the default state. CL is just too bloated.

>>105528504
What is a realistic timeline for this happening?

I don't understand the difference between org-roam-capture and org-roam-find. They both create a node, you can add info to it, then save it. What exactly is the capture doing that find doesn't?

>>105529795
The existence of Coalton makes all of this post uninformed and completely pointless. Please just stop shitting up the thread. This discussion is pointless.

>code is sexp
>implements McCarthy's primitives from recursive paper
Behold, a Lisp.

>>105529897
>1000+ pages specification
>should be the default state
>less than 100 pages specification
>should be labelled separately
we get it that you're addicted to it but to say that it should be the default state of lisp is beyond retarded

>>105530053
>Coalton
It's not a standalone Lisp dialect. It's basically an add-on for Common Lisp. The correct examples should have been Carp or GOAL, but those don't prove your point so you conveniently ignored them.

>>105529795
Lisp = AST directly modelled as S-expressions + macros for AST expansion.
It's this simple.

Jank is very promising.
https://clojure.org/news/2025/06/06/deref
>https://jank-lang.org/blog/2025-06-06-next-phase-of-interop/

>>105530105
You're just not as smart as you very obviously think you are. Coalton does not need to be an independent dialect. The fact you can do this means you're completely wrong right from the first sentence.

>>105530105
>It's not a standalone Lisp dialect.
It is, though. Common Lisp is a Lisp-2 while Coalton is a Lisp-1. It is its own language that just happens to have very good interop with Common Lisp due to being implemented as a CL library.

>>105527496
>>105527550
You could implement addition using minimal primitives a few ways (the chars 0-9 can just be symbols):

;; peano
> (+ (quote (1 1 1)) (quote (1)))
(1 1 1 1)
;; binary
> (+ (quote (1 1 0 0)) (quote (1 0 0 0)) 0)
(0 0 1 0)
;; decimal
> (+ (quote (1 3)) (quote (1 1)))
(2 4)

Binary addition would look like (from wikipedia's truth table):

(set (quote +)
(lambda (a b c)
...
(if (and (eq (car a) 0) (eq (car b) 1) (eq c 1))
(cons 1 (+ (cdr a) (cdr b) 0))
...

If you're curious my lisp interpreter uses 93 lines of C to implement these primitives:

Pair *env =
...
intern("lambda"),
intern("if"),
intern("<"),
intern("+"),
intern("quote"),
intern("macro"),
intern("cons"),
intern("car"),
intern("cdr"),
intern("set"),
intern("null?"),
intern("pair?"),
intern("eq?"),
intern("not"),
intern("="),
intern("-"),
intern("string-length"),
intern("string-ref"),
intern("eval"),
intern("apply"),
intern("load"),
intern("display"),
intern("newline"),
intern("expand"),
intern("inspect"),
intern("radix"),
intern("environment"),
intern("symbols"),
intern("memory"),
intern("clear"),
intern("exit"),
...

and these derived forms in 337 lines of lisp:

t nil list caar cadr cdar cddr append splice cond quasiquote qq qq-list define define-macro map begin let letrec for assoc length filter reduce nth reverse when unless member union intersection > <= >= != and or abs * / quotient remainder min max iota ! modulo even? odd? for-each zero? negative? positive? assoc-let zip format-internal format

< and = is enough to implement > <= >= != min max even? odd? zero? negative? positive?
+ and - is enough implement * / abs quotient remainder iota ! (and expt, which i forgot)
so if you add a few more primitives your Lisp can be pretty featureful while keeping the implementation minimal, gl anon

>>105530021
I don't think anyone is actively working on an org-mode for Lem, so you can't really say yet.

>>105529890
>got bitten by the Haskell bug
oh no, did he get aids? oh ligma, oh my shrigma

>>105527756 (OP)
Is there anything lisp like for android. CL would be ideal.
I just need simple apps. Picolisp didnt work.

>>105531572
>lisp like
Clojuredart
https://github.com/Tensegritics/ClojureDart
But you need to know Dart and Flutter at least a little bit, I can imagine it being quite painful without those

>>105531572
clojurescript or anything that compile to javascript or wasm.

>>105527496
you could start from (λ) then rely on church encoding but it wouldn't be really usable. https://en.wikipedia.org/wiki/Church_encoding

there is also this amazing code from SICP
(define (cons x y)
(lambda (m) (m x y)))

(define (car z)
(z (lambda (p q) p)))

(define (cdr z)
(z (lambda (p q) q)))


here, you defined the pair type only with lambdas. now that you have a pair, you can have a list, then a string, then ...

i also remember a dude doing an advent calendar of lisp where he programmed a little lisp with different programming language everyday. i can't find the repository.

>>105531572
I have the ability to run Racket on my Android phone
no clue how it works (I fuckin hate phones) but it works
I even have Vim, which is crazy

Sophie on the /g/!

Is it normal that Lisp doesn't "click"? I've been trying Scheme and problem solving with it, and it has been somewhat interesting to notice the differences in design I've come up with compared to a language like C. But it all feels "hacky", the algorithms I've written do not look natural but rather built around Lisp's syntax less so than thinking about the actual problem (which is the inverse of what I've heard about the languages), so I've wondered if anyone else has went through this.

>>105532697
Scheme is about composing with expressions and more specifically lambda expressions. You should not think with statements, like you would do with c++ or java, but with procedures. I would say that trying to take advantage of apply will make you closer to the lisp philosophy.

in c, you would check if a list/array is ascending ordered with a loop made of statements and operators, something like this
bool is_ascending (array a)
{
for (int i = 1; i < a.length(); ++i)
if (a[i] < a[i - 1])
return false;
return true;
}


in Scheme, < is a procedure, not an operator; it takes an arbitrary amount of arguments.
you can apply those arguments as a list with apply, so you would just do (apply < a)
apply is extremely powerful and makes you think differently than with c/java/...

ok but what is lisp for

>>105533070
LISt Processing. Shrimple as.

>>105533070
controlling the behavior of computers

>>105533070
A formal medium for expressing ideas. Like a musician would describe a song with a music sheet for others to play, or like an architect would describe a building with a plan for other to construct, a programmer describes a program with lisp expressions. You share ideas with others by writing them down in a formal medium.

>>105527921
512-byte? That's pretty neat.

>>105533184
nice shrimple, anon
mind if i take it?

>>105531875
>>105531875
I wrote Disorganized in ClojureDart and I knew exactly 0 Flutter or Dart before starting. Even now, one year into it, I don't really know Dart. Remember to join #clojuredart in the clojurians slack if you want to get started.

>>105530105
GOAL was implemented on top of common lisp just like Coalton is you absolute nigger mongrel
GOAL itself was basically a DSL on top of allegro common lisp that compiled to ps2 machine code

>>105532564
It's meruru for me

>>105536171
Me too actually. I was just surprised.

>>105536205
Based and barrelpilled

ok so after some random anon recommended racket this has been my first s-expression lang. it's quite cool. ive been doing code golfing and leetcode. so far ive discovered that doing mutations generally perform way better than greedy fold/accumulator with #:result expression.
this is quite sad as i was hoping for a full functional way and good performance. still, coming from BEAM racket has performed way faster with a ton of data structures built in. better yet racket actually fit in to the usecase of my other project for defining DSL. i am conflicted as it "feels" wrong to write "mutation" code but you can't argue with performance.

Example 0 ms leetcode 2657

#lang racket

(define (find-the-prefix-common-array a b)
(define counts (make-vector 51 0))
(define total 0)
(for/list ([x a] [y b])
(vector-set! counts x (+ 1 (vector-ref counts x)))
(when (= 2 (vector-ref counts x)) (set! total (+ total 1)))
(vector-set! counts y (+ 1 (vector-ref counts y)))
(when (= 2 (vector-ref counts y)) (set! total (+ total 1)))
total))

(find-the-prefix-common-array '(1 3 2 4) '(3 1 2 4)) ; 0 2 3 4
(find-the-prefix-common-array '(2 3 1) '(3 1 2)) ; 0 1 3



no mutation
(define (find-the-prefix-common-array a b)
(define updateit (curryr hash-update add1 -1))
(for/fold ([h (make-immutable-hash)]
[out empty]
[count 0]
#:result (reverse out))
([a a]
[b b])
(let* ([h (updateit h a)]
[left (if (= 1 (hash-ref h a)) 1 0)]
[h (updateit h b)]
[right (if (= 1 (hash-ref h b)) 1 0)]
[new-count (+ count left right)])
(values h (cons new-count out) new-count))))


for some reason multiple `define` in the body is faster than `let*` as well.

>>105536469
forgot to say

40 - 50ms on the let* version
30 - 45ms with define (could be statistically insignificant)
0 - 10ms with full vector-mutation

https://www.youtube.com/watch?v=sV7C6Ezl35A
>ywn work on a Lisp machine

>>105536469
>for some reason multiple `define` in the body is faster than `let*` as well.
You'd have to macroexpand to see what racket is doing, but conceptually
(define (f x)
(define y 2)
(define z 3)
...

(f 1)
extends the local environment but keeps it a single alist:
(((z . 3) (y . 2) (x . 1)) calling-environment)
whereas
(define (g x)
(let* ([y 2])
([z 3])
...

(g 1)
if let* expands into nested lambdas the environment will be extended with multiple alists:
(((z . 3)) ((y . 2)) ((x . 1)) calling-environment)
so looking up x in the body of let* in g could be more expensive than x in the body of f, maybe that's it?

>>105536675
yeah i just vibed with Claude and it told me everytihng

define is just a "scope variable binding" it doesnt get re-evaluated unless i told it to (with set!) therefore my solution was inefficient because im recreating an immutable hash 3 times, updateit x2 and values h (fold return statement)

they mainly recommend using hash as a mutable ref and update it explicitly (with hash-set!)

>>105536648
>15 hours ago
Neat ty anon

I'm currently working through SICP. It's incredibly difficult. My brain feels like absolute mush when I spend a lot of time on it, to the point where I'm dropping my wallet three times in a row when I pull it out to use it and running stop signs. My wife is worried about me. She doesn't understand that I'm trying to become a wizard.

>>105536675
I seriously doubt that they really represent environments with alists

>>105536469

45 ms:
(define (find-the-prefix-common-array a b)
(let loop ([out '()]
[aa (reverse a)]
[bb (reverse b)])
(if (empty? aa)
out
(loop (cons (count (curryr memq bb) aa) out)
(cdr aa)
(cdr bb)))))


30 ms with an explicit lambda instead of currying ( (lambda (n) (memq n bb)) )

>>105529795
They tend to argue that only things with a direct lineage to McCarthy's Lisp, so they'd also include now-dead dialects like ZetaLisp, Interlisp, Maclisp, etc., but since those are all dead, it does seem a bit silly to say that Common Lisp is the only real Lisp.

>>105536469
If the immutable hashmaps are represented via binary trees, every hash-update or hash-ref is O(log(n)), compared to O(1) with mutable vectors. Maybe they use HAMT or something complex though, then the asymptotics should be similar.

>>105536648
>xah cited as a source
Absolutely faantastic

>>105536469
>>105537003

20 ms using for/sum instead of (count)
(define (find-the-prefix-common-array a b)
(let loop ([out '()]
[aa (reverse a)]
[bb (reverse b)])
(if (empty? aa)
out
(loop (cons (for/sum ([e (in-list aa)]
#:when (memq e bb))
1)
out)
(cdr aa)
(cdr bb)))))


19ms with a (do)
(define (find-the-prefix-common-array a b)
(do ([aa (reverse a) (cdr aa)]
[bb (reverse b) (cdr bb)]
[out '() (cons (for/sum ([e (in-list aa)]
#:when (memq e bb))
1)
out)])
((empty? aa) out)))


but the timing on leetcode is too random, it's unreliable.

>>105536648
what would it take to bring back the Lisp machine, even if in spirit?
is Emacs the closest we'll get to it, or can we do better somehow?
Literally every boomer who worked on them seems to have nothing but praise for them

>>105529589
unironically cute, protect this feeling of joy

>>105537025
Okay, I'm confused. What do they mean by N here? Anyway, if hash operations are k times slower than mutable vector operations (while still being O(1) - just with a big constant), you'll get 4×k slowdown. I think it may be worthwhile to benchmark just hash-refs, benchmark just vector-refs, and compare them.

>>105537143
You can try one in an emulator: https://archives.loomcom.com/genera/genera-install.html
IMO, modern Emacs is better in almost every aspect.

And if you really think that specialized instructions in hardware make sense, go read "Digital Design and Computer Architecture" (or something similar), practice Verilog and buy an FPGA. Hell, maybe even write an eDSL in Lisp for hardware design.

>>105537114
okay, 10ms using unsafe operations and fold instead of for/sum

(define (find-the-prefix-common-array a b)
(do ([aa (reverse a) (unsafe-cdr aa)]
[bb (reverse b) (unsafe-cdr bb)]
[out '() (cons (for/fold ([acc 0])
([e (in-list aa)]
#:when (memq e bb))
(unsafe-fx+ acc 1))
out)])
((empty? aa) out)))


(in-list aa) is probably using safe operations so you could go even faster with your own fold+unsafe operations.

>>105529890
>Also, representing big numbers concisely as a product of their factors is what people always do when programming in Brainfuck. The difference with interaction combinators seems to be that 2×2 is not a "normal form" (whatever that means for an imperative language) in Brainfuck, while it is in interaction combinators.
Just curious, where is it that people discuss how to program effectively in Brainfuck that they talk about stuff like this?

>>105537191
HAMT needs to be very shallow for the lookup to be quick, but the trie branching factor is limited to the machine word size (like 32 or 64bit). AFAIK.

why does everyone hate the parentheses? i think they are pretty.

>>105537674
I learned this trick here: https://brainfuck.org/ggab.html (see e.g. "+++++[>++++++++<-]" and corresponding comment in the first program)
Trying to find this link again now, I also found https://www.iwriteiam.nl/Ha_bf_numb.html, it should be interesting to you as well.
I'm not aware of any active BF community if that's what you mean by "discussions", but I'd try https://codegolf.stackexchange.com

>>105537853
>https://brainfuck.org/ggab.html
>https://www.iwriteiam.nl/Ha_bf_numb.html
Thanks for the links. Those seems like cool websites.
Yeah, trying to actually program in Brainfuck seems so opaque to me that it surprised me that a trick like that existed, and made me think there was some community.

if i spend a year inhaling the wizard book, am i going to be unemployable? i mean, i'm already unemployable, so nothing would change but it'd be nice to set expectations

>>105537793
Same. I feel like it's a very natural and elegant way of writing a program. I've come around to the view that some people can't be persuaded to think in the right way to really get Lisp. Which is fine, although their hostility is annoying.
As much as I hated tumblrites using Harry Potter references for everything, the wizardry references in the OP and recently in the thread put the idea in my head that languages are like wands in the sense that the wizards were always told that the right wand chooses the wizard rather than the other way around. I think some people are actually naturally meant for languages like C, Rust, Java, Python, Lisp, Haskell, and there is only so much you can do to get them to love a language that won't ever love them back. I don't mean this disrespectfully either.

>>105537793
Because people get filtered and then cope.

>>105538049
"We conjure the spirits of the computer with our spells"
https://docs.scheme.org/sicp/book-Z-H-9.html

>>105538223
I wish there were Frieren SICP art

>>105537755
So N is the base of the logarithm? Really weird notation. Also, those -2 bits (for tagging?) are probably detrimental for perf, unless they use actual unsafe bitshifts (and at this point they might as well store data in the tag bits to get slightly more branching).

I'm still not sure about "log N is limited to less than 30 or 62" (log_{30}(2^32) is 6.52, and you obviously can't have more elements than bytes in your memory). I'm just going to assume that someone fucked up writing Racket docs. Like, HAMTs aren't even mentioned (maybe they use some other purely functional associative array and all those speculations are in vain). Hopefully it's just me being dumb and missing something obvious.

>>105538299
Read SICP and achieve satori.

>>105538049
I think honestly most people would be better off programming exclusively in forth. They don't like/understand abstraction and are happiest with explicit direct imperative instructions. The key being they simply cannot stand holding a lot of information in their heads at once and so the straighter the "line" of execution is the easier they find it.

>>105534509
how's mobile dev work with that? I've never done mobile but I'm thinking about giving it a whirl

>>105538408
>log N is less than 30 or 62
It's saying the machine address size is only 32/64 bits so even if you put your entire computer's memory into a tree it's only be 32/64 levels deep. This means at absolute maximum any operation is going to be 32/64 times slower than a single memory lookup. But that's so fast it's basically meaningless and is vastly overpowered by any of the logic in your program.
It's actually much less than 64 since 2^64 is so gigantic you could put ALL DATA ON EARTH into a tree significantly less than 64 levels deep. Though doing so would drastically increase the execution time simply because of the physical latency of the speed of light, let alone switching time and disk access.

>>105536727
>My wife
Found the problem. Divorce your wife and you will instantaneously grow a long hoary beard and a robe will materialize out of thin air.

>>105527756 (OP)
What do our lisp-sisters think of other FP adjacent languages such as ML (Ocaml, F#, etc.), haskell, or BEAM langs (erlang, elixir)? I'm curious.

>>105540132
Unironically love Haskell's ideas, also quite fond of OCaml, but I'm not sure you can call Haskell FP-adjacent. It's really all-in on functional programming, much more so than Lisp ever tried to be.

>>105540132
i really need to find a deepdive on how erlang actually works in its guts
everyone seems to tout how it's massive and reliable and fault-tolerant and message-passing and async and whatever and i'm just thinking "if erlang message passing is just shared memory pointers or proprietary byte encoding when over the network i will freak"

>>105540220
>but I'm not sure you can call Haskell FP-adjacent
I just used the word 'adjacent' to be concise :3

>>105537793
Lisp is comfy to read but annoying to edit by hand without a proper editor setup, compared to something like Python that can be hacked out comfortably in notepad.

>>105527756 (OP)
Can Lisp ever be a efficient as C or is it destined to be slower due to the way it was designed?
I want to write a native Lisp, but the requirement for cons cells to exist at runtime completely screws up efficient code generation.

>>105538049
>there is only so much you can do to get them to love a language that won't ever love them back
This is me with Lisp. It's because I naturally think at a much lower level of abstraction than most people and I don't feel comfortable working at such a high level.
I love embedded assembly and C programming, but Lisp just doesn't allow me to work with bare metal code as efficiently.
I don't want a GC getting in the way, and I don't want to be forced into pretending that cons cells from an IBM machine of the 50s is how things still work today.

Just give me a proper native Lisp without the cons cell legacy cruft and I'll worship this language for the rest of my life.

>>105537143
>what would it take to bring back the Lisp machine, even if in spirit?
Maybe burn a cadr processor into a fpga and port/update genera to it? Something simple enough you can either build a cyberdeck around it or plug it in to a pc

>>105538448
It's a good experience, that's the point after all. Pretty crazy that we can build cross platform apps in lisp.

>>105540898
>put lisp in jvm
>jvm runs on billions of devices
>get cross-platform lisp

>>105537793
Doesn't look like the first language they learned.

>>105540399
>compared to something like Python that can be hacked out comfortably in notepad.
It's not comfortable at all. You desperately need batch indent/de-indent and your editor to line up indentation as you type.

>>105540940
>doesn't run on iOS and Android

>>105540132
Standard ML is King, it's basically Scheme with types

>>105540524
>Can Lisp ever be a efficient as C
For me it's Pre-Scheme (https://prescheme.org) or Chicken Scheme's CRUNCH (https://www.more-magic.net/posts/crunch.html).

>>105540784
I also work at low level irl (high performance stuff) and I find high level languages tremendously useful
After all, if you ask someone to describe what it is you're doing, you naturally describe in high level language the big picture (what to do) and then implement it as a matter of technique (how to do it).

>>105536648
>>105537098
based emacman

>>105527756 (OP)
is land of lisp actually a good book to learn lisp

>nREPL for GNU GUILE
You need to install these two tools

>GNU EMACS Ares
https://github.com/abcdw/guile-ares-rs

>GNU EMACS Arei
https://github.com/abcdw/emacs-arei

It's pretty cool.

>>105540524
You may not know it, but C is actually ludicoursly slow and inefficient compared to most lisps, or even several scripting languages. It gets away with this by doing all the compilation and optimization it can before running in as small an environment as possible. If you implemented even half the functionality of lisp into C it would be excruciatingly slow and unwieldy. Meanwhile lisp can easily beat C in performance just by running handwritten assembly.

>>105527756 (OP)
I have seen people do very small pieces of code that transpile to other languages in a readable fashion, in lisp. I'm not a lisp man, but how does one get good enough in lisp to do this? any good write ups that aren't too contaminated with academic bs?

>>105540524
>Can Lisp ever be a efficient as C or is it destined to be slower due to the way it was designed?
There's a chance that in the future the fastest language with GC will be Roc: https://youtu.be/vzfy4EKwG_Y?t=1683
You can look through that talk about all the optimizations he did. But the point is that even if he has the luxury of being a very experienced language creator, working on a new platform, in a statically typed language, Roc is not quite as fast as C++.

So now, given that most lisps aren't even statically typed like Roc, which also can come with a performance hit, what do you think?

>>105540524
HVM is a lisp and it's ~10,000x as fast as C, runs on GPUs using an infinite number of threads in parallel, and is continuously garbage collected during runtime.
You can literally cross compile C code into it and beat the native version easily.

>>105540132
I use OCaml almost daily and love it.
>>105541347
>~10,000x as fast as C, runs on GPUs using an infinite number of threads in parallel
I think saying such things is harmful, even if pleasant in short-term

>>105541007
That CRUNCH link is dead, it returns a 404.

>>105541347
>HVM is a lisp and it's ~10,000x as fast as C, runs on GPUs
>runs on GPUs
>GPUs
Into the trash it goes. I don't care about nshitia hardware. I just want something that runs well on a CPU without shitty "hardware acceleration" requirements.

>>105541316
>Roc is not quite as fast as C++
I don't like the contrived benchmarks that are generally presented on these talks. They're too unrealistic.
No, Javascript isn't almost as fast as C++. It's not as close as that benchmark makes it look. The performance of quicksort doesn't represent the overall performance of a programming language in real world code.

Honestly, these are more harmful than helpful. Would have been better to demonstrate the performance of a quake-style software rasterizer in each language, rather than quicksort. At least that would have properly demonstrated the actual differences in performance.

>>105541955
>I don't like the contrived benchmarks that are generally presented on these talks. They're too unrealistic.
If you go back you'll find that he actually agrees with you.
Benchmarking is difficult but he chose this example as something that functional languages were traditionally bad at.

>>105541717
I mean it also runs on CPUs, just 10,000x slower. Is suppose if you got one of those 128 core workstations it would speed up again a decent amount.

>>105541578
>I think saying such things is harmful, even if pleasant in short-term
It's got a lot of other problems,the scalability isn't one of them currently.

>>105542030
>as something that functional languages were traditionally bad at
That's because functional programming languages traditionally preferred immutability and eliminating side effects.
You optimize it by... removing those restrictions. It's not that impressive when all languages on that list either don't have it, or cheated their way out of such restrictions.

I don't think you can still call your language functional if you're forced to optimize it by turning the code into procedural-style s-expressions with unrestricted side effects.
I would love to see a procedural Lisp though.

https://github.com/hyotang666/common-lisp-pitfalls

>>105540524
>Can Lisp ever be a efficient as C or is it destined to be slower due to the way it was designed?
(define (compile term table reg)
(match term
[(? number? n)
(let ([a (reg)])
(format #t "mov r~a, #~a~%" a n)
a)]
[(? symbol? s)
(let ([a (reg)])
(format #t "mov r~a, r~a~%" a (cdr (assoc s table)))
a)]
[('+ left right)
(let ([a (compile left table reg)]
[b (compile right table reg)])
(format #t "add r~a, r~a, r~a~%" b b a)
b)]
[('let binds scope)
(let* ([syms (map car binds)]
[vals (map cdr binds)]
[n (length binds)]
[regs (iota n)])
(format #t "~:{mov r~a, #~a~%~}" (map cons regs vals))
(set! reg (counter (- n 1)))
(compile scope (append (map cons syms regs) table) reg))]))

(define-syntax test
(syntax-rules ()
[(test program)
(compile 'program '() (counter 0))]))
(test
(+ 2 (+ 3 5)))
mov r1, #5
mov r2, #3
add r1, r1, r2
mov r3, #2
add r1, r1, r3
(test
(let ([a 2]
[b 3])
(+ a (+ b 5))))
mov r0, #2
mov r1, #3
mov r2, #5
mov r3, r1
add r2, r2, r3
mov r4, r0
add r2, r2, r4
screw c i'm already as fast

>>105529897
what does "live image" mean in this context?

>>105540254
Each Erlang process is a green thread that absolutely never shares memory with any other process---if a process crashes, this means it cannot leave memory used by other processes in an inconsistent state; this also means each process is separately garbage collected, so there are no stop-the-world GC pauses.
Each process is preemptively interruptable. The scheduler will distribute all processes across however many CPU cores you have configured, and will actually count the number of operations executed by each process, and will move to execute another process the moment some configurable number of operations have been executed (called reductions in Erlang parlance)---it is impossible for any process to hog CPU time (this is in contrast to many other green thread implementations, where explicit yielding points are embedded into the executable, and thus loops over things like gigabyte-sized vectors might consume much CPU time without ever yielding). Even the per-process garbage collection is bounded by reduction count.
Process--process communcation is via message passing, where each process has an inbox. When you send a message from process1 to process2, there is no blocking involved. process2 might never receive the message, thus, if you need to guarantee that process2 has received the message, it must send back an acknowledgement message to process1. With this, we can now place processes on separate servers (if a server fails, it cannot return those acknowledgement messages). This prevents the need for a separate networking abstraction to be interacted with, it's just the default in Erlang.
Processes can be organized into supervision trees, where child-processes failing can be dealt with in any way you program them to. This provides a high-level abstraction over dealing with failures. This high-level abstraction can be leaned on to avoid writing a bunch of error-handling logic for niche error classifications.

>>105543113
The running program is the entire dev environment and can be interactively altered at any moment and even entirely recompiled, all without losing state. So you can for example setup your dev environment, load all your packages, then halt the program, dump the image to disk, and later restart it instantly from where you left off. Or you could run a program, hit an exception, interactively examine the program state and debug it, redefine various functions, alter the state in the current scope, rewind up the stack, and then continue where you left off.

It's a program more akin to a computer with hibernation enabled. Imagine a normal language that core dumps, but you're able to load that dump, alter it, and resume running it.

>>105537316
>do
>unsafe
woah wtf i gotta look into this

>>105543299
In short: Erlang is a very well designed system, and many have tried to replicate it in other languages, but it just will not work. All of these things must be present for such a system to function correctly.
You should use Elixir however, it has macros, can trivially call ANY Erlang functionality, and has a super nice enumerable/lazy streaming system, allowing you to avoid the need to write countless TCO recursive functions.

>>105543300
This would have been much easier to implement for other Lisps if there was native OS support for it.
Suspending execution of a program and dumping the address space to disk is something the kernel is already responsible for. That's basically how threading and swap memory works, it's dumb to re-implement those in userspace.
That's something a Lisp OS could do natively, and if you want it to be competitive with existing kernels then you need a bare metal Lisp that can compete with C in efficiency.

>>105543643
This reminds me of application snapshots from DragonFly BSD
https://en.wikipedia.org/wiki/DragonFly_BSD#Application_snapshots

>>105541234
not really
a gentle introduction to symbolic computing is better, if you're new to programming, otherwise practical common lisp, ansi common lisp, on lisp, etc are good

>>105543643
The snapshot part isn't really the emphasis, it's made possible by the actual major feature: being able to completely mutate the entire program state of a running program, including all the executable code itself. In essence it's self-modification that makes an image based language, and program can mutate itself into any other program dynamically.
This lets you easily implement suspend/resume by starting, loading the state from an image, and mutating your own state to match it. But that's really just a side effect.

>>105543806
thank you
i'm not really new but I think starting over would be a good idea

>>105537793
They see it as mathematics formulas instead of s-expressions. Coloring the expressions instead of symbols/tokens may help to change that

http://lemonodor.com/archives/001207.html

There was also SchemeBricks, a live coding environment where the s-expressions are represented as colored blocks that you can move around.

https://vimeo.com/62615513

>>105543835
>being able to completely mutate the entire program state of a running program, including all the executable code itself
That's also the responsibility of the kernel. Changing pages from executable, to writable, and then back to executable to keep the W^X security policy intact. Would be more efficient if the kernel provided some functionality to avoid needing so many system calls.

>>105540524
What makes c faster is machine types and access to primitives operations like AVX. A tracing jit with thoses could defeat c (luajit is faster on some cases related to hashmaps despite the dynamic typing).

>>105543955
Also the lack of garbage collection. You go fast by executing less instructions and not trashing the cache. The act of garbage collection requires executing more instructions and destroying the L1 cache in the process.

>>105543949
no. a live program can introspect callstacks. a live program can serialize functions, send them over the wire, and recompile them
a live program can serialize its entire state, send it over the wire, and resume itself on the other machine.

>>105533070
AI programming before AI was cool

>>105544076
A program cannot modify its own executable code, while running, without the help of the kernel on a modern architecture. The hardware W^X protection won't allow it, it's the responsibility of the kernel to change the per page permissions (or disable W^X) to allow for self-modifying code.
Serializing the program and sending it to another machine (basically just compilation) has nothing to do with self-modifying code at runtime.

Resuming the program on another machine still requires the kernel to set up the executable pages properly, with a ton of system calls. This isn't magic, and having better kernel support for all of this would be much better.

>>105544165
nigga, a virtual machine's executable code is an AST in memory with read permissions, absolutely no different from a hash map on the heap in terms of access mechanics.

>>105544204
read/write perms*

>>105544204
>a virtual machine's executable code is an AST in memory
There are so many things wrong with this, I don't even know where to start. Who the fuck runs an AST interpreter in 2025? Ever heard of a JIT compiler?

>>105544288
>Who the fuck runs an AST interpreter in 2025
Python, Lua, Perl, Javascript, etc. contain numerous implementations made in this fashion
>Ever heard of a JIT compiler?
ever heard of premature optimization? I will build a project, and, if it becomes successful, I will consider hiring engineers to implement JIT compilation for me.

>>105544324
>Python, Lua, Perl, Javascript, etc. contain numerous implementations made in this fashion
they are bytecode interpreters

>>105544329
what exactly do you think bytecode is?
it's just memory that is processed by a loop, where the loop invokes calls based on the content of the memory.

>>105544356
That's not a syntax tree walking interpreter, though.

>>105544356
>what exactly do you think bytecode is?
not the ast. https://en.wikipedia.org/wiki/Abstract_syntax_tree

source code -> ast -> (ir ->) machine/byte code

>>105544373
welcome to the concept of Lisp, where your AST is your bytecode.
works fine for me.

>>105544356
>Implying that bytecode is an abstract syntax tree
Anon... I thought we Lisp users were smarter than this.

>>105544411
Being Lisp doesn't mean you have to run a slow AST interpreter, that's just laziness. It's so easy to compile Lisp to a stack machine bytecode that there's simply no reason not to do it. You can even design your own stack machine if you're not happy with existing ones.

>>105544458
given that I have actually implemented my own virtual machine with the ability to persist itself to disk and resume itself, I think I am quite aware of what goes into building such a mechanism.
I also think I am quite able to judge the different data structures that can be used to represent programs, and do not consider a stack machine to be necessary if you do not want to implement things that way.
I have written my own Forth too, here is an excerpt from that:
{<
false true
`a `b
<[foo] [bar]> <[baz] [buz]>
[foo] [bar]
{false} {true}
(0 1 2) (3 4 5)
> <
false true
`a `b
<[foo] [bar]> <[baz] [buz]>
[foo] [bar]
{false} {true}
(0 1 2) (3 4 5)
> equal} assert
{<
false true
`a `b
<[foo] [bar]> <[baz] [buz]>
[foo] [bar]
{false} {true}
(0 1 2) (3 4 5)
> <
false true
`a `b
<[foo] [bar]> <[baz] [buz]>
[FOO] [bar]
{false} {true}
(0 1 2) (3 4 5)
> equal not} assert
{<
false true
`a `b
<[foo] [bar]> <[baz] [buz]>
[foo] [bar]
{false} {true}
(0 1 2) (3 4 5)
> <
false true
`a `b
<[foo] [bar]> <[baz] [buz]>
[foo] [BAR]
{false} {true}
(0 1 2) (3 4 5)
> equal not} assert
{<
false true
`a `b
<[foo] [bar]> <[baz] [buz]>
[foo] [bar]
{false} {true}
(0 1 2) (3 4 5)
> <
false true
`a `b
<[FOO] [bar]> <[baz] [buz]>
[foo] [bar]
{false} {true}
(0 1 2) (3 4 5)
> equal not} assert
{<
false true
`a `b
<[foo] [bar]> <[baz] [buz]>
[foo] [bar]
{false} {true}
(0 1 2) (3 4 5)
> <
false true
`a `b
<[foo] [bar]> <[baz] [BUZ]>
[foo] [bar]
{false} {true}
(0 1 2) (3 4 5)
> equal not} assert

>>105544508
i remember in the olden days, you could get emacs to dump core after initialization, and then you could run "undump" on it to re-create an executable at the point where it dumped core.

we're talking dec vax 11/780 days here

is there a book like SICP but not as pretentious as it?

>>105544508
How can i share code like this?

>>105544558
https://www.emacswiki.org/emacs/DumpingEmacs

>>105544698
>>105076684
>To use the Code tag, book-end your body of code with: and

;; 1.3
;; Define a procedure that takes three numbers as
;; arguments and returns the sum of the squares of the two larger
;; numbers.
#lang sicp
(define (sum x y z)
(if (and (< x y) (< x z))
(+ (* y y) (* z z))
(if (and (< y x) (< y z))
(+ (* x x) (* z z))
(if (and (< z y) (< z x))
(+ (* y y) (* x x))
0
)
)
)
)

(sum 4 2 3) ;; ==> 25

>>105544570
HtDP I guess

>>105544850
You could find the minimum of the three and then subtract its square from the total. Thought of this getting bothered by the hardcoding.
Phoneposting, so I haven't tried it out.
(define (sum x y z)
(let* ((min (if (< x y) x y))
(min (if (< min z) min z)))
(- (+ (* x x) (* y y) (* z z))
(* min min))))

>>105544850
>>105545035

you could build a truth table
(define (sum x y z)
(or (and (>= x z) (>= z y) (+ (* x x) (* z z)))
(and (>= x y) (>= y z) (+ (* x x) (* y y)))
(and (>= y x) (>= x z) (+ (* y y) (* x x)))
(and (>= y z) (>= z x) (+ (* y y) (* z z)))
(and (>= z y) (>= y x) (+ (* z z) (* y y)))
(+ (* z z) (* x x))))


but >= being a procedure, not an operator, you could simply do
(define (sum x y z)
(or (and (>= x y z) (+ (* x x) (* y y)))
(and (>= x z y) (+ (* x x) (* z z)))
(and (>= z x y) (+ (* z z) (* x x)))
(and (>= z y x) (+ (* z z) (* y y)))
(and (>= y x z) (+ (* y y) (* x x)))
(+ (* y y) (* z z))))

>>105545035
That is a good solution.

>>105545075
Dear jesus

lisp is a turning tarpit. delete this thread.

>>105545075
But that has a different answer for each possible ordering, and you only need the minimum to compute the answer.

>>105544850
(defn my-sum [x y z]
(let [[a b] (reverse (sort [x y z]))]
(+ (* a a) (* b b))))

>>105545512
stuff like reverse or sort are not available. this exercise is at the beginning of sicp.

>>105544899
thanks

>>105537143
Smalltalk pharo is like that: an environment where everything is inspect-able, modifiable, ... you can save, share or load an "image" to restore the entire state.

https://pharo.org/features

>>105544850
(defun sum-of-squares (a b c)
(apply #'+ (mapcar (lambda (x) (expt x 2))
(remove (min a b c) (list a b c)))))

>>105537143
>Literally every boomer who worked on them seems to have nothing but praise for them
Or maybe the boomers who worked on them without praising them just stopped fucking talking about them 35 years ago.

>>105546493
You’d expect to see someone chime in with negativity at some point but the environment appears to have been a real high note

>>105544850
Is this good
(defn sum- [x y z]
(apply max
(map (fn [[a b]]
(+ (* a a) (* b b)))
[[x y] [x z] [y z]])))

>>105546318
#lang racket

(define sum (compose (curry apply +)
(curry map (curryr expt 2))
(λ n (remq (apply min n) n))))


(define (sum . args)
(apply + (map (curryr expt 2) (remq (argmin identity args) args))))

still love lisp even though i got filtered by SICP like fifty pages in

>>105541316
>Roc
my god this is perfect for me who is an elixir enjoyer

>>105542679
>You optimize it by... removing those restrictions. It's not that impressive when all languages on that list either don't have it, or cheated their way out of such restrictions.
You're really just repeating what he said himself. Watch the entire talk, I think you will enjoy it.

Have all these people using emacs been using it for 20+ years? There's no way it's worth getting into now.

I wake up and start thinking about lisp

>>105546629
Keep going. Ask for help if you need it. Look up solutions if you have to, learn more. Become a magician.
>>105547660
I got into it only last year. I don't really understand all its features, or even most of it, but I love it as an editor. You can just do anything you want to it. It feels freeing.

Should I work on the wizard and dragon books concurrently or just keep on focusing entirely on the wizard book?

>>105547660
>Have all these people using emacs been using it for 20+ years?
6 years for me.
>There's no way it's worth getting into now.
Absolutely, now there's <shiny new thing> that has almost half the features of Emacs with just double the effort of executing them.

I've been thinking, assembly is untyped. Why are all system langs statically typed? Technically you could build a lisp where everything is *void and it should be as performant as the next systems programming language?

>>105548336
Is it untyped? It strikes me that you could make an argument for assembly being the most strongly-typed language there is: every value is a bitstring of fixed width or it is nothing. Where the extrinsic value of an arbitrary integer is undecidable in a higher level language without further runtime clarification and directly human-imposed meaning, so is the value of a bitstring in assembly. You must decide the value yourself -- the machine can't do it for you.

>>105548336
>assembly is untyped
the operations are typed. you have to pick the correct instructions to add a float to an integer, for example. and to do that you must know what is a float and what is a integer.

>>105548336
In general, your options are:
- Sound static type system which provides guarantees that certain runtime problems are impossible (think adding int to string)
- Tagging values and doing runtime checks. Some stupid statically-detectable errors will be detected at runtime, but at least they will be detected.
- Don't do anything. If you fucked up, you're fucked. Silent data corruption, undefined behavior.

>>105547743
If you really want to read the dragon book, skip 318 pages of syntax analysis (Ch. 2-5), it's useless for compiler construction. BTW, there are Lispy books about programming language development (like EOPL). And if you want nitty-gritty optimizations, then don't bother with novice books and use something like Muchnik's "Advanced Compiler Design and Implementation".

>>105548845
I don't want to read it. I want to own it from start to finish, but I want the reward of doing so to be commensurate with the wizard book.

>>105548336
>I've been thinking, assembly is untyped. Why are all system langs statically typed?
Well, you could have a programming language like BCPL, where everything is a machine word and only the operations are typed, like assembly.
But C has types because they help. Pointer types let you not confuse integers and addresses (at the cost of limiting flexibility with address arithmetic). Structures let you give names to offsets so you can actually write stuff like "s->a = 568008;" and not "*(s + <offset of a>) = 568008". That helps if you ever change the layout of a structure, too, so you don't have to change all the offset values in your code.
Also, differently sized types were added to C because B and BCPL only manipulate objects of machine word size. For ASCII strings, you had to pack and unpack the bytes into words. This was ridiculous to do when they got a byte-addressed machine that could manipulate bytes in assembly, but not in B.
Also, on some CPUs, like ARM64 ones, accesses must be aligned (e.g. 8-byte accesses must be from an 8-byte aligned address). Having different types automatically aligns those addresses at declaration and helps you not make unaligned accesses, unless you make weird casts that strictly conformant C technically doesn't allow. Then you'll get a hardware exception on the unaligned memory access.

I spent four and a half hours studying SICP today. My biggest stumbling block was an exercise where the book asked me to imagine a Scheme where lazy evaluation was the default. I was too stubborn to write the trace of a simple GCD function and failed to realize that even though deferred calls absolutely were stacking up at a stupid rate, infinite recursion was prevented because the if form forces eager evaluation and therefore a base case will be reached. The rest was spent with the Fermat section and trying to debug (runtime) errors.

does anybody here use mezzano?

>>105548336
>Technically you could build a lisp where everything is *void and it should be as performant
It won't be because a decent compiler uses static types as optimization hints. You don't want everything including value types to be a pointer, that leads to unnecessary indirection (Java suffers from this).

If you really want a Lisp to be as performant as any other systems programming language then you need native compilation, strong static typing, an imperative programming style, less restricted mutation / side effects, and manual memory management (pick one: actually manual, defer statement, or RAII with linear types).
Game Oriented Assembly Lisp had some of those (it encouraged imperative code too), so it could compete with Assembly/C/C++ on the PS2. It's not impossible to make a Lisp as performant as C. It's just difficult to make it as readable, consistent, and elegant as an interpreted Lisp.

>>105550606
>Kernel-level generational garbage collection
No!

>>105550723
>https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
>"GOAL encourages an imperative programming style: programs tend to consist of a sequence of events to be executed rather than the functional programming style of functions to be evaluated recursively"
Why aren't we seeing more Lisps adopting this idea for better performance too?

>>105550723
Really you don't want any of those features, you just want the ABILITY to use them if you so choose. 99% of code is much better(and faster!) if you just use high level dynamically typed garbage collected code. For the remaining 1% it's useful to be able to drop down, turn everything off, and write tight imperitive loops.
But CL can actually already do this, hence coalton being literally compiled into CL. You can literally just hand write inline assembly and run it if you want to!
The real issue is it's just kind of a pain in the ass to do and some better less verbose syntax for it would be nice, but that's it really.

I'm completely new to LISP and am primarily interested because of "LISP machines" and "Expert Systems" from the 1980s.

It's extremely hard for me to find resources about what Expert Systems actually are from a technical standpoint. How they are implemented in LISP and how LISP machines would accelerate the workflows.

If there is any place on the internet that would know where to find resources about this specific topic it would be this thread.

You could have a lisp with no type but typed operations. For example, instead of (+ 2.0 4) you would have (+f32 2.0 (i32->f32 4)). I think web assembly IR is like that.

>>105552397
>Pass (+f32 a b)
>No runtime type checking because muh performance
>Completely wrong result because b was accidentally a pointer to a Car object
Not sure about this one.

>>105552481
You can do static type checking on the operations. Just check that b's last assignment came from an f32 returning function.

>>105552397
You can do this in Common Lisp. It's just optional.
Before defining functions you just call declare and pass in the types, sort of like function prototypes in C. You can also declare the types of variables too.

>>105552194
>99% of code is much better(and faster!) if you just use high level dynamically typed garbage collected code
Dynamically typed code can't be faster than statically typed code. For several different reasons, ranging from insufficient information for proper optimization, to wasting L1 instruction cache with multiple copies of the same function but slightly different for every type combination used.
Dynamic typing isn't magic, you're paying a runtime cost for the convenience. That runtime cost doesn't exist with static typing, therefore it's guaranteed to be faster in well written code.

Same with garbage collection. You pay in both performance and memory usage. Often, depending on the algorithm, efficient garbage collection requires the heap to be twice the size of the actual memory usage. I know that both Java and C# suffer from this, CL probably does too.

If you want to build a Lisp that actually competes with system programming languages, then your only choice is static typing, with no GC, and AOT compilation. Anything too dynamic would get in the way and prevent aggressive optimizations.
>inb4 "you're wrong because CL can do this and ..."
Please explain how you'd build a boot loader like GRUB, or the firmware for an embedded system, in a dynamically typed GC'd language?
There's no runtime support at that level to run a GC, and if your system Lisp can't do that, then it's not really competing in the same space as C/C++.

>>105552397
>I think web assembly IR is like that
Yeah, it has a format like (i32.add). It's a stack machine, so the operands are often implicit.

The parallels between gigi/kronii and imperislop/functional programmers is wild https://www.youtube.com/watch?v=ETErYf_PCJo
even down to the villager factory that leaks memory and not upgrading tooling

>>105552872
>https://www.youtube.com/watch?v=ETErYf_PCJo
What the hell is this. Are these grown men?

>>105553207
>Are these grown men?
>men
Not anymore, it seems.

>>105552661
>system programming languages
You can program an operating system in fucking javacsript, it doesn't matter. And there are literally embedded microprocessors running node right now. It's not the 60s anymore.
You use lisp because it's much better than C in every way and still more than good enough for performance.
If bleeding edge maximum performance is required, you'd be a fool to use C anyway, hand written assembly is the correct choice.

>>105552661
>grub
sectorLISP

>>105553372
>You can program an operating system in fucking javacsript
No, you can't. Any examples of it are either running on top of a browser or running on top of Linux with Node.
>You use lisp because it's much better than C in every way
Except for systems programming. That's the point of the post you're replying to.
>and still more than good enough for performance
Except for systems programming and specially anything close to bare metal.

>>105553572
Do you even know what systems programming means or is it just a meme to you?

>>105553681
You clearly don't. You've implied that Javascript is good enough, and "it doesn't matter".

>>105552235
I wish I could show you my university library, because I keep running into books about implementing expert systems and other forms of AI in Lisp from the 80s. I haven't read most of them, though.
I know that "Paradigms of Artificial Intelligence in Common Lisp" has a section on expert systems in chapter 16.

Common Lisp HTML Generation DSLs

==AllegroServe net.html.generator==
- https://github.com/sharplispers/portableaserve
==cl-who==
- https://github.com/edicl/cl-who
- https://edicl.github.io/cl-who/
==spinneret==
- https://github.com/ruricolist/spinneret
==flute==
- https://github.com/ailisp/flute
==hsx==
- https://github.com/skyizwhite/hsx
- https://code.skyizwhite.dev/paku/hsx

Are there any others?

racket saars....

i am still having FUN

>>105553712
So you don't then?

>compiled exe vs "racket ./1,rkt"
>compiled is faster
ok makes sense
>raco make 1.rkt
>generates bytecode optimised files
>running through the VM is now 1.2x faster
ok wtf

am i being retarded? wtf is happening here

code

#lang racket

(define _example1 "3 4
4 3
2 5
1 3
3 9
3 3
")

;; (define input1 (file->string "1.txt"))

(define (solve1 s)
(define parsed (map string->number (string-split s #px"\\s+|\n")))
(define l empty)
(define r empty)

(do ()
((empty? parsed) (set!-values (l r) (values (sort l <) (sort r <))))
(match-let ([(list a b) (take parsed 2)])
(set! l (cons a l))
(set! r (cons b r))
(set! parsed (drop parsed 2))))

(for/sum ([l l] [r r]) (abs (- l r))))

(solve1 _example1)

In a little under 1 hour, the lispy gopher show will be on.
Every Wednesday on 00:00 UTC:
https://anonradio.net/ (live stream)
https://lispy-gopher-show.itch.io/

>>105554833
Lispy Gopher?

>>105541316
The speaker in the video wrote a big effort-poast the other day.
https://lobste.rs/s/e8abqn/how_can_one_write_blazing_fast_yet_useful#c_hjio6d

>>105554832
When you compile with raco make, a file with scheme and machine code is generated in the "./compiled" folder. The VM load that file if it exists. You can do raco disassemble <compiled file> to inspect the code. Racket is also available on godbolt.org's compiler explorer.

>>105547707
>Look up solutions if you have to
i did that a few times and it felt like cheating. maybe i just have jeetcode interview brain or something

>>105554972
I don't know the origin of the name, but it doesn't seem to be that kind of gopher.

>>105556617
I mean after giving it a serious attempt

>>105552397
https://arcanesentiment.blogspot.com/2015/01/if-scheme-were-like-scheme.html
>>105552566
So (if foo 2.5 3) will be invalid? Might as well use Hindley-Milner type inference at this point.

>>105555996
yes but i also compiled the native machine code with raco exe and i was assuming that the final "production-ready" binary would be faster than machine code cache

I'm near the end of SICP's chapter 1 and this is by far the hardest problem set I've ever tried to solve in my entire life. That's not saying much since I've been a slacker for my entire life (arguably up until this precise point in time), but still. This book is an incredibly humbling experience.

They like, "Patxhy, don't you got asthma, ain't you fuckin' sick?"
Hell nah, I lied to the doc so I can get a script
Learned the motherfuckin' method, I make my own Actavis
And I'm smoking on this za, it's smellin' like some cat piss

>>105527756 (OP)
How many statically typed Lisps are there? Does anyone have a list with all of them?

>>105561505
i am only aware of typed racket, it's typing is highly reputed with quite a few academic papers.

>>105561505
There's Coalton and Shen.

Coalton
https://coalton-lang.github.io/ (Coalton Website)
https://github.com/coalton-lang/coalton/blob/main/docs/intro-to-coalton.md (Intro to Coalton)
https://x.com/killian_arts/status/1925029797438333420 (Toward safe, flexible, and efficient software in Common Lisp)

Shen
https://shenlanguage.org/

>>105540940
>lisp in jvm
So Clojure?

>>105544850
(define (sum-of-largest-squares x y z)
(+ (square (max x y z))
(square (- (+ x y z)
(max x y z)
(min x y z)))))

Mine sucks but i was naive

>>105561505
An extension to this same question: how many statically typed Lisps have generic types?
Static typing alone without generics is quite limiting. Are there any Lisps that implement parametric polymorphism too? (and is the syntax for them better than C++/Java generics?)

>>105540940
>compile lisp to c
>c runs on every device
>get cross-platform lisp
i believe there are some scheme implementations that can compile into very efficient c code

>>105563997
Is that the lion who got his balls bitten

>>105563997
>>105541007, also gambit

Are their hosting their shit on a fucking 2003 dell optiplex on dial up?

>>105558803
>So (if foo 2.5 3) will be invalid?
This is plainly a type error
(+ (if foo 1 1.0) 1)
but is this?
(+ (if true 1 1.0) 1)

>>105565351
Well, usually no one adds inference rules that integrate some kind of partial evaluation, because that will make everything very complex. Proving important properties like soundness would be really hard, and programmers won't have a clear mental model of your language, and errors will be kinda "brittle" - at least I feel that small code changes will produce errors in unexpected places with weird messages. And should we allow (if (even? (* 2 (read-int))) 1 1.0)? Or (if (contradicts-collatz-conjecture? (read-int)) 1 1.0)

Also, I'm a bit confused why wrapping with (+ · 1) matters to you. Usually people associate type with an expression so (if (zero? (read-int)) 1 1.0) is ill-typed regardless of the surrounding context.

(I'm using (read-int) here as a function that is impossible to evaluate at compile time and that can produce any integer)

>>105565351
IF returns either an integer or float, which means this IF has a union of integer or float. both are invalid, and trying to reason your way out of this with "but the float cannot be returned due to the constant" results in a brittle system.

>>105546941
Ok I've tried Roc:
- The standard library is so little (no string->chars have to walk over the u8s and pray)
- Performance is giga fast
- Half the time spent is appeasing the compiler
- Result type like rust but no unwrap only defaults???
- Doesnt suffer from cold boot like Racket compiled 200ms on day1 aoc 2024 EXAMPLE vs 1ms full day1 part 1 with text parsing in Roc

I feel compelled to create a library of utility functions, maybe Roc anons can recommend some if they exists already? Wherever I looked so far everyone has their own flat_map, fold, reduce etc in their utils.

app [main!] { pf: platform "https://github.com/roc-lang/basic-cli/releases/download/0.19.0/Hj-J_zxz7V9YurCSTFcFdu6cQJie4guzsPMUi5kBYUk.tar.br" }

import pf.Stdout

import "day1.txt" as day1: Str

# example = "3 4\n4 3\n2 5\n1 3\n3 9\n3 3\n"

parse = |s|
s
|> Str.split_on("\n")
|> List.map
|v|
v
|> Str.split_on " "
|> List.map |x| Str.to_u64(x) ?? 0
|> List.drop_last 1
|> List.walk
([], [])
|(left, right), v|
when v is
[a, b] -> (List.append left a, List.append right b)
_ -> (left, right)
# |> dbg

main! = |_|
# _ : List (List _)
total =
# parse example
parse day1
|> |(l, r)| (List.sort_asc l, List.sort_asc r)
|> |(l, r)| List.map2 l r Num.abs_diff
|> List.sum
# |> dbg

Stdout.write! "${Inspect.to_str total}"

>>105566765
vs racket

#lang racket

(define _example1 "3 4
4 3
2 5
1 3
3 9
3 3
")

;; (define input1 (file->string "1.txt"))

(define (solve1 s)
(define parsed (map string->number (string-split s #px"\\s+|\n")))
(define l empty)
(define r empty)

(do ()
((empty? parsed) (set!-values (l r) (values (sort l <) (sort r <))))
(match-let ([(list a b) (take parsed 2)])
(set! l (cons a l))
(set! r (cons b r))
(set! parsed (drop parsed 2))))

(for/sum ([l l] [r r]) (abs (- l r))))

(solve1 _example1)

>>105565247
https://gitlab.com/nonguix/nonguix/-/issues/395

;; Have you ever wanted to edit the current URL and load it while using eww?
;; It's something I've wanted to do often.
;; Now I can.
;; Also, if you give it a prefix argument, it'll open the URL in a new buffer
;; just like regular `M-x eww'.
;; C-u M-x eww-edit-url RET new-url RET
(defun eww-edit-url (&optional url)
"Edit the current URL and go to it with eww."
(interactive
(let* ((current-url (or (if eww-data
(plist-get eww-data :url))
(thing-at-point 'url))))
(list (read-string "URL: " current-url nil current-url))))
(message "%s !!!" url)
(eww url current-prefix-arg))

;; Have you ever wanted to edit the current URL and load it while using eww?
;; It's something I've wanted to do often.
;; Now I can.
;; Also, if you give it a prefix argument, it'll open the URL in a new buffer
;; just like regular `M-x eww'.
;; C-u M-x eww-edit-url RET new-url RET
(defun eww-edit-url (&optional url)
"Edit the current URL and go to it with eww."
(interactive
(let* ((current-url (or (if eww-data
(plist-get eww-data :url))
(thing-at-point 'url))))
(list (read-string "URL: " current-url nil current-url))))
(eww url current-prefix-arg))

>>105567436

>>105553372
>more than good enough for performance
How does lisp compare to C stuff for numerical algorithms? Say for solving differential equations.

>>105567767
I want to be very real with you: the performance of your code does not matter in literally 99% of cases. you can write a well-architected algorithm in Elixir and be faster than some naive C or Rust implementation simply due to choice of data structures. the difference in performance between optimized algorithms in Rust and Elixir is probably about 5x in favor of Rust. almost all of the time, these algorithms are ran by the software once every few minutes, and are working with datasets that result in execution times of a few seconds max.
it's far nicer to just ship some fucking code that does something cool, have a few users play around with it, and if it takes off as a massive success AND you actually run into performance issues, you can hire someone to rewrite it in Rust or whatever.
you will not be remembered as a person that perfectly optimized his todo app. you will be remembered as a person for coming up with a novel way to organize todos.
now, I personally write Rust, but not for performance reasons, but because it is a good language with which to structure ideas AND come back to them later on to add features.
optimize your language selection for productivity. there is ALWAYS a way to speed your shit up later if you really need to.

what are some neat guile projects besides guix and shepherd?

>>105568983
goblins, hoot (https://spritely.institute)
wip shepherd goblins port (https://codeberg.org/spritely/shepherd/src/branch/wip-goblinsify)
guile-emacs was recently resurrected
(https://codeberg.org/lyrra/guilemacs
https://codeberg.org/guile-emacs/guile-emacs
https://guile-emacs.org)

>>105567767
I couldn't disagree with >>105567949 more strongly. If you're doing serious numerical work then every bit of performance matters. Nobody uses anything but C, C++, Fortran, Rust, and much more the former 3 than the latter. You might use Julia, sometimes.
I personally used Lisp for metaprogramming in HPC but that's not the performance critical part. It just automates some of the other work, not the actual computations. You simply do not use Lisp for numerical algorithms.
Which should be fine. Use the language which fits the domain. In numerical work you care about memory access and all that, so use the languages which describe that. It's not a negative that it isn't one language which is the perfect tool for every conceivable problem. In this particular domain, it is an inappropriate tool.

>>105566765
>no string->chars
Is there a chance this was a design decision? These string representations are weird. See https://www.roc-lang.org/builtins/Str section on graphemes for example. Strings aren't a list of chars anymore.

>I feel compelled to create a library of utility functions, maybe Roc anons can recommend some if they exists already? Wherever I looked so far everyone has their own flat_map, fold, reduce etc in their utils.
I would stay easy on large Roc projects for now. They said they might launch alpha this year so hold out for that one, because there might be breaking changes.

>>105569466
I am the guy you disagree with. I remember writing a base X to Y encoding library in Elixir, such that one can generically do things like encode ASCII to base64 or whatever else you want to do (involves shrinking or growing data sets in length). lots of multiplication and division.
I remember being amazed when my test suite (not even optimized bytecode) processed 100k elements in a second
modern CPUs are very damn fast

>>105569955
I get the feeling we are talking about entirely different things. When someone says they're talking about numerical performance, to me I assume this is in the context of a serious problem. In those contexts we can never have too much speed, fast is never fast enough, and you really cannot get by without manually managing what is where in memory at what point of your computation. I have never seen anyone use anything but C(++), Fortran, or Julia, personally, and I don't think it would be taken seriously for serious work.
If he wants to tinker around with something just for learning, then by all means use whatever language, but as an example he should compare how even simple linear algebra is vastly slower in e.g. Java compared to C. Considering that differential equations are numerically solved to a large extent by linear algebra, this should really be enough to make the point that most languages are non-starters.

>>105569955
>processed 100k elements in a second
And for you it doesn't matter if C would have done it in 0.3 seconds because it's almost the same for you.
But if you're training a machine learning model, where training is on the order of days (the largest are on the order of months afaik) that difference suddenly makes a very real difference in your workflow.
Even "small" experemints easily take hours and suddenly the difference between Elixir and C is running one experiment per day or three.

Retard here. Is it possible to replicate picrel in emacs?

>>105569955
>100k elements in a second
For added context, that's quite small.
When doing differential equations as >>105567767 mentioned, I expect a few hundred Gflops per second. Less than 1 Mflop/sec would be considered unacceptably poor performance.

>>105570387
You can get stuff in columns, but the images are going to be trouble. They can be displayed, but scrolling is probably going to be janky.

Example of columns being possible:
https://github.com/rougier/nano-emacs/blob/master/images/nano-mu4e.png

>>105566774
aoc 2024? i did this
#lang racket
(define lists (for/lists (a b #:result (list (sort a <) (sort b <)))
([x (in-port)]
[y (in-port)])
(values x y)))

(displayln (apply foldl (λ (a b r) (+ r (abs (- a b)))) 0 lists))

(displayln (foldl (λ (x z) (+ (* x (count (curry = x) (second lists))) z))
0
(first lists)))

>>105569955
>>105570006
Realistically numerically serious problems don't exist.
And if you want to do them anyway, C, rust, C++, etc... are some of the worst choices possible. If you're not doing GPU acceleration you're a fool. And the GPU doesn't care what language you use to write the shaders, the performance is the same. Hence all those people using Julia and python.

Basically serious work on the CPU is a relic of a bygone time, or the obsession of optimization autists working on their hobby software rendering projects. For anything serious you're just using a language to automate the control of other much more optimized systems like databases, render farms, ai accelerators, etc... And in that case all that matters is ease of use, which boils down to library access and simplicity of syntax. Nothing else matters.

>>105566765
Please tell me that's not how Roc looks. It's as if Python, Java, Haskell, and Rust had an ugly child together. That's disgusting.
Also, why does Str.split_on and Str.to_u64 calls have parenthesis like Java, but other functions don't? Why the inconsistency?

>>105571285
Sorry but I work in the area and I don't believe you're fully informed. I don't want to spoil the atmosphere of this nice thread so I'll just say I disagree with almost everything written here and leave it there.

>>105571285
>numerically serious problems don't exist
this is a completely insane take, numerical problems only ever grow to match our compute power, we always have them

>>105566765
>>105571385
>Str List Str List Str List List List List List List List Num List Stdout
That's just from two small functions, that'll become annoying very quickly. Do you really have to keep repeatedly specifying the types of every function call like that?

>>105569341
>goblins
That's a really interesting project, making an entire networking layer is crazy!
I really like their implementation of an object system as just closures with recursion as assignment.

>>105571528
Not on the CPU, and not to a normal person. Unless you're working commercially or scientifically you're not going to encounter anything you can't brute force through in a few minutes.

>>105571403
I disagree with your disagreement.

>>105571285
>If you're not doing GPU acceleration you're a fool
>Basically serious work on the CPU is a relic of a bygone time
>>105571609
>Not on the CPU, and not to a normal person

>Idiot thinks that embedded devices don't exist
>Idiot thinks that everything has an Nvidia GPU
Not everything has a dedicated GPU. Sometimes all you have is a CPU that must maintain strict timing constraints in a hard real-time system. No, you can't "brute force through in a few minutes" when the entire system will fail if you don't respond within a few hundred microseconds.

Not every system works like a consumer desktop.

>>105571609
>Unless you're working commercially or scientifically
I am. I find it weird you went straight to graphics talk when the original post mentioned "differential equations" and "numerical work."
Alright, I'll clarify.
>Realistically numerically serious problems don't exist.
is wrong for the reason >>105571528 gave. If you're tinkering then fine, use whatever you want. If you're not, C++ is the industry standard. Anything in Python is probably ML and will certainly be calling C libraries. You're absolutely not getting away with writing Elixir.
>GPU acceleration
is done in CUDA C++.
>serious work on the CPU
was not mentioned by me, at least, and also wasn't even the original question, so just isn't really relevant here. The Elixir person mentioned their CPU was fast enough they could get away with not caring. That's fine for hobbies, but not for serious work. This comment is a complete tangent to the actual topic.
As for these optimised systems you're mentioning, how do these get made? People have to actually write them. It's not magic, it's a job. When you do that, you do that in C or C++. Those are still in active development too. It's niche work, but it is absolutely a serious problem. If he's asking about work in differential equations, then most of what we simulate those for is actually for heavy duty serious work, not toy projects, because they're of much wider use than just games and shaders.
If he were also doing anything nonlinear, then that's such a broad category he may find he needs to write his own implementation, since it won't be as easy as "discretise + LAPACK call" - he'll need to implement a method specific to that problem. Code is still written in C or C++ for this, Fortran is still used a bit, Rust is growing. I don't know what you're talking saying they're bad choices. They're nearly the only choices anyone uses for the job.
In any of these cases, Lisp is an unserious tool, unless you're making a tool to work with those libraries.

>>105571678
>>105571731
See the thing is you're lost in the sauce here.
Does it matter what some OTHER existing program is written in? No it doesn't. Are YOU PERSONALLY the one programming the database you're using? No you're not.
You idiots are saying things like "real programmers only use gate level logic, all you assembly users aren't serious since we all know when the chips are down only HARD SILICON really computes anything!"

Also learn to read
>for non commercial/scientific purposes performance simply doesn't matter
>b-b-b-but commercially and scientifically
Yeah, you're not doing that.
>b-b-but I am!
No, you're not. You're using the already implemented high performance software/libraries other people have made for you. Driving a car does not make you an automotive engineer.

If, by some chance, you're literally the original developer/maintainer of a high performance bare metal embedded ICBM missile guidance system for nuclear launch interception then questions of "can I use lisp for this" are asinine since even C code is subject to suspicion and careful manual review of generated assembly.

>>105571731
>In any of these cases, Lisp is an unserious tool
NTA, but Lisp is only an "unserious tool" because functional programming purists refuse to give up dynamic typing and garbage collection. It could easily compete with C++ in performance if it had static typing with manual memory management and the code was written in an imperative style with direct mutation.

The only reason why Lisp doesn't compete is because we're too attached to dynamic functional programming. It's useful and convenient, but it's just not how the hardware works.

>>105571860
>but it's just not how the hardware works.
...neither is static tying...

>>105571850
I'm trying to keep this relatively respectful, so you should calm down. You're getting way too invested in something which isn't your field. No offense, but it's very obvious.
>Yeah, you're not doing that.
>b-b-but I am!
No, you're not. You're using the already implemented high performance software/libraries other people have made for you
No, I mean this the way I said it. I literally am a contributor to a library which is used for these projects. It was my research topic and I am an author of one of these HPC libraries which are being used here. I know exactly how they're coded, and I wrote them in C.
If he is doing differential equations, it's really simple. Are you tinkering with it, or are you using it for a real purpose?
Then it's back to as I said earlier. If you're tinkering, go for whatever your heart desires. If he's doing this for a real purpose, which is what differential equations are commonly used for, then you'll need to use a serious language for it. You pick the right tool for the job.
It does nobody any good to tell them they can use any tool at all for anything because others have written stuff so it doesn't matter what you do. Presumably he asks wanting to learn why it is or why it isn't a good choice, so the question should be answered in good faith rather than saying "well it doesn't matter because you can use numpy which uses C for you," because then the poster gets only the illusion of an answer to his question and doesn't learn why C is the better tool for the job.

>>105571880
The hardware operations are typed. The data is untyped. The point is that static typing allows the compiler to statically determine exactly which typed operations to use, while dynamic typing does not.
Dynamic typing exists in fairy tale land where one single function could accept different types.
That's not how the hardware works, that single function has to be compiled into multiple separate functions for each type that was used with it. Some of those separate functions do nothing but crash at runtime with a type error.

Just look at how JIT compilers work. It often has to convert a dynamically typed function into multiple statically typed versions because the machine code works with typed operations.

Is there any cool lang able to use Python libraries? for numpy shit.

>>105571947
First of all read the end of the post before replying, I addressed your situation already.
Second, differential equations aren't a serious thing, I mentioned hobby software rendering because that often actually involve a lot of differential equations.
Third, for almost anyone working on a problem, they can't accurately estimate the true required performance without testing. It's probably much faster and simpler to just implement your problem in a high level language like lisp and try running it than it is to analyze the problem to determine it's running time. The only exceptions are when you know you have extremely limited execution windows, or extremely large data volumes that you know will be difficult for any computer to handle no matter the language used.

So basically if it's a legitimate question by someone about programming, they're probably better off just using lisp since nothing they're working on is likely to need more. And if it's a highly technical issue of real time embedded processing or mass supercomputer processing they should know enough to answer the question themselves.

>>105571860
Well yeah but that's also the strength of Lisp, that you can abstract away all that, and then you've got a nice language which gives you a bunch of stuff you'd never get with C++. I don't think Lisp really has to try to compete in that area since it already does what it does so well (and let's be honest, C++ is an ugly thing).

>>105572049
https://gambitscheme.org/
The website says it can compile to Python.

>>105572021
And you trade massive amounts of boilerplate and complexity for the cost of a single indirection per function call.

>>105572067
I'd add that even if it turns out you can't run your program in lisp it's not a waste of time at all to implement it in lisp anyway. It's simpler and easier to use, so you get a working result much faster that you can now directly translate into a lower level language, and it also encourages you to apply all the high level optimizations easily done from lisp before attempting any lower level fiddling. The lisp implementation and testing should give you everything you need to know about exactly how you're going to structure the program and is MUCH faster to iterate. In terms of developer time, lisp a far more optimized and high performance, so you're wasting a lot of your time if you start out in a low level language.

>>105572067
>Second, differential equations aren't a serious thing
This is just not true. I don't know who told you this. We have many physical systems which require serious thought because of issues like nonlinearity, etc. As for raw speed, this usually translates to a linear algebra problem in the end. You can see that linear algebra libraries are actually a surprisingly active field nowadays, if niche.
I conditionally agree with the third point in that Python is a good way to quickly test, but typically nowadays your latter condition does in fact apply. Nowadays we do have huge data volumes quite frequently.
I agree that this is a question someone *should* know, but not everyone will know it so I prefer to give a proper answer, and in that case the answer still reduces to "how serious are you?" and if so, here are the serious tools. But the third option is also quite frequently that someone asks because they're a mathematician, physicist, chemist, biologist, what have you, by training and get into programming later, and then they have to start somewhere. Many of these people ask questions like that because they don't understand why at some point they'll get told Python isn't a good tool here, for example, and Matlab isn't available and they just don't know any better. It happens, everyone starts somewhere. Many CS people even don't know much about numerical work.

>>105572073
>Well yeah but that's also the strength of Lisp
The strength of Lisp is in the simplicity of syntax, relative of most other languages. It makes macros possible, and incredibly easy to use.
Notice that if you replace the s-expr syntax with something more complex, all you'll have left is a worse version of some other language, the rest of the features become mediocre. The dynamic typing and GC are not what makes it good. Lisp is good because the uniform syntax allows it to be easily extended to solve whatever problem you have.

Read this: https://web.archive.org/web/20250531155348/http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html

>that you can abstract away all that
Unfortunately, that tower of abstraction results in slow code. It's convenient, but you'll never get anything remotely considered efficient if you're unwilling to give up some of those abstractions. As mentioned above, the tower of abstractions isn't what makes Lisp good, it's the syntax.

>>105572088
>a single indirection per function call
No, the cost is much deeper than just a single indirection. Dynamic typing also don't give enough information for the compiler to properly optimize the code, and you need a bunch of type checks at runtime with all the information needed to perform them. All that extra space used for type checks and information also makes poor usage of the CPU caches.

You literally cannot generate efficient machine code from dynamically typed source code.

>>105572158
I mean differential equations aren't some super complicated hard thing only used by experts. They're used all the time in hobby projects.
As for everyone else I say it's way faster to just get someone to learn and use lisp than it is to try to force them prematurely into C++. If they're graduating off python or something it's already a huge performance boost, and CL even has access to the same numerical processing libraries as numpy through numcl. Then you've got scheme and it's simple C interoperation, there's really no need to avoid lisp. It's quick and easy to learn, high enough performance for 99% of tasks, and has lots of support for using low level libraries.

>>105572088
>massive amounts of boilerplate and complexity
Adding type symbols to function signatures is considered "massive amounts of boilerplate" now? Type inference can remove 99% of those, except on the function signature where types are actually important.

>>105572212
And you can't dynamically redefine code in statically compiled languages. Which is much more important and useful to most people.
Also this is a false dichotomy, lisp supports dynamic AND static typing through compiler hinting!

>>105572251
What type is "if"?
How about apply? What's the type signature of eval?

>>105572242
It is faster to do that, yes. I don't like C++ as a language but it is what it is.
The rest I somewhat agree with: if it's a hobby project, go for anything, but with regards to optimisations, the issue is the low-level optimisation is what gives you something like 10-20x the performance. So those optimisations don't do that much in practice. But if it's a hobby, no problem, and anything goes.

>>105572285
And high level optimization is what gives you 1000-1000000x the performance. No amount of C++ or manual assembly is going to save you from exponential algorithms or synchronous disk access.

>>105572257
>dynamically redefine code
>important and useful to most people
For hobby code, sure. You won't be dynamically redefining code on an actual production server. That's an easy way of getting fired from your job the very next day.
The entire software industry has agreed that self-modifying code at runtime isn't a good idea, we even enforce that at the hardware-level with W^X protection, but somehow lispers are still stuck in 50s software conventions where self-modifying code was the norm.

Code generation and macros at compile-time is useful, it's the best feature Lisp has, easy and simple macros. Runtime self-modifying code is not, it's perhaps the worst feature some implementations of Lisp still support.

>>105572268
>He doesn't know what parametric polymorphism is
Not every statically typed language works like C. Those examples could easily use compile-time generics to keep the same semantics and usage in code.

>>105527756 (OP)
>org-forward-sentence
>org-backward-sentence
god those functions should be general functions innit

>>105572257
>dynamically redefine code [...] is much more important and useful to most people
Seriously, who actually uses this in production? No other language does that. Not because they can't implement it, but because it's a massive security problem. So who are these people who think it's important and useful for a language to have a built in arbitrary code execution vulnerability?

>>105572327
You're wrong, opinion discarded.

>>105572312
This isn't true. The DSA stuff isn't the main obstacle in practice. Nobody is realistically going to come up with e.g. an exponential time matrix multiplication algorithm. They're just going to optimise memory access patterns in the cubic algorithm.

>>105572445
>I love when my Lisp implementation has a built-in arbitrary code execution vulnerability as a feature
He's right, and you're an imbecile. Nobody else does it because it's a security problem.

>>105572268
>What's the type signature of eval?
Either a string of Lisp code or a pointer to a runtime representation of a list with Lisp code?
Just embed a Lisp interpreter into any program that uses eval just like you would with Lua embedded into a C program.

>>105572444
>>105572483
>lisp dynamic nature is le bad
>but le heckin hot reloading feature of my favorite industry standard™ ꜱoylang is le good

>>105572483
Live patching is done on Erlang telephone shitboxes to have no downtime.

>>105572756
>Comparing hot reloading (on a dev machine) with being able to arbitrarily redefine functions on a running program
>>105572791
>Comparing live patching (of likely signed code) with being able to arbitrarily redefine functions on a running program
The difference is that once hot reloading or live patching is done the code cannot arbitrarily modify itself further at runtime, the change is done and that's it. You're replacing a block of static code with another block of static code. That change can be verified and the code can be signed to prevent unwanted modification.
What certain Lisp implementations allow is a security problem because the code can arbitrarily modify itself at runtime, at any time. It's equivalent to an assembly program constantly changing some machine code somewhere, sometimes based on user input, and then jumping to it. It should be obvious why that's a problem.

This is like cniles in denial of their language's memory safety issues. Lispers are in denial of the problems caused by some of the language's dynamic features.

>>105573111
>It's equivalent to an assembly program constantly changing some machine code somewhere, sometimes based on user input, and then jumping to it. It should be obvious why that's a problem.
Fun fact, I'm pretty sure some really old computers allowed you to stop the program counter at any time, step through instructions, and mess with its registers. It would make sense, as if you can only program it with machine code, that's the only way it would be enjoyable to program it. I can't remember the of it, though, only that I read it somewhere, so take it with a grain of salt.

>>105573111
That's not a problem though, that's the entire point.
I could just as well say static code is useless trash because it CAN'T be redefined at runtime by self mutation. It's crippled and poorly performing, not even worth being called a language. Imagine an interpreter that can't even interpret code!

>>105572454
No, but they're going to be running matrix multipilcations that are entirely useless and can be removed. So many algorithms can, with additional thought, be reformulated into entirely different much simpler problems. I'm not talking loop unrolling here, I mean finding out the entire linear algebra simulation you're running has a classical solution and can be solved in a single step, or that the propagating error in a calculation you're doing is so large the result is effectively random and can be omitted or replaced with procedural noise. Or you find out that you didin't actually need so much data and can get away with drastically reducing the number of steps and precision for an equivalent result. Or maybe you don't like the kinds of results you're getting and decide to use an entirely different type of optimization. Or maybe you detect a small arithmetic error that would render the results of an entire six hour long calculation garbage. All of those things are much easier and quicker in lisp than C.
If you're going to optimize at all it should be when you've exhausted every other option possible and have fully committed to a single definite implementation you know will work for you.

>>105573508
Someone is almost never numerically solving for something with an analytical solution. If the equation is known then this will be easily checked by looking it up. This is probably getting away from the point.

>>105573212
>some really old computers allowed you to stop the program counter at any time
I was done with self-modifying code. You could build a tiny hex editor prompt that writes any machine code you want into any memory address, and then jumps to it when you pressed enter. It's possible to bootstrap a Forth in less than a day, with just the editor in a floppy disk's boot sector. It was very useful back then, before security was a concern.
Older processors didn't have write xor execute (W^X) memory protection. You could write arbitrary machine code into any arbitrary physical address and jump directly to it. That led to a bunch of self-modifying malware, which is why we now have W^X protection to prevent unwanted modification of machine code at runtime.

It was great while it lasted, but then all the malware ruined the fun of self-modifying code.

>>105573414
>The imbecile thinks that having built-in arbitrary code execution vulnerabilities is the entire point of Lisp
You're worse than a brain damaged cnile refusing to acknowledge all the buffer overflow vulnerabilities. This is one of Lisp's worse features by far, it's an obvious security problem and it's not what makes Lisp great.
What makes Lisp great is the uniform syntax that enables easy macros and simple (compile time) code generation to freely extend the language. This is something that *only* Lisp has, no other language has macros that are as easy and simple to use with such an elegant and uniform syntax.

That's the entire point of (why you'd use) Lisp, that's *THE* feature that cannot be replicated in another language. Every other feature can be replicated elsewhere, but this one cannot, because it depends on the syntax and semantics of Lisp.
If you think the dynamic features are what makes Lisp special, then you don't understand Lisp. You can remove most of the dynamic features and still have a Lisp (like pre-scheme does), but you can't remove macros or s-expressions and still have a proper Lisp.

>>105573414
>redefined at runtime by self mutation
>mutation
That doesn't sound very functional.

>>105573620
On the contrary I find people are constantly doing exactly that. It's a very common mistake to immediately bust out all the computation before actually thinking whether you need to compute anything at all. This happens across all forms of programming and is a self perpetuating problem.
A disturbingly large amount of times someone asks "how do I do x?" the correct answer is "don't."
Though lots of times this gets overblown and people just refuse to answer questions by assuming they know the context.

Really this entire argument would be solved by specifying a context for questions.

>>105573958
>he thinks lisp is sexps

>>105574074
lisp isn't functional

Does anyone know how to set up token and selection highlighting?
I'm trying to basically have:
>if a region is highlighted, also highlight instances of the ws-stripped text in the region
>otherwise, if the cursor is just chilling, highlight instances of the token

I tried doing this with these two packages and some really shitty elisp:
https://github.com/wolray/symbol-overlay/tree/master
https://github.com/nschum/highlight-symbol.el/blob/master/highlight-symbol.el

However symbol overlay has a monstrous fucking default color scheme, and I couldn't for the life of me override those with custom faces, and any time I slightly changed the selection, it would cycle through these clown vomit colors

>>105573817
What I was thinking of is how some old computers had toggle switches that let you enter machine code instructions with lights for viewing register values and buttons to halt the machine and step through instructions, and view or change memory contents. Apparently the PDP-8 (1965) had it, but later microcomputers didn't.

>>105574074
>That doesn't sound very functional.
What if it's opportunistic mutation

>>105574186
>lisp isn't functional
>the first programming language with lambdas isn’t functional
Functional ≠ purely functional. Learn the difference.

>>105554335
>https://github.com/edicl/cl-who
Pretty nice.

So I was posting on /hsg/ regarding installation of Frigate, which seems to require Docker, but an anon is installing with LXC...
>>105576934
>>105577001
>>105577048
Then I came over this after a quick search:
https://github.com/blakeblackshear/frigate/discussions/5448

So... Is there maybe an easy way to convert Docker images to Guix containers?

>>105571385
>>105571550
I'm like 5 hours into the language itself so here's what I discovered
- f x y is implied as f(x,y) both forms are valid though the formatter flag must be supplied in order to convert to explicit brackets
- Str/List are namespace for standard library calls (see Elixir), additionally they are also literal types, the Result type is described as something that can be [Ok(v), Err(v)] much like Rust
- The namespace is determined by filename on import, e.g. if you want Util.fold you would create Util.roc (capitalised) and export the fold function
- White spaces matter which kind of sucks

Here's code from day 2 aoc 2024 that I did - with more strict formatter (roc format --migrate)

>>105571550
Forgot to mention you can use explicit import if you want to ignore the namespace
import Str exposing [split_on]

>>105569935
>design decision
This is great and all but as far as I can tell there's no way to iterate over the code points or graphemes at all
>alpha this year
>breaking changes
Sounds great, looks like I hopped on at a good time

So far the only thing I'll be using this for is cpu-intensive scripting

>>105570837
>in-port
>automatically tokenises and type convert
man racket has so many tools that idk wtf to even use

>>105571731
>You're absolutely not getting away with writing Elixir.
i fucking love elixir and it saddens me that the performance is not there. writing it is such a joy, the ecosystem and tooling is insane. phoenix is a gem. the restriction on raw performance and limitations on cross compatibility is what prevents me from doing absolutely everything in it.

>>105577345
There's the guix import command, but unfortunately I don't think it can import dockerfiles yet. Probably the easiest way for you would be to use this:
https://guix.gnu.org/manual/devel/en/html_node/Miscellaneous-Services.html#index-oci_002dcontainer_002dservice_002dtype

>>105577474
if you are willing to dig in deep to a project, then I believe that there would be great success in patching the BEAM to support a sub-language with linear or affine types (to avoid garbage collection) and mutable data structures (with static types to avoid boxing) that could be used for fast performance. or just use NIFs with Rustler/Rust or C if you want to be masochistic. make sure that, if you use NIFs, you use the dirty variants if you cannot abide by the BEAM's strict timing constraints.

>>105576843
I've been using spinneret mostly because it was already chosen when I joined the project I'm working on now. I think the new kid on the block is hsx which is less than a year old. That's rare for a CL lib these days.

Am I an idiot or are a lot of lisp tutorials really fucking bad? I'm trying to learn lisp because it's different and interesting at a glance but I literally can't understand anything from youtube vids and stuff. It's always buzzwords/buzzphrases like code is data, symbols vs evaluated code, macros, etc. with ZERO real world explanations on how this matters or what the purpose is.
>look, you can store (+ 1 1) as 2, or store it entirely as (+ 1 1)! Cool right?
NOT COOL! what the fuxk is a real world example? are there any sane videos or anything that can actually teach me properly? I feel like a middle aged mom listening to her son rant about rimworld or some autismo time sink pc game any time anyone talks about lisp

>>105579494
>Am I an idiot or are a lot of lisp tutorials really fucking bad?
You're not an idiot, you're right. Especially CL tutorials are the fucking worst because the authors are so busy jerking off to how great they think the language is rather than trying to teach you how to use it.

>>105579494
Read a book. There are several decent ones, two are in the OP for Common Lisp. People doing video tutorials are grifters and/or mostly getting a high off the idea of explaining some insight to their past selves as if they could have gotten the insight faster if they heard the explanation from their future self.

>>105579494
>>105579515
However to be constructive I will say that if you know another language already, Lisp shouldn't be that difficult to pick up. It looks esoteric at first, but once you get over the initial "wtf is going on with these parentheses" you will find that lisps tend to be rather simple.
Once you get a hang of the very basics you can already get started building stuff.

>>105579494
>youtube vids
they're horrible learning tools full stop

>>105579494
I've managed to pick up a few useful tips from this guy.
https://www.youtube.com/@the-lisper/videos

new bread
>>105581689
>>105581689
>>105581689
>>105581689