I might quote you on this if I have to explain it to others.
> if you're finding yourself tempted by ed you should probably try sam instead
Ty, I may try it then.
> i don't understand the nature of hedy but it sounds like just another scripting language; what would make it especially difficult or costly to implement? i don't understand what you mean by 'user-localizable' or 'more overtly'
The language drop-down on the editor / try-it page translates not just page text, but the scripting language keywords itself. I haven't had time to dig into it yet, but it's inherently an internationally oriented scripting language by design since the goal is to allow adding your own language to the supported set of keyword display languages.
I do not think that it should be necessary to make the keywords in the programming language to be languages other than American English, and I also do not think that it should be necessary for musical notation to be in languages other than Italian.
(I do not speak Italian, but that does not mean that I cannot play piano or that I cannot write music. I speak Canadian rather than American, but that does not mean that I cannot program a computer.)
But if people want to use languages other than English for computers and Italian for music, they can do that if they want to (and some people do); this is not an intention to prevent people to do such a thing if they want to do, just to say that I think it is unnecessary, and why I think it is probably better not to do.
However, documentation, comments, etc, can be in any languages you want to do, and documentation should be available in many languages in order to make it understandable by many people.
Using different languages in the program itself (or in music, etc) can make it more difficult to understand and to find information; but making the documentation in many languages makes it easier; you can read documentation in the language you undertsand and can then understand a program even if it is English, that you might not have written by yourself. So, I think this way is more useful.
i see. visual basic did that too; while i'm sympathetic to complaints of cultural imperialism, i'm not sure that having your keywords in a foreign language such as english is actually worse than being cut off from the international community of other programmers in your language so that you can't find answers with a full-text search engine. but there's an enormous space of possible programming language designs that haven't really been tried
TL;DR: My concerns are more directly practical ones about approaches (formal and humor-based) to overcoming language barriers between devs across language families
> visual basic did that too
I haven't seen this on recent versions. An old MS support thread[1] suggests VB's editor has been English-only for the past decade-ish. Do you remember whether it's a built-in feature or an add-on? For example, did it get handled by replacing text, or storing ASTs of built-ins and remapping the display name? I'm not seeing much in search results.
I also haven't had time for an in-depth look at how Hedy handles their translation, but they do use Weblate to manage everything[2]. Their keywords page even has percentages for partial languages[3]. For Microsoft or whoever added a simliar feature to VB, I'd be surprised if they didn't have a way to do your own customization for an organization.
> while i'm sympathetic to complaints of cultural imperialism
My concerns are much more practical. Collaboration across language barriers:
* is fairly easy when the devs are all familiar with the same writing systems
* can become mutually frustrating across writing system families, especially between Latin-derived and logographic[4] CJK[5] systems
My best example involves attempting to discuss the same differences across the same writing system gap. I had to do some careful reading to make any sense of things. However, it led to some immediately useful conclusions about glyph cache and texture atlas / sprite sheet issues for everyone involved.
Fun fact: limited space in rewritable text editing tools may go back at least as far as the Romans.
However, de novo writing writing systems seem to have very few enduring examples. As far as I know, Korean Hangul[6] seems to be the oldest and it still experienced significant hurdles for hundreds of years.
Part of it seems to be that symbol systems tend to be domain-specific if they even have grammar, let alone executable properties. For example:
* Extensions to flowchart concepts such as Drakon[7]
* Toys such as Scratch[8], LEGO's old MindStorms environment, etc
* Non-executable domain-specific markup (7 Wonders[9] and other card / board games)
This goes all the way back to the Sumerians. Although we no longer use symbols primarily as primarily a means of agricultural contract record keeping, we did some of their timekeeping conventions. Our mathematical notation is better as I understand it, but still awful and inconsistent from an outsider's perspective.
That last point got me thinking. Diagramming and working demos both help with graphics, games, and geometry questions. The first two also seem to be specific cases of the third, which is a human interest predating digital or mechanical computers.
However, low-power or emulator developer communication seems to tend toward the following instead of clay cylinders or tablets:
* Non-freeform monospace text and text boxes (although the Left editor has both nice font support and syntax editing now, thank you for updating me on that)
* Audio calls or screen sharing text boxes or GUIs (more text and symbols)
Aside from inventing conlangs[10], we don't really invent new human languages, nor do we apply them at project scale. Instead, we seem to tend to come up with neologisms and project-specific slang.
Is this a feature or a bug? I see two extremes with regard to bridging grammatical structure and writing system gaps:
1. Reject: attempt to formalize how Esperanto did (or the way you said VB did)
2. Embrace: encourage and combine it with the following:
* The way Forths tend toward being a family of dialects, each specific to an ISA or machine
* Naturally emerging labels and slang
The second direction seems easier.
To me, Python seems to have "regional" dialects specific to industries or codebase purposes. It's not a standard, but an emergent thing the same way I've heard Newgrounds[11] projects had a reputation for offensive variable names.
Python had humor once too. Unlike Newgrounds Python's humor was Monty Python references in example code instead of choosing variable names based on shock value. Also, Python seems to have lost the humor as it "grew up"
It seems like this sense of humor is important to early-phase software and hardware ecosystems. For example, the Uxn / Varvara ecosystem we've been discussing has plenty of it. Potato[12] isn't quite a joke with a punchline, but it is an irreverent reference to low-power computers with "bad" graphics.
Community coherence is something Octo had issues with, but both Uxn and Decker seem to be doing well. My guess is humor as a key factor.
Do you have any thoughts on this and other parts of community building or emergence?
* In your specific area(s) of interest? (low-power, long-term hardware)?
* For retro languages+hardware?
* In general?
I also realize I might be bringing way too much process and theory into this. Do you still use the email listen on your about page?
It'd be nice to have a fallback in case this thread locks or something. It's been rare to have such long-lasting discussions, so I don't remember how thread locking works on this site.
so, the translated visual basic thing is a thing i remember hearing about vba in the 90s, without any personal experience. but if memory serves (and i'm not just confabulating the whole thing) it was built-in, not an add-on
i think it's reasonable to describe graphical notations such as drakon as having a grammar. you have some finite set of atomic features (often things like shapes or arrows, but sometimes other characteristics such as size, orientation, and color) which are combined in some finite set of ways to produce an infinite set of possible 'sentences'. the only non-grammatical aspect of this is that some of these features are used in an analog way, for example with a length proportional to a time lapse or an orientation that indicates a cardinal direction, while verbal features are strictly digital and arbitrary—but we often use similar paralinguistic features in speech and especially in sign language
I might quote you on this if I have to explain it to others.
> if you're finding yourself tempted by ed you should probably try sam instead
Ty, I may try it then.
> i don't understand the nature of hedy but it sounds like just another scripting language; what would make it especially difficult or costly to implement? i don't understand what you mean by 'user-localizable' or 'more overtly'
The language drop-down on the editor / try-it page translates not just page text, but the scripting language keywords itself. I haven't had time to dig into it yet, but it's inherently an internationally oriented scripting language by design since the goal is to allow adding your own language to the supported set of keyword display languages.