Happy Thursday!

Thursday is the day where I look back upon the week and consider what I've learned. Last week I completed the main Buddhabrot algorithm and got it to work.

Studying: The Little Schemer

This week was primarily studying, so there's not a lot of code to consider. Instead, I worked my way through The Little Schemer, a book that teaches how to write Scheme and, by doing so, master the Y Combinator (the mathematical formula, not the orange site people), and eventually meta-circular interpretation. The latter wasn't as interesting to me as I'd hoped, as I'd already done it once, writing a meta-circular interpreter on top of a Lisp I'd already written which, in turn, was written in Coffeescript, because that's how I was rolling back then.

It's a rite of passage to finish The Structure and Interpretation of Computer Programs and then write your own programming language in it. I'm up to section 3.3 and am currently a little stuck on the "write your own deque" section. One thing I dislike intensely about MIT Scheme (and Schemes in general) is the way objects and pointers just exist, willy-nilly, and knowing when you're using the original handle and when you're using a reference is all a matter of keeping it in your head. I think I'm becoming more of a Rust partisan every day.

Speaking of Rust, I started an implementation of Brzozowski's Algorithm in Rust. It's a very naive sort of thing, based on my earlier attempt with Python. It doesn't work yet and, according to Might it will probably have terrible performance and memory issues, but it's a first draft. I may have to figure out how do memoization and some macro handling / inlining. The first time I wrote it, I realized where the memoization would have to occur to make it performant, but that knowledge seems to have faded from my brain and I'll have to re-learn it all over.

Plans: Next Week

Next week, fate willing, I'm going to:

  * Implement colorized versions of the Mandelbrot and Buddhabrot implementations.
  * Read three chapters of _The Seasoned Schemer_
  * Finish chapter three of _Structure and Interpretation of Computer Programs_
  * Write some damn documentation for the [images.rs](https://docs.rs/image/0.19.0/image/) library.

Future Plans

There are a number of other, unfinished projects on my plate. Most notably, I haven't finished porting Daniel Givney's Assembly Tutorials to 64-bit ASM, as promised.

And then I'm going to dive into writing an interpreter, a virtual machine, and a compiler. All the stuff I never learned how to do because my parents didn't believe, in 1985, that a programming career would ever be lucrative and would only pay my college if I majored in Accounting– excuse me, I meant "Business Computing"– instead. My ideas for it are incredibly vague, but there are some basic ideas.

Excessively Ambitious:

  * It is going to be a Scheme.
  * It is going to be strongly typed.
  * It is _not_ going to be beholden to the naming history of Lisp or Scheme. My first thought was be to steal from [Hy](https://github.com/hylang/hy), using [Ghostwheel](https://github.com/gnl/ghostwheel) or [Compact Notations](https://docs.racket-lang.org/compact-annotations/index.html) as inspiration for typing annotations.
  * It will use type inference wherever possible.
  * It will use a sane import scheme.
  * It will rest upon an Intermediate Representation that will not be married to the syntax. Alternative syntaxes should be easy.
  * I want it to have the following:
  * Garbage Collection: A tri-color parallel garbage collector.
  * Green threads implementation, like Go routines.
  * [Batteries included](http://www.network-theory.co.uk/docs/pytut/BatteriesIncluded.html)
  * [Computation Expressions](https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions)
  * Fat executables (all files and libraries included in a single, runnable format)
  * It would be silly for me to want:

    * Software-transactional memory
    * Type Providers




  * It would be madness to provide domain-specific stuff like:

    * A [Grammar interface](https://docs.perl6.org/language/grammars)
    * A type-driven graph engine (the underlying technology of spreadsheets)
    * A type-driven pluggable buffer engine (the underlying technology of databases)
    * A high-performance [rope](https://www.geeksforgeeks.org/ropes-data-structure-fast-string-concatenation/) or [piece table](https://en.wikipedia.org/wiki/Piece_table) implementation (the underlying technology of text processors)
    * A document object model ([the DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction) is an obvious one, but what about [OpenDocument](https://en.wikipedia.org/wiki/OpenDocument)?)

For all I know, there is a strong conflict among these different goals, in that, for example, grammars might be incompatible with strong typing, or at least difficult to implement correctly. This is a learning experiment.

And here's the thing: I don't just want to write a programming language. I want to write useful things in my programming language. That's the whole point. If I can't write useful things in it, then it's not a useful language. Yes, there are days when I feel like this plan goes over Programming Language for Old Timers, but that's also the point; I know enough to feel modern, but I want something that is expressive to me.