In English (at least), the standard was always "/" in a list of options and such . . . IE, "pick one of this/that/those/these/something else" and now the younger crowd who were raised on M$ and ignored thier English classes tend to write that as this\that\those\these\somehing else. It's not a computer - it's incorrect.
We have a 1st level support guy at work who does this constantly. Example:
"Request 28630516, is this something we can create a Fischer resource to add\manage or do we just need to pass these over to be "licensed" accounts as previous requests?"
(I've even seen this crap showing up on street signs . . . . It comes across the same as the made up words is some ethnic dialects such as "aksed" instead of "asked", etc. . . )
I don't think there is much point in continuing the personal part of this discussion. You called my request ridiculous, made assumptions about how many RouterOS features I use, went through my profile, checked an unrelated old website and even wondered whether my profile was AI-generated or stolen. And somehow we ended up in a holy war about the characters. In my view, that clearly got you under the score
As for the actual topic, I did not avoid anyone's arguments. I read them and consolidated my view into one post instead of replying to every message separately. I think I explained there quite clearly how I got to my question and why I still think it is a valid architectural question.
What actually made it even more interesting to me, was looking more closely at interface lists. With include / exclude, I can already see the glimpse of a hierarchy, or even a graph of relationships between objects. That's exactly why I'm interested in where RouterOS could go with this concept, rather than just accepting the current design as the status quo.
I come from two ecosystems - DOS / Windows, as well as old Amiga, where OS architect created later the Rebol language, where syntax was constructed around small letters, slash and hyphens.
That is why I like Mikrotik argument syntax as well, but some of my IT colleagues hate-this-syntax-look. So YMMV. In my case, the _ used was delivered by one partner configuring MT and I was lazy to change it in multiple locations
You are contradicting yourself here. As you wrote, / in the language is for a list of alternatives (either/or) not for a parent-child hierarchy.
That Unix happened to use / as directory separator does not mean that it's the gold standard, and does not have any legitimacy coming from the English language like you wrote.
Actually, the more logical separator, and that was also one of the earliest used, would be >, that was used in Multics. Modern GUIs nowadays seem to go back to that Multics root and display > as separator in the path breadcrumbs.
The point was that M$ BS is tainting the English language, period.
The American Standards Association — predecessor to ANSI — issued X3.4-1963 — backslash character included — a dozen years before Gates & Allen dropped out of college. That glyph was also present in the second major version of that standard, X3.4-1968, by which point the institute had renamed itself the USA Standards Association, which is why the code had the name USASCII for a time.
1968 was not only long before the founding of "M$", it was the year of the famous rummage sale whose proceeds funded the purchase of a Teletype ASR-33 for Bill Gates' private high school, plus remote access to a GE mainframe, which helped put Bill on that path. The ASR-33 was one of the early hardware implementations of ASCII, making it one of the drivers of the standard's success; fixing the mess of teleprinter incompatibilities was one of the things the standard was meant to accomplish.
You must really have some issues if you keep insisting on this...
Is there anything else missing from the list of things you blame me for?
People don't dwell on ridiculous things, like giving lists and interfaces the same names,
they talk about other things instead, seeing as it's a forum.
How come you aren't complaining to the others for going off-topic?
In any case, it doesn't matter where it comes from,
it originated as a mathematical\technical typeface, and for everyday writing... it makes no sense...
I don't dwell on rudiculous topics, because it is not about the identical names, but about overal object architecture of the system, and I think I have already tried to explain my points. naively thinking it might start the discussion about grouping things, e.g. MT lacking port-list etc., as that feature was already requested in the past.
And as for ppl going off-topic? Yes, I think, that this thread could be entirely deleted, but I can give you a credit here at least - your reply with the image of a machine from 1930 with backslash is the best post about all those \-_/ chars and standards discussions so far
Because we've known that for you Linux is the Holy grail and "Winduh" is always "sh.t" and \ is prominently used by Windows as path separator. I just wanted to show that that choice is not worse than the / character that Unix (and thus Linux) picked.
There's an ancient Latvian saying:
"If you name the river and the bridge by the same word, the spirits of the Baltic will forget which way the water flows."
While that may be true The point was that so many are so "Windoctrinated" that it is creeping into utterly unrelated things in day to day life. (Despite seeing that the char IS older, I think today the origin of the "leakage" is pretty hard to deny, esp. when you hear some of the same folks call "/" backslash . . . .
My guess is that it has more to do with ease of implementaion and support of users that in general don't read documentation. There are probably ways that could be designed to allow a use to force the use of an interface if the interface-list took precidence.
But MikroTIk ROS is already so flexible that it provides many ways to shoot yourself in the foot. So I can understand why not allowing interface-list and interface names use the same name was considered as a better alternative to than providing methods to override the precidence.
Flexible but complex can be very useful, but also very confusing for "casual" users. An example from another product (OpenVMS aka VAX/VMS) was logical names. These were tightly integrated into the OpenVMS file system, and users could open a file using a name "FOOBAR". If there was a logical name FOOBAR, then it would be used, and it may specify a filespec on another device and directory with a totally unrelated name, e.g. USER.DAT, other wise the it would be used as the filename, (and other applied defaults). For people that read the documentation, it was a very useful feature, but I knew many application programmers that never really understood how logical names worked, even though they had used VMS for over 20 years (and should have mastered something as fundamental as logical names are in VMS if they were applications programmers). But for a casual user the didn't know about a system wide logical FOOBAR, it could be extremely confusing when the file FUBAR was not used in their default directory.
So not allowing the same name to be used for both interfaces and interface lists probably is more of an pragmatic descision than a technical one. But it does make it much easier to search the exported config for a name and now what it is referring to.
ROS does allow you to name a bridge device "bridge" (and defconf does that itself), and even that may be confusing to someone learning ROS. If even allows you to name the bridge device "ether6" as long as there isn't an existing interface with that name.
typeface, and for everyday writing... it makes no sense...
