Ask HN: What made you change your mind about a programming language/paradigm?

I built games in C++, game engines in C++, and real-time communication servers in C++. As I pushed the language more and more, I wanted to squeeze out as much safety from the compiler as possible. My object-oriented polymorphism (like a function taking a ref or pointer to a base class) became parametric polymorphism (templates). Then my templates became template meta-programming (TMP). Then I was trying to enable/disable safe code paths using SFINAE, but this was only helping me on a type level. I still have undefined behavior (UB) all over the place, due to C++'s history. I still had issues with mutability and parallelism, but modern processors and game requirements demanded that things must not be single-threaded.

So how can all of this happen? Well, safer systems languages like Rust can help, but another approach is to remove the mutation entirely. If we could have a practical language which was built around immutability, we'd have thread safety by default. So I found Clojure and thus began my foray into lisps and functional programming. After spending a while completely baffled, things began to click. I would thing of each of my tasks as a series of pure data transformations instead of a class + members + methods to mutate those members. It was data in, data out. Alas, none of my colleagues were so interested, and I was still their go-to C++ guy for anything non-trivial. So why was the "C++ guy" giving talks about referential transparency?

Ultimately, I had had enough. To me, though I had spent several years building an encyclopedia of C++ knowledge, the state of things didn't seem practical. Not if we wanted to take full advantage of parallelism. Not if we wanted to feel confident in the safety of our code at compile-time. I gave a final talk at my day job, regarding C++ value categories. It's a nasty subject and a deep dive into something many professional C++ developers still don't grok. Ironically, I wrote it in Clojure and it became the go-to cheat sheet for everything value category in C++14 and before: https://github.com/jeaye/value-category-cheatsheet

So, finally, we're still left with the incomplete journey: Clojure's type system. Alas, there's nothing to be done about that. Similarly, as someone who enjoys game engine development, kernel development, and other systems work, Rust is likely the best option for me there. However, it's not functional-first. It doesn't have persistent, immutable data structures (which trade data locality for thread safety; a worthy trade in many cases) in the stdlib. We have other functional languages which do have much stronger type systems, but, in my humble opinion, they often lack the practicality of Clojure. Adhoc side effects, s-expressions (very little syntax), and utter simplicity.

That's why I've been working on https://github.com/jeaye/jank for a few years. It's slow going, but I want it to be a statically typed Clojure dialect, basically, which compiles to native code. Similar to Clojure's spec, jank should allow folks to start with a baseline of data transformations and then build up stronger type checking after things are in place. The big difference is that jank isn't dynamically typed at all; its baseline is much more secure and the additional validations which can be presented at compile-time are akin to dependent types. So, static typing, functional-first stdlib with immutable data structures, s-expressions (Clojure-compatible syntax), gradual dependent typing, and a compilation target of LLVM. To me, that's the dream.

As a last addition, trying to write C++, or most any similar language, these days is quite upsetting to me. I no longer have a taste for it.

That's relying on distribution package management to save you. Here is what happens when you add libraries in any other context:

The library has a dependency on another library, and when you go look at the dependency, it tells you that it needs to use a specific build system. So you have to build the library and its dependency, and then you might be able to link it.

But then, turns out, the dependency also has dependencies. And you have to build them too. Each dependency comes with its own unique fussiness about the build environment, leading to extensive time spent on configuration.

Hours to days later, you have wrangled a way of making it work. But you have another library to add, and then the same thing happens.

In comparison, dependencies in most any language with a notion of modules are a matter of "installation and import" - once the compiler is aware of where the module is, it can do the rest. When the dependencies require C code, as they often do, you may still have to build or borrow binaries, but the promise of Rust, D, Zig et al. is that this is only going to become less troublesome.

Types, because of testing.

Python code is really hard to maintain once you grow over a few thousand lines of code and a few developers.

I used to believe that a good culture and seasoned developers can delivered testable code, but it rarely happens in practice. Even if, deadlines kill testing budget.

Types make refactorings sane, they are you contracts. Ended up in Haskell.

Ladder of abstraction and Functional Programming

[1] http://worrydream.com/LadderOfAbstraction/ [2] https://en.wikibooks.org/wiki/Computer_Programming/Functiona...

Why do you think javadoc is better than docstrings? There are docstring-based languages that encourage good practice and can produce what I regard as excellent integrated docs. E.g., Julia's Documenter:

https://juliadocs.github.io/Documenter.jl/stable/