Change (primarily Operator) nodes to have more descriptive names

[Zyzyl]

I and others have variously mentioned in Discord that the current names for several nodes could benefit from being more descriptive. I realize many of the current names are standard symbols in many programming languages and thus may appear very familiar to those with software engineering experience. However Neos is not aimed solely at a software engineer audience and renaming some nodes would help lower the barrier to entry for using one of the main Neos creation systems.

Specifically I suggest making changes along these lines:

• ! becomes "Is Not !" or "Not !"
• != becomes "Is Not Equal To !=" or "Not Equal !="
• % becomes "Remainder %" or "Modulo %"
• & becomes "And &"
• ?: becomes "Ifelse ?:"
• ?? becomes... something better, I'm not 100% sure what this actually does
• | becomes "Or |"

Also:

• -> becomes "Dereference ->" or something else if I've got the wrong technical term here.

There are several others which could probably benefit from the same treatment, but these seem like the most important. Particularly !, !=, &, ?:, and | since these are all nodes where the use case is pretty clear if the node is named in plain language but potentially completely opaque if not. :? is probably the worst case here since it's such a useful node but I can't overstate how unhelpful the current name is for most people.

A secondary point which affects some of the mentioned nodes + a few others is that wiki pages absolutely cannot contain the characters # < > [ ] { } | (see here). Adding some descriptive text to the name of any nodes containing these would make it easier for people to search for the node's wiki page.

Finally, I suggest making bools the default input type for !, & and |. I can add that as a comment here if you prefer https://github.com/Frooxius/NeosPublic/issues/358

[Frooxius]

I think we can do both. My long term goal was to actually have a simple graphic on each node that would have the main symbol and then smaller text for the word description. Maybe even some simple infographic.

The problem with longer names (and why I used symbols in the first place) is that they're a bit harder to read and slower to parse. Especially if you're using a VR headset (particularly older one with lower resolution), you'd need to get close to the nodes to see what they are, whereas symbols are recognizable from afar.

Having a big symbol and smaller text (e.g. ! with smaller "Not" underneath) could work well. If you're not sure what it is, you look up close and you remember the symbol at the same time, making the work easier later on.

I'm not sure about ?: being "If Else" though, as that would conflict a bit with the flow nodes which already has "If Else" (although it only says "If").

?? is also problematic. It's called null coalescing operator and I don't know if there's a short description for it that would fit on the node. This is a point where having a direct link to documentation for the nodes would help instead.

[mralext20]

The conflict of if and :? with flow nodes seemed like a non issue, considering the existing of ++ and -- both in the actions folder and in operators

[mralext20]

?? To if not null else

[Zyzyl]

Thanks Froox, I think adding some smaller text for these while retaining the large symbol would be a reasonable approach.

Perhaps ?: could be called "Conditional" or similar, though I don't think "Ifelse" would be too much of an issue (or unprecendented as Alex pointed out).

Just, looked ?? up - maybe that could be "First Not Null" or similar?

As and when you decide to implement this I would suggest making the changes to pretty much all nodes with only non-alphabetical names, maybe + - x ÷ could be spared, but there's really no harm in over-clarifying things.

[Frooxius]

@mralext20 It's not as much about the name clash, as that the ++ and -- do pretty much the same thing, but ?: is a bit different semantically, as it deals with evaluation, rather than program flow.

Conditional sounds good though, that's short and simple enough. It's often named conditional or ternary operator so that would fit.

"First not null" might work yeah. The smaller labels could be added to all anyways, the ÷ confuses a few people too, so if it has small "Div" or "Divide" under that can help.

[Earthmark]

I do agree that more verbose names would be nice, there has been many times where I'm explaining logix to someone and they're like "dafuq's this ?: thing?", And when I explain it and they ask why this symbols, all I can really say is "it's a c/c++/c# thing..." And I realize I don't really have a good answer. The same thing has happened with or, and, not, and xor. Oddly the Boolean ops that are spelled out still confuse people, but they don't seem to care as much?

[sirkitree]

I'd request that we do not make these logix nodes larger with longer text, but have a way to have an explanation on hover or something. LogiX already can get large and hard to parse over an area, and the longer each node is the harder it is to make it compact and parse quickly in my head. But having longer descriptions that are only shown on hover could be pretty decent.

