Maybe We Can Have Nice Things

It's not your imagination. Python tooling is awful.

If I may be forgiven a bit of preaching, I'll point out that the fundamental problem with the Python ecosystem is that package definitions are executable python code. This means they have their own dependencies, and are subject to all the pitfalls of general purpose programs - the halting problem, non-determinism etc. The Python community keeps trying to fix this by writing a better installer, and it's never going to work.

NPM and Cargo, with their declarative package definitions, are built on a far more stable base!

Error handling is an everywhere concern. In general, recoverable errors are more local, and unrecoverable errors should crash/throw.

Here are a bunch of error-handling strategies that I'm aware of (which one is valid depends on the situation).

- Die immediately / assume the error won't happen, but still code defensively.

- Throw an exception (in languages that support this). setjmp() / longjmp() also falls in this category, although it is hard to do correctly.

- Return an error code to the calling function

- Contain the error in a data structure.

The last is a truly object-oriented approach. In larger systems this is the one that scales. Its advantage is that it decouples the error detection from the handling (temporal decoupling) and allows the error to be handled asynchronously. This is a property that exceptions don't have.

Exceptions are, in my experience, not nice to use. If you actually want to handle errors (i.e. not use them only as a glorified die() function) the code gets really ugly - you tend to use them like error return values, but with more verbose syntax (having two return mechanism is bad since it reduces compatibility of code).

I know a situation where exceptions can be useful: when interpreting a chunk of code in a sandbox in a synchronous fashion - i.e. you call the interpreter function of that virtual process, and that process either completes successfully or terminates with an exception. The virtual process is then cleaned up. There is no possibility to interrupt the interpretation and resume some time later.

This is more of a toy setting, though. You don't write complex systems like that.

Yeah, good point. The reason NPM can have packages like left-pad is that it works so well. It's easy to publish a package, it's easy to find one, it's easy to install and use a package. So sure, why NOT make a package for one function that you use all over the place?

There's a downside to all this, but ultimately it's to NPM's credit: the tools are so easy to use that people... use them.

> throw is not at all like GOTO

They are the same thing.

To see it clearly, replace each exception with a label, each "try" by a no-op, each "catch" by a label statement, and each "throw" by a GOTO statement.

    try:
        foo()
    catch BarException
        baz()
    

    def foo():
        ...
        throw BarException
        ...

Is like:

    CALL foo
    GOTO end
    LABEL bar
    CALL baz
    LABEL end


    LABEL foo
    ...
    GOTO bar
    ...
    RET

Either you have relatively simple exceptions and the equivalent GOTOs would also be simple enough to be not "considered harmful"; -or- you have complicated exceptions, which is really an ad hoc state machine, and you might be better off making that explicit rather than hiding it in a tangle of try/catch/throw control-flow logic, eh?

There are still people who disagree that the world is round and a very very large portion of the populace is religious when it's abundantly clear that religion is bullshit. Go is an outlier with a huge media machine behind it and it will disappear back into the abyss as soon as Google stops pushing it with no contributions to programming language research at large.

There isn't a good answer. RAII is a great thing that I use all the time. However it requires deterministic destruction which in turn means some form of reference counting garbage collection. Garbage collection research has found non-reference counting garbage collection has a lot of advantages. So as a language designer you need to choose, better garbage collection at the expensive of non-deterministic destruction, or worse garbage collection but you get RAII. There isn't a clear winner.

For about 80% of all garbage this doesn't matter because it turns out the reference count is always one until it goes to zero so you don't need to track it, and in turn this means the better garbage collection algorithms I mentioned above are not better in this case. However this rule of thumb comes from C++ where training (based on real performance needs of the type of code you might write in C++) keeps people from doing the types of operations that would increment the reference count. Which is to say even if Java could figure which cases can use this rule (this appears like variant of the halting problem to me), they would probably discover that the number there is enough less as to not make it worth adding.

Worse, in C++ there is a tiny number of data structures with circular references that you cannot use reference counting to deal with. Thus as a C++ programmer will sometimes have to write some other garbage collector for the edge cases, and these don't get RAII deterministic destruction.

Note that I didn't state the advantages of better garbage collectors. I am not an expert here, so I'm leaving it as an exercise to the reader. Just know that there are advantages to them that make them a great choice for some problems despite losing RAII! If you are designing a language you should probably look into this early. (I was going to say a hybrid is the worst of both worlds - but maybe I'm wrong so I'll let you figure that out)

And everything that has existed outside Bell Labs and UNIX.

.NET will always be looked at as enterprisey, and old school. I agree that it has advanced a lot, but I don't think anything will change that perspective.

The programs Palmer is talking about already exist, and are already implemented in C and C++, languages without managed runtimes. Rust is interesting here because it is memory safe and also doesn't have a managed runtime.

A programmer's opinions of various technologies is highly trajectory-dependent. The problem of uneven distribution of lore is exacerbated by two startling factors: we tend to be ignorant of the history of our field; and we are fashion-driven to a fault. I suspect that's how you get educated intelligent people with, um, unusual ideas about things. (E.g. I've worked with fellows who did not know who Alan Kay was, or what Prolog is.)

In re: Rust, Graydon Hoare gave a talk on the history of compilers in which he doesn't mention Prolog. https://thenewstack.io/rust-creator-graydon-hoare-recounts-t... I suppose he just didn't think it was relevant, but it's possible even he is a little ignorant?

I see a ray of sunshine in the form of a nascent and inchoate new paradigm that could be called "Categorical Programming", Conal Elliott has the scent: http://conal.net/papers/compiling-to-categories/ CT provides a mathematical formalism for finding the most highly factored forms of various functions/programs, enabling a kind of "convergence" of code to its most efficient form. But that's a big ol' tangent.

My point is, it's often more informative to try to understand the context in which something someone says makes sense, than to just decry them as wrong. Oh, and to remind folks to read your history!

RAII is a core fundamental feature of C++ and I would argue that constructors and destructors are the implementation.

With RAII (using vector, string, unique_ptr, etc), memory leaks are pretty much a solved problem in modern c++. The biggest memory danger in C++, in my opinion, is dangling references where you have a reference to an object (either on the stack or heap) that has been destructed.

The idea in RAII is you create a type that's solely responsible for acquiring the resource and freeing it (and little else). This idea is indeed fundamental to modern C++ design. For example, smart pointers.

When created, the pointer lives on the stack. The resource it points to lives elsewhere but that's no concern to RAII. When the stack variable goes out of scope the resource will automatically be freed (via the destructor)

One place where this can break down in C++ is in copy and moves. The acquire/release works simply enough using constructors/destructors but correctly handling copies and moves has turned out to be harder to get right. And when you add in other objects that may refer to the resource object... well things can quickly become even harder to handle unless you're very careful.

What's a fundamental feature for C++ then, if not RAII?

GC may not be the fundamental feature of Java the language, but it is certainly a fundamental feature of JVM.

You should look into modern c++ - at least C++11. While it is possible to write the code with all the problems you state, C++11 adds some neat features that mean in practice you rarely do. Sure I can put something on the heap and forget to free it - but in practice I don't put anything on the heap without first wrapping it in something on the stack so that when the thing on the stack goes away my thing on the heap does too. This can get really complex fast to deal with edge cases, but most of the time the complexity is hidden and so doing the right thing that always works is just as easy as putting something on the heap that I have to remember to free latter.

Most people use address sanitizer not valgrind for the few times they have a memory leak. In general though the problem is solved not by tools but by using the modern C++ features. Valgrind is really only useful when you need to deal with C interfaces. (note interfaces, the code on either side need not be written C)