Why is Scheme\Racket so slow?

You and the Sussman go on and on about how powerful and expressive it is, but the only expression I'm making is that of exasperation as I wait a full thirty fucking seconds for this piece of shit language to draw a single 1000*1000 monochrome image onto the screen.

#lang racket
;; 5/2/2015
(require graphics)
(open-graphics)
(define vert 1000) (define horiz 1000) (define rule 30) (define viewport (open-viewport "LOL" horiz vert))
(define (auto seed row)
(if (> row vert) #t
(and ((lambda (src yv)
(let ([draw-pixel (lambda (x y) ((draw-pixel viewport) (make-posn x y)))]
[c (lambda (fun l x) (fun fun l x))])
(c (lambda (fun l x)
(if (empty? l) #t (and (if (= 1 (car l)) (draw-pixel x yv) 0) (fun fun (cdr l) (+ x 1)) ))) src 0))) seed row)
(auto ((lambda (old)
(let ([gen (lambda (x y z) (let ([a (if (= x 0) 0 4)] [b (if (= y 0) 0 2)] [c (if (= z 0) 0 1)])
(if (bitwise-bit-set? rule (bitwise-ior a b c)) 1 0)))]
[r (lambda (m) (if (null? m) '() (append (cdr m) (cons (car m) '()))))])
(map gen old (r old) (r (r old))))) seed) (+ row 1)))))

(auto ((lambda (width pixels)
(let ([c (lambda (fun init end) (fun fun init end))])
(c (lambda (fun init end)
(if (= init end) '() (cons (if (memq init pixels) 1 0) (fun fun (+ init 1) end)))) 0 width))) horiz (cons (/ horiz 2) '())) 0)

(close-viewport viewport)
(close-graphics)

>>1
Clojure is not a LISP.

It's a matter of trade-off.
Abstraction comes at the expense of efficiency.
The day there is a very high level language (like Scheme and Haskell) that is as efficient as C, then it's time to take them seriously.
But currently the trade-off isn't worth it.

#lang racket/gui

(define size (* 8 100))

(define initial (append (make-list (quotient size 2) #f)
(list #t)
(make-list (- size (quotient size 2) 1) #f)))

(define (rule x y z)
(or (and x (not y) (not z))
(and (not x) y z)
(and (not x) y (not z))
(and (not x) (not y) z)))

(define (step left l)
(if (null? l)
'()
(let ((right (if (null? (cdr l)) #f (cadr l))))
(cons (rule left (car l) right)
(step (car l) (cdr l))))))

(define (to-byte . bits)
(foldr (lambda (x ys) (+ x (* 2 ys))) 0 (map (lambda (bit) (if bit 1 0)) bits)))
(define (to-bytes l tail)
(if (null? l)
tail
(cons (to-byte (car l) (cadr l) (caddr l) (cadddr l)
(cadddr (cdr l)) (cadddr (cddr l)) (cadddr (cdddr l)) (cadddr (cddddr l)))
(to-bytes (cddddr (cddddr l)) tail))))

(define (live initial i)
(if (= i size)
'()
(to-bytes initial (live (step #f initial) (+ i 1)))))

(make-monochrome-bitmap size size (list->bytes (live initial 0)))

Racket is shit. Check out stalin if you want a higher performance scheme. Check out sbcl if you want a high performance lisp.

>>3

Abstraction comes at the expense of efficiency.

No, it really doesn't. If you can provide enough guidance to the compiler, it will maintain efficiency despite the abstraction.

It's all due to the garbage they filled R7RS with. Programs were blazing fast in the days of R4RS. Now they've added tonnes of shit to ensure cache misses and page faults and garbage collection pauses until it's a miracle if it even works at all.

cache misses and page faults and garbage collection pauses

how to sound like you're an expert when you actually have no idea what you're talking about

>>8
I didn't want to confuse like yourself by going into the homomorphic endotensor closure issues that the new specs caused and why it is ultimately harmful. Instead, I just listed the symptoms that laymen not acquainted with the catagorical theoretical underpennings of the LISP would be able to measure. After all, must one really explain to a small child why zero cannot divide anything? Of course not. A simple mind only needs to know to avoid it, and maybe, if they are smart enough, there will come a day when a full explanation can be given.

But I fear that that day is not today.

>>1,3

define define define define define define define define define

Just use def you faggots. 6 letters is way too long for such a common reserved word.

Also lam instead of lambda.

Just use this:

(define-syntax def
(syntax-rules ()
((def a ...)
(define a ...))))

(define-syntax lam
(syntax-rules ()
((lam a ...)
(lambda a ...))))

>>10
>>11
only folk of a very shallow superficial level of intelligence would consider mutilating words by slicing them in half a benefit.

Those who would give up essential Clarity, to purchase a little temporary Terseness, deserve neither Clarity nor Terseness

>>12-12,12
only folk of a very shallow superficial level of intelligence would consider mutilating quotes by slicing them in half a benefit.

λ or gtfo

>>14
ASCII or GTFO.

I'd say that isn't to bad when you consider you are doing it in perhaps the least efficient way possible by generating three thousand lists and traversing three million elements, then drawing them one by one with a refresh between each.

did you try my version of your program OP?

>>3
Check out the Ur/Web benchmarks in https://www.techempower.com/benchmarks/
C++/ulib is the fastest overall, but you get to see serious high-level competitors.

>>17
I did. It made me quite angry. Firstly because I did not see that functionality when I was glancing over the documentation, and had to use graphics instead. Secondly, you are defining functions too much, and not using lambda and let enough. This is Scheme, and that is the defining feature. Use it more. I also dislike your usage of abominations like cddr. I oppose those on the personal obligation that they are ugly and gross, so I will not hold it against you. I also take issue with your method of deciding a value. The rule cannot easily be changed in your version, and the program is at the mercy of a cryptic series of boolean algebra. Also, I find the ease of which you avoid [] to be gaulling. It is clear that you did not suffer through the laggy, annoying, unpredictable DrRacket to compose your program that forces such things on you, and I resent that you took the easy way out. Additionally, I find the idea that consorting with byte arrays in the LISt Processor to be dangerous heresy. Finally, I do not think, and shudder at the thought, that >>4 is any version or derivative work of mine. It would take hours to rework >>1 into what you have presented; I know this because I spent almost an hour collapsing everything into such annoyingly recursive statements myself. I suspect that you merely started anew and wrote a program that achieved a similar output. I do not like the fact that you are now trying to ride my coat tails, so to speak, by speaking with such familiarity.

That said, >>4 is a well done program, if a harsh indictment to the harsh indictment I was giving Racket in >>1.

(cons (to-byte (car l) (cadr l) (caddr l) (cadddr l)
(cadddr (cdr l)) (cadddr (cddr l)) (cadddr (cdddr l)) (cadddr (cddddr l)))
(to-bytes (cddddr (cddddr l)) tail))))
This is almost like a catchy rap song