Hacker News Reader

Whereabouts do I confuse the role of inheritance in C++? I just used it as an example of a language which has inheritance built into it. It's completely optional, of course, and I was not suggesting anywhere that it was required. In fact, I rarely use it at all in my own C++ code, and when I do, I usually go the old fashioned C-like approach (for numerous reasons which I won't explain in this comment).

In the article, I define inheritance as the following:

> Most people generally view inheritance as a combination of subtyping and dynamic dispatch through virtual method tables (vtables).

So I did not confuse anything between regular and virtual member functions.

You have made a lot of assumptions about my views which are not even in the text.

And I agree Computer Science is very much not a science in the natural sense. I do with many more people would either say it is just mathematics (formal science) or start giving empirical evidence for their claims that "X is the best way to Y" (natural science).

The author also managed to use the same word, linear, in two different senses while pretending those are the same (or very similar) senses.

Bonus points for having a somewhat long list of definitions that explains that the words are used in their usual meaning, yet does this by the way of introducing more undefined terms, sometimes tautological: an Agent is an actor with the capacity to act, marvellous. "A Doer is a doing entity that can do things"--agent and actor are both derived from the same Latin verb that means "to do". And that list misses the definition for "linear", which is definitely not used in any usual sense of the word: trees are linear, but graphs are not... huh?

Yeah by the end of it I was dying for an explanation of what all the uses of linear and non-linear were meant to imply. One paragraph has the words mentioned six times in three sentences!

The whole thing would be much more obvious if they ditched half the philosophising and gave a concrete example of the problem and their solution. Then by all means talk about the philosophy behind how it generalises.

> "linear", which is definitely not used in any usual sense of the word: trees are linear, but graphs are not... huh?

While I agree with your overall point, this is a usual definition of linear: each item (eg graph/tree node) is used (eg pointed to) at most[0] once (eg each tree node has at most one parent node, whereas a graph node can have multiple edges from other nodes).

  0→2  0→2
  ↓ ↓  ↓ ↓
  1 3  1→3

Left is a tree, and linear (each node has only one arrow pointing at it), while Right is nonlinear because there are two ways to get to 3 (via 1 or 2). In this context it also means that if (eg) you print out the graph in a naive S-expression-style traversal you'd encounter 3 twice (eg "(0 (1 (3)) (2 (3)))" when each node is a list).

This sense comes from linear functions, which can be expressed with at most one use of their argument in the form λx(Ax+B) for A and B constant in x. (Under this scheme, x² would have to be expressed as x·x, which repeats x; linearity in programming languages generally allows numeric values to be duplicated freely, so this is only of etymological relevance.)

0: or possibly exactly once; I can never remember which of those is "linear" and which is "affine".

You are partially correct that I have a minor tautology i.e. an actor is something that acts. I wanted to use the term "agent" because "actor" already has a slightly different connotation in common programming speak, and I wanted something a little more specific. That's why I used that term. I do know the etymology of the terms Agent and Actor, but the point I was making is that these abstracted concepts don't actually "do" anything in reality. They are abstractions we use to help us structure and think about programs (regardless of it they are actually useful in practice or not)

I was also using the term "linear" with respect to graphs: * All trees are graphs, but not all graphs are trees. All linear graphs are a form of tree.

Whereabouts was I using the term _linear_ in two different senses?

What is a linear graph? What is "linear hierarchy"? That's the first time I've heard those terms, and I did have a decent Discrete Maths course back in the uni (it did have graph theory and algorithms on graphs). "Value", on the other hand, is indeed generally understood to mean "a datum with an associated type", maybe without "with associated type", pretty much universally since the sixties.

As for two different senses, look at the the first paragraph in the "Mathematical Formalism of Ownership Semantics": it uses "linear graph" and "linear logic" in the same sentence. Unless you define "linear graphs" as "graphs that are described by linear logic", but to the best of my knowledge, linear logic describes the structure of computation (that's why it's logic, it describes the proofs and you get code via Curry-Howard isomorphism), not of data. Unless you equate the graphs with their traverses? But again, that's all highly non-trivial and non-widespread knowledge and terminology, unlike "value is a piece of data" and "agent is an actor".

A "linear graph" is effectively a graph with no cycles in it, i.e. a basic tree.

All hierarchies can be described using graphs, and hierarchy is a relationship between different things in that graph through some dominating aspect (whatever that might be). A "linear hierarchy" is a hierarchy with no overlapping parts, no cycles, and a unique way to traverse up the hierarchy, e.g. you father is your son is not allowed, a node cannot be part of multiple hierarchies, a node has two parents which share a common ancestor, etc.

I am not sure why you brought up my "Value" definition, that was a little random.

> Unless you equate the graphs with their traverses?

