blog

I came into Forth with 32 years of mixed experience from Lisp, Smalltalk, Haskell, C++, C, Java, Perl, Python, Clojure, Scala and more; it's difficult for me to judge anything from that perspective. I've never written a standard Forth program in my life though, never installed any other implementation. The second I was introduced to Forth, it clicked; Lisp took me much, much longer to get by comparison. Like I said, I'm not very much into rebuilding what has already been built better by someone else. Anyone who's written any amount of code is bound to have own ideas, and the nice thing about Forth as a substrate is that doesn't come with that many ideas of its own. I've written a few blog posts explaining design choices (https://github.com/andreas-gone-wild/blog/blob/master/forthy...), there's more interesting stuff to come now that the p

There is no need to use raw pthreads in modern C++, it comes equipped with a much more convenient and capable standard library module. I prefer working with channels, which are still missing from the library; but they are trivial to add: https://github.com/andreas-gone-wild/blog/blob/master/diy_cp...

Go contains many good ideas that may be carried over to more pragmatic languages. Using it for anything beyond simple, self-contained command-line tools and network servers never really worked out for me. And that makes sense, since it was explicitly designed to scale over groups of inexperienced developers at any cost; the opposite of my needs. Modern C++ runs circles around Go for more complex software, and it provides the tools to add as much convenience as needed on a case-by-case basis. I recently ported a 7kloc Go codebase to C++ and wrote down some of my impressions here: https://github.com/andreas-gone-wild/blog/blob/master/rewrit...