[Zyzyl]

@sirkitree That also sounds like a possible option, although I think the additional explanatory text would absolutely need to be visible in the node browser without spawning the node.

I don't think node sizes would necessarily grow muich though - there is often unused space on the node visual and Froox was suggesting using a smaller font for the more descriptive name anyway.

[Frooxius]

@Earthmark It's not symbols specifically because of C/C++/C# thing, but to help improve readability. Consider headsets that have lower resolutions, for longer names you have to get much closer to them to read what the node is.

However the current symbols are tentative solution as well, the ultimate goal is to have a proper graphic for each of those core nodes, that combines both approaches.

@sirkitree That could work too, although I think a small description would fit in the node as well, while keeping the existing symbol at pretty much the same size. We'll have to experiment though.

I definitely want to maintain the ability to quickly parse and read what the nodes are though.

And yeah the description would need to be show in node browser too, but that shouldn't be a problem.

[Banane9]

I'd request that we do not make these logix nodes larger with longer text, but have a way to have an explanation on hover or something. LogiX already can get large and hard to parse over an area, and the longer each node is the harder it is to make it compact and parse quickly in my head. But having longer descriptions that are only shown on hover could be pretty decent.

Very much agree with @sirkitree there - the symbol nodes are recognizable as a programmer, and quick to read.
Descriptions on hover are lacking all over the game, really.

[iamgreaser]

My 2¢ coin, which has held no monetary value for decades...

Stemming from #3169 where I express a miniscule part of my hatred for truncation (round-toward-zero) division, I propose the following renames:

• Math/Repeat should be Operators/Mod.
• Operators/% should be Math/Truncating Remainder, although ideally buried somewhere one isn't tempted to accidentally use as truncation remainder is as far as I can tell always the wrong thing to use.

And weighing in on the other nodes mentioned above:

• ! should be Not
• != should be ≠
• % should be in the trash and replaced with modulus, but because it exists already, see above
• & should be And
• ?: should be IfElse
• ?? is a hard one to pick a name for, although "Coalesce" makes sense if you've done enough SQL and if you haven't it still makes no less sense than "??".
• | should be Or
• ^ should be Xor (fun fact: in Lua, ^ is exponent, and that actually makes way more sense)
• -> should be Deref

Of course, if you really want the mathematical symbols for the logical operators:

