Ask HN: Why do new(ish) programming languages eschew OOP features?

OOP is inherently an imperative paradigm; you might mean “procedural” instead of “imperative” (certainly, that makes both uses of “imperative” in your post more sensible), but even then, OOP as a paradigm is very closely related to the procedural paradigm.

Strictly speaking namespaces don’t need names, either. But for medium to large projects they’re still useful, and enforced by the IDE.

> to imagine functions living in just a namespace, not a class.

You can place them into a namespace on the consumer side of the API, with `using static`. While not the same, might be good enough in practice: you normally have multiple `using` statements on top, for namespaces.

> I'd be interested in seeing the model reversed, e.g. immutable defaults with something like `public mutable class Foo`

I wouldn’t want immutable defaults, but I do want readonly classes and structures, with readonly being part of the type system.

BTW, the new value tuples with named fields is a step in the right direction https://blogs.msdn.microsoft.com/mazhou/2017/05/26/c-7-serie... Useful but limited, I would prefer real immutable classes & structures. Currently I have to create them manually, mark all fields public readonly, implement the constructor, that’s more typing than I’d like.

Not really; in OOP a method call like `foo.bar(baz)` sends the `foo` object the message `bar` with argument `baz` (in Kay's current terminology); or, in more 'mainstream' terminology, it looks for a method in the `bar` slot of `foo` and calls it with `baz`.

As far as I'm aware, this is a pretty core concept in OOP: if our code isn't organised along these lines, then we're writing non-OOP code which just-so-happens to use classes/prototypes/methods (in the same way that we can e.g. write OOP code in C which just-so-happens to use procedures/switch/etc.).

(Side caveat: I appreciate that I'm making some assumptions here; one of my pet peeves with OOP is that it's rife with No True Scotsman fallacies about what is "proper" OOP, e.g. see 90% of the content on https://softwareengineering.stackexchange.com )

There is a fundamental asymmetry between the roles of `foo` (object, receiver of message, container of methods) and `baz` (argument, included in message, passed into method).

A function call like `bar(foo, baz)` doesn't have this asymmetry: the order of the arguments is just a convenience, it has no effect on how the `bar` symbol is resolved (in most languages it's via lexical scope, just like every other variable). Swapping them is also trivial, e.g.:

    var flip = function(f) { return function(x, y) { return f(y, x); }; };
    var rab  = flip(bar);

    bar(foo, baz) == rab(baz, foo)

Of course, the elephant in the room here is CLOS, but that's sufficiently different from most OOP as-practiced that it's better considered separately (e.g. I'd be more inclined to agree that CLOS methods are "100% pure syntax vs a function call")

> Non-syntactic aspects are maybe a more involved discussion. For an example, I personally think traditional OO lends itself very nicely to runtime polymorphism.

I also disagree with this, again due to the artificial asymmetries that OOP introduces (that objects "contain" methods). In particular, as far as I'm aware OOP simply cannot express return-type polymorphism. The asymmetry between arguments and return values is certainly more fundamental than the completely unneeded distinction between receiver and arguments, but it's still very useful to dispatch on the output rather than the input.

The classic example is `toString` being trivial in OOP (a method which takes some object as input and renders it to a string; the implementation dispatches on the given object); whilst `fromString` is hard (a method which takes a string and returns some object parsed from it; OOP can't dispatch the implementation by "looking inside" the object, since we don't have an object until we've finished parsing).