11:32 <polarian> interesting... also the heap has more overhead at least in C, the stack has a set size (which is also why it overflows if you recurse too much, which is why I assume racket/scheme uses the heap, seen as the languge(s) are built around recursion), but this set size also means no allocating or freeing of memory is needed which does take time. With the heap it must find a free block of allocated memory, and chop that up, otherwise ask the kernel for more

11:32 <polarian> memory, and then there is reclaiming this and returning it to the kernel, while stack? it just pops the frame once out of scope. Unless I'm missing something stack is far more performant, but it has limitations of course.

11:33 <polarian> and a lot of languages tend to be better than bad C

11:33 <polarian> C you don't just simply pick up the language, you must understand the ins and outs of everything... optimisation? that's mostly up to you

11:35 <polarian> I remember discussing it with a Java software developer, its far easier to write performant Java code which the JIT compiler can calculate hotspots and optimise them further, than pick up C and instantly expect it to perform better.

11:36 <polarian> Racket also has a AOT compiler... so I assume you can get decent performance if you were to use racket in a production codebase?

13:08 <polarian> also, vectors are still iterated, or is that also recursive under the hood?

13:21 <bremner> polarian: "under the hood" it is machine language. The implementation of loop (e.g. the for macro) in racket is (probably) tail recursion, but that doesn't really make an important difference; it is still iteration from a user and performance point of view.

13:24 <polarian> I assume its highly optimised though, right?

13:24 <bremner> yes, you might look up "tail call optimization"; it turns tail recursion into goto

13:26 <polarian> oh so its not "true" recursion then, it follows the structure of recursion but it hops instructions like in iteration...

13:26 <polarian> so on a programming level it is recursion, but its then optimised out to act like iteration?

13:27 <bremner> right, that's what tail-call-optimization is

13:27 <bremner> scheme and racket guarantee that particular optimization, which means that tail-recursion is safe to use, performance wise

13:27 <polarian> thats cool...

13:28 <polarian> so racket traversals and path finding must be much more convinient

13:28 <polarian> and performant than the C counterpart

13:28 <bremner> note that "tail-recursion" is not all recursion. It's a special kind of recursion.

13:29 <bremner> https://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html#%28part._tail-recursion%29

21:20 <shawnw> I think one of the important things to really getting Scheme (And Racket) is realizing that there's no fundamental difference between iteration and recursion (Especially tail recursion). They're just two sides of the same coin.

21:58 <bremner> well. I think there is a big difference between tail recursion and general recursion as far as performance.

21:59 <polarian> so in other words, don't go out of your way to use for, because unless it is more practical in the situation, it should perform similarly to recursive?

21:59 <polarian> aka use whatever is syntaxically easily?

21:59 <polarian> easier*

21:59 <polarian> for the situation?

22:01 <bremner> you should use for in racket because it makes the code easier to read, and because it guarantees tail recursion. the for macro in racket is just a wrapper for tail recursion.

22:02 <polarian> so overall, vectors are still faster, for is still worth using over recursion (unless its a recursive algorithm)

22:03 <bremner> vectors are clearly faster _for random access_. For other things, I'd need to benchmark to know if it is significant

22:03 <bremner> vectors vs recursion isn't really a comparison that makes sense to me

22:17 <polarian> vectors vs lists is the argument here

22:17 <polarian> if iterating each is negligable in difference... why use a vector?

22:18 <polarian> I have been told by a few people who write racket code that "racket is orientated around lists, you use lists for everything"

23:23 <shawnw> Lots of things don't involve doing something with every element of a data structure, just specific ones. Or need fast random access to preform well.