• ! could be ¬
• & could be ∧
• | could be ∨
• ^ could be ⊻ or ⊕ (seriously, who came up with ^ in the first place? It's not even the right way up!)

and then you can proceed to get ∧ and ∨ backwards while you get used to things. Yeah, I think I'd rather have words for those, thanks.

[iamgreaser]

I went through the whole list of nodes in the Operators section after realising that << and >> haven't been scrutinised yet. Here's some stuff I'd change.

• << change to SHL (can be confused with "much less than")
• == OK, but = is also a candidate
• >> change to SHR (can be confused with "much greater than")
• ° put in Math and change to Deg Between (too easy to confuse this with ∘ which is function composition, especially as the text render renders it like that)
• Mask should be merged into ?: (which should be called IfElse)
• Project OK namewise, but needs better names for inputs (e.g. A → Point, B → Origin Plane)
• Reflect OK namewise, but needs better names for inputs (e.g. A → Point, B → Origin Plane)

In terms of consistency, I've noticed that ROL, ROR, NAND and NOR are all in ALL CAPS so if changing the other binary logic nodes, AND, NOT, OR and XOR would be the most appropriate names.

[zkxs]

My Beef

I've been eyeballing this issue for a while in silent disapproval, and I think it's time to throw my two cents in as I'm afraid of becoming the silent majority (or minority, who knows).

I'm really not a fan of either the long names approach (e.g. != becoming Not Equals) or the set theory symbol approach (e.g. ! becoming ¬).

The long names approach has an issue with visual clutter, as Frooxius already pointed out. While it may be easier to learn the nodes if they have long names, once you're up to speed my belief is the visual clutter will slow you down.

The set theory symbols approach has a couple of issues I can see. Firstly, I believe we have more people in Neos with a programming background than a mathematics background. Why not use the symbol set that has a broader audience, that being programming symbols? The second problem is the set theory symbols are difficult to type. This makes them difficult to talk about and search for.

A question that was asked in #questions-help:

What exactly is the logix node that's literally just a triangle?

Imagine that user trying to describe the ¬ hieroglyph. If we replace current node visuals with set theory symbols the problem we're already having with Δ will spread to the other nodes.

My Proposal

I propose leaving the programming symbols as is, and adding some sort of opt-outable tooltip on laser over with a more verbose description of the node.

[Banane9]

That's pretty much what I've been thinking too - although it's just boolean algebra, not set theory ;)

What I could also see, is an enum setting for which format you'd prefer, description, programming or mathematical.

[iamgreaser]

I propose leaving the programming symbols as is

But why settle for mediocrity when you can at least make things somewhat better? I mean, after all, what exactly is the logix node that's literally just a triangle?

A fallacy here is assuming that every popular programming language has the operator set from B, which is the precursor to C, which is the family of languages that C# belongs to. If you're wondering where the janky operators come from, it was because B was a cut-down modification of BCPL designed to be easy to parse on a low-end mainframe.

The problem is that there are people in the Neos community who predominantly use a really obscure programming language called Python which just got ranked as the most popular programming language this month (October 2021) on the TIOBE index. No really, that finally actually happened.

In Python, condition ? true_value : false_value is a syntax error. That's because when the if-else "ternary" didn't exist until Python 2.5, where it was given the syntax true_value if condition else false_value. Calling the node IfElse, or perhaps If (newline) Else, would make more sense to a Python programmer, and would also make more sense to a C programmer than ?: would to a Python programmer.

I've also bumped into a couple of Scheme programmers, where there is no separate syntax for if/else - the (if condition true-term false-term) syntax/macro/special actually passes the return value through, as per other languages in the wider Lisp family. Similar approaches are also taken by Nim, Zig, and Rust.

But if we really need to make the ?: node confusing to people, then why not use the Prolog syntax of ( cond() -> (!, TrueTerm); FalseTerm ) , and just call the node (->(!,);) ? Now it can make sense to nobody!

The second problem is the [boolean algebra] symbols are difficult to type. This makes them difficult to talk about and search for.

Good point. In that case, why stop there? We have ≤ and ≥, should they be <= and >= instead? I'm aware that Prolog and Erlang use >= for greater-than, but Prolog is behind COBOL in the TIOBE index and Erlang doesn't even appear in the top 100 any more, so <= would be more familiar to people.

What I could also see, is an enum setting for which format you'd prefer, description, programming or mathematical.

At first I thought this was going to be a nice idea but a total mess, and then I realised that when you go through the node menu, you want to be able to find what you're looking for quickly, and we've already got more than enough mystery meat navigation in Neos thanks (I'm glaring at you, inventory menu).

The hardest part (after the obvious bikeshedding of course, by the way I want it pink with bright green stripes) is working out how to sort things logically based on the combination of locale and notation-preference. In essence, you're going to have some sort of multi-dimensional locale scheme to make it happen.

But that could end at least some of the arguments for some of these nodes - "I want my stuff to look like math", "I want my stuff to look like C#", and "I want words for my stuff" - to be honest, I'd be tempted to go with the latter of the 3 just because it's easier to sort the nodes alphabetically.

And while we're at it...

What exactly is the logix node that's literally just a triangle?

There are some nodes that are really difficult to give a name that makes almost everyone mostly happy.

By the way, finding a better name for that node is really difficult, and I'd love to see some good attempts at naming it such that people can actually know what it does.

Perhaps dy/dT. It might confuse less people - if you've done entry-level calculus, you should be able to recognise it. Although it may also be technically incorrect, but ∂y/∂T doesn't make anything better and tends to be more confusing... Then again, GLSL seemed happy with dFdx and dFdy despite it being an approximation... but this isn't a gradient, this is a straight-up delta and you have to divide it by dT to actually get anything resembling dy/dT.

Yeah, that's a really hard one actually.

[Banane9]

The hardest part (after the obvious bikeshedding of course, by the way I want it pink with bright green stripes) is working out how to sort things logically based on the combination of locale and notation-preference. In essence, you're going to have some sort of multi-dimensional locale scheme to make it happen.

I mean, the notation display should be local to a person, so they can get used to whatever order makes sense, or a fixed order based on the type names in code or whatever.