yes! that's the plan. the hope is that these will turn out to be things that _should_ be emacs commands :D

You can have a readmacro that you can bind to a key on emacs or whatever editor to be able to change S-expressinos to postfix and back again. Postfix is nice if you see the stack so you can see the intermediate values, but LISP is better for reading. Also you can use Chinese symbols and put the words in a tiny ruby script and maybe change the ruby script to give you sample test values seeing how they move through your code.

I used to hate R when I first used it back in 2007, but having used it as my primary language at work for the last 3 years, it's become (as you say) actually pretty good. It's not quite my favourite language (that's Julia), but it gets stuff done and makes it easy to do. Plus once you get the hang of FP, your programs start looking really nice! I don't do any linear modelling, my work is all non-linear modelling, stochastic simulation, and making quality plots :)

the videos are intended for a wide audience, but I personally have a pure math background lol

They were developed as two different ways to mathematically study what was possible on a machine (though Church was Turing's thesis adviser). After some time, they were shown to be _equivalent_ in the sense that each model could be used to implement the other one. It's sort of like how Python and Java are two different programming languages, but you can implement a python interpreter in Java, and a Java compiler in Python.

If the return statement is a complete description of everything that happens in a function call (no mutability or global state), then certain optimizations are guaranteed to be safe, like - Caching - Parallel calls what's important is that in the functional world, it doesn't matter _how_ the function is implemented, as long as the mapping of inputs to outputs stays the same. you can't get this in the mutable world, because of the way the specific implementation might interact with the outside world. it also makes the function easier to understand and test, because the API surface is smaller. i.e. you don't have to test the function for every possible context/state of the world, you only need to test the mapping of inputs -> outputs. I also answer this more specifically in part 2 of this video: kzbin.info/www/bejne/bHjKlGR4gLNrndk

"Caching" This constitutes mutating state. Also, at least for the things I work with, caching isn't going to help as the amount of memory needed for the hash map exceeds the available amount of RAM. After watching your second video, I am left with the conclusion that functional programming contradicts itself and is fundamentally impure. There is state somewhere, that state has to get mutated and all that functional programming accomplishes is moving around where the state is that gets mutated.

I'm wondering, what is the functional programming guidelines when you absolutely need to change the state of a variable? Where or how do you change it?

Unfortunately I don't think I saved the code for this one, but I'll try to put up github links in future videos. As far as mongodb, I think it's a good choice for quick development/smallscale applications because it's easy to set up, and it lets you dump JSON, which lines up well with how I represent objects in my application logic. If you want to scale up, you have to think more carefully about: - what type of information you're trying to represent - what types of operations need to be fast. (e.g. SQL is a much more mature language for aggregation and join operations) Often you'll want to pick a storage solution that's appropriate for the particular problem you're trying to solve. MongoDB is the first DB I learned to work with, and I think it was good for me, because I got to get up and running building my little project without thinking deeply about relational databases. I sort of learned the fundamentals of backend-development first, and then deep-dove into relational databases later. Hope this helps! :D