Trying new programming languages helped me grow as a software engineer

What grew me the most as a programmer was doing the Advent of Code challenge every year using a different language each year (and doing 1 year with 3 languages each day). Learned so many new algorithms and languages I never would’ve otherwise encountered. Side note, Advent of Code 2022 starts December 1!

"null-safe type" is a term which takes the perspective of backpedaling out of a mistake, which keeps highlighting the mistake. The mistake is unnecessary in the first place; types do not naturally have a null in them that has to be exorcised.

For instance, when we think of a type like "the natural numbers", that's just a set of 1, 2, 3, ... there is no "null reference to Integer" in there.

Thus I think terms like "null-safe type" is just something we should leave to Java programmers, and not use as a way to talk about types.

In a functional language technically you don’t have multiple returns, because the function is a single expression so in a way you’re right. On the other hand the actual result of the expression is determined on a leaf of the expression so you could consider it a return point

To make an example the following expression can be considered to have two returns:

    max x y =
      if x > y
      then x
      else y

The Java equivalent is

    int max(int x,int y) { 
      if (x>y) 
        return x;
      else 
        return y;
   }

Some people abhor the idea of having multiple returns in a method, and say that you should write it like

    int max(int x, int y) {
      int result;
      if (x>y) 
        result = x;
      else 
        result = y;
      return result;
    }

(Disclaimer: Contrived and buggy example as I am on mobile)

> Because of some of my programming teachers, I had a feeling that JavaScript is not a “real” programming language. In addition, it was JavaScript in the frontend environment, so you know, moving divs and buttons around, not algorithms.

Well, it certainly does not live up to the standards of languages, which those people would call "real programming languages". So while they are doing a true scotchman thing there, there is also some truth at the core of it. If we remember JS how it was a decade or more ago, and what JS today still keeps downwards-compatibility with, it is easy to see, how the very foundations are flawed, to say the least. Self-respecting computer scientists, professors or not, will most likely not accept those shaky foundations as something worthy.

Anyway, it is not the pure count of programming languages, but rather the count of programming language families one got to know, that makes the difference. If all one ever touches are languages out of the algol family, then it will have far far less benefit, compared to trying out languages from various families. For example one will learn much more, trying out SQL, a lisp, an APL, Prolog and a Smalltalk dialect, a language with stytic typing and a langauge with dynamic typing, than from trying out Java, C++ and C# and the like.

This is because the various different families do things vastly differently and require you to switch your brain into different modes, while languages of the same family will mostly only make you learn a new syntax and new built-in function names.

Rust convinced me that having a section at the top of a function that early returns in error/exceptional situations works very well. I find myself missing this in the one functional language I've tried, Elixir, although I find Elixir worth it for other reasons.

I initially fell in love with the Rust convention of simply bubbling up errors throughout a function but I've gradually realized that leads to a poor API. [1]

I'm currently learning c++ for a personal project. I want to use a library with an API that's sufficiently templated it'll be easier to write a c++ shim than directly generating bindings. So far I'm at the stage where I'm constantly thinking Rust does things better. Hopefully later on I'll realize why the different tradeoffs c++ makes make sense. (One example would be how generic code is typechecked).

[1]: If you want to be able to simply propagate up errors with the `?` operator you need to implement automatic conversations from your dependencies' errors to your error type. But that means your API will have a single error type for every dependency error type - say MyError::Io(io::Error) - which is the wrong level of specificity. I now think you should either expose only a string message your user can just show their end user or an error that's much more specific so they can write code that intelligently responds to it. Something like MyError::ReadConfigFailed(io::Error)