I mostly am because data structures on their own without algorithms are useless things. Type systems try to encode information about the values effectively restricting what algorithms can do to them. Ownership semantics are another aspect of the type system of some languages which encodes a responsibility dependency graph to values. This means it explicitly restricts what data structures can be like _by default_. It encourages linear data structures, where the dependency between the values can be model through linear logic. This is why something as basic as a linked list is difficult to implement in languages designed around ownership semantics. It is of course possible but either requires restricting what the linked lists can do, or doing something to bypass the ownership semantics entirely.

> I am not sure why you brought up my "Value" definition, that was a little random.

Because your definition of "Value" is uncontroversial and customary, unlike your definition of "linear graph"--I have met it in your article for the first time. Granted, my knowledge is limited but that's my point exactly: if you bother to introduce the most basic concepts that your readers are most likely already accustomed with, then also please introduce the advanced concepts that you're about to discuss. If you feel that it makes the article too long, maybe consider removing the trivial definitions of the basic concepts, but not the other way around.

I don't want to come off sounding aggressive or rude, and in fact I've read some other articles on your site with great interest, but this particular one leaves a bit of a taste of a maths article written by a crackpot: it starts with talking about what is a number, what is addition, talks about how numbers can also be multiplied and divided, a-a-a-and then in a blink of an eye it goes into very remoted areas of the number theory which may not actually exist (at least Googling them doesn't show anything relevant).

In fact, googling "linear hierarchy" suggests that it's a term from biology, and it doesn't describe a graph or a tree at all: "In a linear hierarchy, there is one individual who dominates all the other group members, a second who dominates all but the top individual, and so on, down to the last individual who dominates no one" (Ivan D. Chase, Kristine Seitz, "Aggression", in Advances in Genetics, 2011). So "linear hierarchy" is apparently a linear (or "total", as it's also called) order, and it's actually consistent with the customary definition of "linear data structure": the one that arranges it's elements in a sequence, so arrays and linked lists (in fact, those used to be called "linear lists", see Wirth's "Algorithms + Data Structures = Programs" from the seventies) are linear data structures, but trees and graphs are not.

To sum it: your usage of the term "linear" seems to be novel, and so it's confusing for someone who hasn't met it already, and arguably most of the readers haven't, maybe define it, even at the expense of defining what a "value" or an "agent" is? Those words you use in their customary senses.

> this particular one leaves a bit of a taste of a maths article written by a crackpot

That gave me a good laugh! I do understand the issue and I am not a brilliant writer in this regard. I was trying to make it understandable to the average programmer but also be at least "correct", and I think I have kind of failed at both in this article. I wanted to make sure that the ideas I was trying to express made sense not just to me or in speech form, but in written form too. I added all those definitions, including "value", because I know so many people who use the terms "value" and "object" interchangeably and assume all values are "objects" in the OOP sense. So I wanted to make a distinction between the two, as I wanted to emphasize the object-ness as the key relationship, not the value-ness.

I am quite interested in how people build mental models of things and how they think about programming in general, but there is very little on the topic currently. And ownership semantics (even the name alone) has a lot of implicit assumptions tagged along to it that I wanted to understand. In sum, "ownership" is the wrong word but oh well, silly history.

And yes, "linear hierarchy" does come from biology. It does mean "linear order" in that sense. That is a much better way of explaining it succinctly.

Interesting you brought up Wirth, since he is one of my idols and that book is absolutely amazing. I always recommend Wirth to beginners wanting to learn how to write compilers.

I noticed the same thing with linear and duly noted it as the four term fallacy

>(Also: what distinction is being made between "oriented" and "orientated", and why?)

My guess is that he's just explicitly acknowledging the Commonwealth English preference for using the verb "to orientate" to mean "to focus/to position", while on the other hand the verb "to orient" is traditionally understood as literally meaning to orientate something in an easterly (=oriental) direction.

I'm a British English speaker, I use the verb "to orientate", but "object-orientated programming" still sounds unnatural to me. It's a bit like "program" and "programme"–we use "program" for software, "programme" for everything else.

I have never heard of "orient" to mean "point something in an easterly direction." The difference between "orient" and "orientate" to my ear is "orient" is a verb and "orientation" is a noun. That means "object-oriented" is a gerunded adjective and "object-orientated" is an compounded adjectival noun. Since the usage is as a gerunded adjective, "object-orientated" is just grammatically awkward. But I'm not a grammatical prescriptivist, so you guys do you.

You are correct. I am British and write in British English. I naturally say orientate rather than orient. It's also a minor joke to add both but whatever.

> The sorts of confusion seen here are quite common in philosophy, which has great difficulty staying grounded to facts of experience, something I think Wittgenstein complained of.

I have to comment this, being myself a multi-class character (both computer science and philosophy graduate). The confusion seen here is quite common when somebody without a proper philosophy background is trying to hold a discourse on abstract philosophical topics. Obviously it happens often in philosophy, but often due to the outsiders (computer scientists, physicists, sociologists, artists) who believe, they have revolutionary ideas ;) Wittgenstein's (or rather Kripkenstein's, depending on the interpretation) were rather of a different, more profound, nature.

