_Application.Run(Object, Object, Object, Object, Object, Object, Object, Object

If you’re suggesting the current identifier is already latinised, it’s not, it’s translated.

I've basically just said that, e.g., instead of the identifier EmployeeTheNumberThatIdentifiesATupleInARelation, you should really be using the identifier EmployeePrimaryKey. That is, you usually refer to things using the name of the respective concept, not by describing what the thing's concept is every time you're trying to refer to the thing. It's called "coining a term". Or, in programming, abstraction (as per SICP, that is giving a name to some compound construct so as not to be forced to repeat it endlessly).

Surely it has a more generic name, then.

If unicode is allowed, you can also use the Chinese characters

As I understand, only children of father's brothers can be prefixed with 堂, because they have the same last name and are traditionally considered to be in the same house. All others, including children of father's sisters, are all prefixed with 表.

Knowing who is related too closely to you can be a problem on a small island, the comment was possibly referencing the Icelandic dating-app that tracks if you share a grandparent with someone you meet in a bar[1]; a feature the app itself calls a "Sifjaspellsspillir", or "Incest Spoiler".

Interestingly the article mentions that this is a problem precicely because of the Icelandic naming scheme:

> Neither patronymic or matronymic, instead each person's father's first name becomes the child's last name. Each new generation has a completely different name to the name of the generation that preceded it. Cousins, aunts, uncles, nieces, nephews -- all could have very different names.

[1] https://www.wired.co.uk/article/iceland-incest-app

It wasn't "finished" until much more recently than a few hundred years ago.

My great grandfather Søren Kristian Magnussen was born in 1890, and he got his fathers last name. His father, August Magnussen was born Magnusson in 1842 to a Magnus Andersson near Bullaren in Sweden (ignoring the mothers here only because they had no impact on the last names). August's brother Johan Alfred Magnusson had (at least) three children who were named Johansson / Johansdotter born between 1885-1890. So even that late some children's last names were still derived from their fathers first names.

It makes genealogy both easier and harder - on one hand apart from during and after the transition period you get the fathers first name "for free" (most of the time, except when they complicate things by using the name of a farm instead of a last name), on the other hand it makes searches for the transition period a real mess (as if the poor hand writing of everyone involved in record-keeping isn't bad enough).

I didnt know how the naming system works in other countries, I only know about Iceland and UK, but I still suspect the naming exists to highlight relationships. The point I'm trying to make is that when the naming system was introduced or adhered to in an area on this planet, I wonder if they knew about the problems of inbreeding, you see here in the UK, with livestock, you typically have a one or two studs and the rest of females, so there is an element of inbreeding or deviation towards it. Pig farmers will have two or three bores fertilizing the sows, cows will get a bull and roosters are also limited to one for a brood.

So did/does some cultural naming system highlight a lack of inbreeding knowledge or not when considering when it was introduced?

See the German TV show Dark for in interesting take on what could happen if they somehow became cyclic.

Well, family graphs including relationships by marriage and adoption are not in general acyclic.

> But I've honestly never encountered this

Boy do I have the perfect example for you then: https://developer.apple.com/documentation/contacts/cnlabelco...

You've caveated the "valid" answers out of existence. But here are some examples of or-ed concepts:

* parent or legal guardian (shows up on legal forms all the time)

* state or province (an English language political construct)

* DNS name or IP address

You could argue that "parent of legal guardian" is a legacy concept since it really just means "legal guardian", but it's literally written on legal forms, so it's a domain concept, except if you believe it shouldn't count because it's an anachronism.

You could argue that we don't need "state or province" since we can just say "region", but "region" doesn't mean "state or province" colloquially, and we have to be careful not to refer to Ontario as a state, so the distinction is important. Ironically, that distinction does not exist in Chinese, but it does in English.

"DNS name or IP address" absolutely are two different concepts, it just happens that URL's were specced to accept both as the "host" segment. So whether or not it counts as an example depends on whether you believe that the act of coining the term is also the act of erasing its status as an "or" relation. Alternatively, if you're implementing a web browser, that distinction absolutely does exist because you need to know not to try to resolve an IP address as a DNS name.

I agree about passing Either types as arguments, I wouldn't do this. Pattern matching solves this problem.

> If it is a return-type

As for making them return types, it forces you to match over them, you can have the compiler do exhaustive matching over the types it can be. If you have a tuple of (int, string), you could store an int and a string. With Either types, it has to be one OR the other, it can never be both.

Like I said, you can pattern match over this depending on what the type contains. It also allows nice binding and failing out the chain early. e.g. something like in a C style syntax:

    public Either<Error, int> M()
    {
       "In M".Print();
       return 6;
    }

    public Either<Error, string> M2(int y)
    { 
       $"In M2 {y}".Print();
       return $"{++y}";
    }

    public Either<Error, string> M3(string y) 
    {
       $"In M3 {y}".Print();
       return $"Result {y}";
    }

    public void ShowResult(string y) => y.Print();
    public void DisplayError(Error error) => error.Message.Print();

    M().Then(M2)
       .Then(M3)
       .Match(left:  DisplayError,
              right: ShowResult);
 

So, the functions that operate on the Either types only ever take the right type of the Either. If say M2 returned an Error, M3 would never be called and you shortcut to the error handler.

The match forces you to explicitly handle if it's an error or not.

I like this pattern, it can be concise and expressive when used in a context where it's applicable.

> And if it is a class, or even method: it is violating SRP.

I disagree, the Person class is just a Person (and nothing else), the Error class is an Error and nothing else. The Either class is generic and is a way to hold Either of multiple types (but only one at any time).

> make it an `Option<Some, None>:

I like Rusts option type, but the problem is the None state doesn't collect information, but I think it's certainly a nicer alternative to null. Again you can compile time enforce pattern matching to ensure you handle both states.

> Result<Ok, Err>: user`

Assuming Result can only ever be OK or Err, this is basically an Either type!

> And if it is a class, or even method: it is violating SRP.

Not always! Somebody is going to have to discriminate on the argument, and if indeed the caller already knows what they're providing, there's no need to wrap it in an Either -- there should be individual methods for both variants. But if the caller doesn't know what it is yet, and the type represents a domain concept that happens to be a set of options, then there's no reason the caller has to busy itself with that knowledge. To the caller, this might be (actually or morally) an opaque type, and the callee may be where knowledge about it is centralized, and hence where discriminating on the variants ought to happen.

The single-responsibility principle is definitely something that always needs to be kept in mind, but it's not something that can be replaced with broad rules, either.

> If it is a return-type, there too: why not [...] do like Rust: make it an `Option<Some, None>: user` or a `Result<Ok, Err>: user`, the typing now contains this "either/or" not the variable names;

That's exactly what they did -- in the ML-like syntax they used, their `PersonOrError` is exactly `Either<Person, Err>`, but with the type arguments pre-instantiated.

    type PersonOrError1 =
      | P of Person 
      | E of Error

    type 'l 'r either =
      | Left of 'l
      | Right of r

    type PersonOrError2 = Person Error either

Using one word for your family and an unrelated word for your other relatives, including your cousins, doesn't make it sound like your cousins are part of your family. That's a sharper distinction than is drawn in English.

This isn't a question of the pronunciation of the word you use to refer to remote relatives. It's a question of the social relationships that exist between you and your relatives.