PDoyle

No, not simple. Analyzing an arbitrary lisp program to determine the lifetimes of all allocated structures reduces to the halting problem, so it's undecidable. You must either restrict the input program or tolerate some leaks.

Not in Canada.

There are other articles like that, of course.

Not true when the comments are mechanically checked for correctness.

You're not the only one. It's a common sentiment if you haven't really, fully used a type system before.

If there's an important property you want your program to have, and you can express it using the type system, then your compiler can prove it for you. For example, if you have an Employee record with a jobTitle field of type String, then it's hard to be certain you'll never get an invalid jobTitle. If you change that to a type hierarchy with subtypes like Manager, Developer, etc. then once the program compiles, you can be certain that particular error can't happen at run time. As type systems grow more sophisticated, more program properties can be represented as types.

If you want to experience it, perhaps try a language with a really top-notch type system like OCaml or Haskell. Maybe try implementing some kind of transpiler from json to json that uses the type system to describe the valid input. You'll have a collection of parsing functions that detect all the errors, and then the rest of the system can rest assured that the parsed representation is error-free, and you can be certain that you never forgot to handle one of the possible cases. (OCaml, in particular, is very good at this.)

If you try this, and you're human, I think you'll make a few mistakes that get caught by the type checker.

It doesn't. Not sure what that guy's talking about.

Same happens with integers. Try computing the mean of 3 and 4 using integer math.

The only difference, really, is that floating point can lull you into believing they have unlimited precision. With integer math, the problem would have been more obvious in the first place.

If you're interested in memory layouts in Java, I wrote a blog post recently discussing a way to make super-tight data structures in Java:

https://engineering.vena.io/2016/05/09/transpose-tree/

J9 has had one-word headers for years now. I think this article was already out of date in 2012 when it was published.

This article is super old. Those options are now default, and the overhead is much smaller. (I think even in 2012, we already had 1-word headers.)

You're right, that's the Java/C++ way. I was trying to do it the OCaml way in Java. :-)

Ultimately, what I wanted was a way to declare the variants in one place. I didn't want to repeat myself. The only way I could think of declaring them once, and still being able to both produce and consume values of those types, was with a generic visitor interface.

You've done it with a C++ class hierarchy, which has the following properties that the OCaml solution does not:

First, it needs to repeat the components of each variant type three times: once as field declarations, once as constructor arguments, and once as initialization statements in the constructors. The OCaml one (and my Java one) lets you declare the types, fields, and constructors in one line of code.

Second, your code is arranged into classes, which means that adding a new function (say `toString`) requires adding new code in N places, for N types. In OCaml, you'd just write one new function with N variants. (Of course, your code is better if you want to add a new type.)

<groan> Hello World tells you nearly nothing about a programming language.

(Unless, of course, it's written in Java, in which case it's a painstaking tour of the entire programming language, requiring you to learn the concepts behind "class", "public", "static", "void", "main", and arrays, despite never actually using any of those things.)

Was that the A-Team van at the start?

Locality depends on many factors. True, the fields for a given object are spread out; however, they are much smaller. If you're iterating through a consecutive sequence of items in your compressed tables, you end up using the cache quite efficiently.

Yes, that kind of "transaction-based" memory management is beautiful in applications where it's appropriate: just leak memory until you're done with the current task, and free it in one chunk. That's hard to beat for performance and simplicity.

What's the point you're trying to make? That GC can't beat manual memory management on arbitrary workloads with no tuning hints? Ok then, no argument here.

The difference is that free() needs to be able to free objects one-at-a-time without knowing their size, and without moving any live data around. This inevitably leads to fragmentation, one way or another.

Check the title of the article. I'm comparing GC verus malloc+free specifically.

I'm the author of the article, and I agree 100% with you: there are definitely application-specific memory management schemes that beat both malloc and automatic GC. In fact, I'm working on one right now: it's a way of storing a huge balanced tree data structure in arrays to save space.