In my opinion author has decent ideas but lacks skills in communication to express them properly.

> because the facts of problems to be solved and, moreso, of the physical machines we use in solving them provide ground truth.

It is a very optimistic view of the programming as a knowledge domain. IMHO in real life "The facts of problems" are often very blurry and prone to similar problems seen in the philosophy. I am not talking about academic toy problems, but real-life problems that have to be solved.

Thank you for your comment. I mostly wrote this article as a way to get an idea out of my head rather than present it as a thesis on the topic. I am not a philosopher, but a physicist by profession, so I apologize for my lack of correct terminology to explain the topic correctly.

I do enjoy reading philosophy but there is very little in terms of "philosophy of programming" in order to have a common language to talk about. I could either go full mathematical and most people will not know what I am talking about, or go full example based, but then lose the essence of the problem.

What I wanted to say is that ownership semantics can only deal with "linear" problems whilst most problems are "non-linear" in nature. And that designing an entire language around this idea to ensure "safety", especially without it being "proven" in a smaller language, is/was very risky and dodgy.

I also wanted to explain the mentality that many (not all) people have with regards to ownership semantics and how it regards to a certain concept of "agency", and how it is related (not the same) as the OOP mentality.

P.S. The original commenter is confused about my views, and made mistakes about what I stated. https://news.ycombinator.com/item?id=24999902

It's very difficult, but important thing, to express abstract things in a correct, yet still understandable way, so "kudos" for trying :)

You make a good point, however:

1) > And that designing an entire language around this idea to ensure "safety", especially without it being "proven" in a smaller language, is/was very risky and dodgy

It's not exactly true that ownership models weren't "proven" in different languages. Objective-C comes from the top of my head; the main memory management technique there was reference counting (with the memory pool/manual management fallback). And yes, the non-linearity of some structures was a pain in the ass, one had to be careful to not create a "strong reference loop", but... in the end it worked quite well :) The difference is that in Obj-C one had to do it manually/in runtime, Rust checks it automatically/during compilation.

2) quoting your article "Ownership semantics [...] cannot be used to express non-linear problems".

This is a very strong claim. What does it mean for the problem to be non-linear? I would say, that linearity (in programming) may be ascribed to a model of the problem, not the problem itself, i.e. Traveling Salesman Problem is a problem involving a non-linear structure and still the best known solvers (e.g. Concorde) use linear models to solve it.

It is true that ownership semantics has to be bypassed in the non-linear model, but the question stays whether the given problem really requires one.

Sure, anything Wittgenstein ever thought could never be expressed in anything so crude as human words. Yet, here we are, muddling along.

I have to agree with the author that ownership is a tail that should not be allowed to wag the language dog.

> How confused can one person be?

IMO this sentence is completely unnecessary.

> Unlike in Java, which offers practically nothing else to organize a program, in C++ inheritance is wholly optional, and is typically used only where it solves a specific problem.

As someone with extensive experience in both Java and a number of other languages (before and after learning Java) this just isn't true.

It detracts from your point for everyone who knows Java and it adds unnecessary anxiety for people who will learn Java in the future if they belive this.

Java has flaws, but inheritance is not the only way to compose Java programs.

Edit: As a general rule I'd suggest everyone stop pretending Java is generally bad until they have some actual experience from real world systems in Java and a couple of other languages under their belt.

Been a while since I used java but is it still the case that your main function has to be inside a class which has to inherit, ultimately, from Object? I think that's what gp meant in implying that inheritance is not optional.

In practical terms of course a bit of boilerplate to declare a class where none was needed, doesn't matter a great deal.

> but is it still the case that your main function has to be inside a class which has to inherit, ultimately, from Object? I think that's what gp meant in implying that inheritance is not optional.

This is correct but not what GP wrote. What GP wrote is:

> Unlike in Java, which offers practically nothing else [than inheritance] to organize a program,

To point out why GP is wrong:

- In Java you can organize files by packages

- by purpose (different folders for test vs production code),

- you can use composition to combine classes (in fact this is the recommended way these days)

- etc

I normally don't care about language wars but I think it is OK to point out when someone writes something that is clearly wrong.

Also, you can further organize your packages into Java modules (Java >=9).

I don't know why people say that you can't use composition in Java or that it is unique to purely functional languages. You can achieve composition by using Streams, decorator, composite and chain of responsability patterns.