PurelyFunctional.tv Newsletter 299: Fullstack, ClojureScript, Class hierarchies
Issue 299 - November 05, 2018 · Archives · Subscribe
Hi Clojurists,
Please enjoy the issue!
Rock on!
PS Want to get this in your email? Subscribe!
Announcement: No Clojure SYNC in 2019
I'm sorry to say it, but it won't be happening in 2019. I'm deliberately leaving 2020 open. This post talks about why, and the future of Clojure SYNC.
Lessons learned from creating a rich-text editor with real-time collaboration
A nice write up on the challenges of synchronizing complex data between multiple distributed machines. I love that they came up with a rich model that worked for them. Instead of hacking at the problem, they modeled the editor document in a better way to support their features. It also shows how conflict resolution is primarily domain-dependent. Each type of data will need its own model of synching.
Create your own dysfunctional single-page app in five easy steps
Jim Newberry on some industry problems with single page applications. I have to say that I haven't experienced these where I've worked myself but I know people who have.
Haskell vs. Go vs. OCaml vs. ...
A post-mortem about reimplementing the same existing Python script with Haskell, Go, and OCaml.
Clojure is a product design tool.
Danny King talks about how he uses ClojureScript as a product designer.
What do functional programmers think of the class inheritance hierarchy? Podcast
I was classically trained as an OO programmer. After 17 years of functional programming, I look at the class inheritance hierarchy in a totally different way.
The Architecture of the Burroughs B-5000
Alan Kay has said that this was a really cool computer architecture designed to implement high-level languages. I wanted to understand more about it and this article was pretty good at explaining it. The perspective is from the 1980s, before the x86 architecture dominated as it does today.
What is Futhark?
It used to be that the easiest way to make your software faster was to wait 6 months and buy a new computer. Then clock speed increases slowed down. CPUs were getting multiple cores instead of faster execution. The idea was to run multiple instructions at the same time to make up for the lack of improvement.
Functional programming was going to give us back what we were losing. It would make parallel programming easier. We could once again wait 6 months and our software would be faster.
Ten years ago, we were all promised CPUs with thousands of cores. That didn't happen, and it may never happen. Instead, the cores moved into the GPUs.
The general-purpose languages we are used to were not designed to run on GPUs. The languages grew up on von Neumann architectures with sequential CPUs and RAM. Their memory models and execution semantics grew up in those assumptions. That means that most languages, including the highly-parallel function al languages like Erlang, Clojure, and Haskell, don't have much to contribute to programming the GPU.
I've wondered what a GPU-first FP language would look like. In theory, FP should still have a lot of constructs that would run well on GPU hardware. Futhark looks like a great example of that.
Understanding Re-frame update New features
I recently bumped the some dependency versions on the code for Understanding Re-frame. Though I generally try to make my code future-proof, I failed on this one. Java 1.9 dropped some libraries that Figwheel and other tools depended on. I'm still running Java 1.8 so I only knew about it from a helpful customer. I'm forever in their debt. If you had trouble running Figwheel on the code for Understanding Re-frame, give it a try again.
To make the upgrade possible without reworking the entire git tree, I switched from using git tags to using git branches. Tags are nice for naming certain commits, but they are a pain for anything that might change over time. Now each lesson has a branch so I can make upgrades if needed.
Please let me know if you have any trouble with this code or any other code on my site.
