GitHub - xodn348/han: A compiled programming language with Korean keywords, written in Rust (github.com)
from jeena@piefed.jeena.net to programming@programming.dev on 15 Mar 11:46
https://piefed.jeena.net/c/programming/p/344342/github-xodn348-han-a-compiled-programming-language-with-korean-keywords-written-in-r

A compiled programming language with Korean keywuords, written in Rust - xodn348/han

I remember our professor at university (Gothenburg, Sweden) was teaching us object oriented programming and her example code had variable names and method names in Swedish because Java could deal with utf8 already beck then in 2008.

We were trying to convince one of the Arabic students to send in his stuff in Arabic, but he was too afraid.

#programming

threaded - newest

TehPers@beehaw.org on 15 Mar 11:56 collapse

This might seem like an obvious question, but wouldn’t it be more effective for the README to be in Korean? Not that having it in English too is a bad thing, but people interested in a language with Korean keywords probably can read Korean more comfortably than English (if they can read English at all).

Anyway, I don’t really see why PLs that support UTF-8 idents can’t just reserve multiple aliases in different languages for their keywords. Rust is mentioned here, so I’ll use that as an example, but Rust could just add a language field to Cargo.toml next to edition that defaults to English (which is what Rust currently uses), and that wouldn’t even need a new edition as far as I’m aware. C# could do a field in the csproj file, C and C++ can use compiler flags, and so on.

ViatorOmnium@piefed.social on 15 Mar 14:52 collapse

What happens when you import an library written in another language, and one of the functions is a reserved keyword in your language? How would collaboration between people with different native languages work? Who makes sure all language variant have equally good educational resources?

There’s a reason why lingua francas change over time but always exist, and forgetting that will do more harm than good.

Jeffdude@piefed.social on 15 Mar 15:00 next collapse

I don’t see why compilers/IDEs couldn’t handle translated keywords the same way we do internationalization everywhere. Have a ‘key’ value that is the actual keyword, and translate it in the IDE only when the user is viewing the file. Otherwise, the key is universal and can be compiled by anything.

I’m actually disappointed it’s not already a thing in new PLs. Open source needs less barriers to entry, not more.

ViatorOmnium@piefed.social on 15 Mar 15:11 next collapse

The barrier to entry, or at least to proficiency is access to educational material and community. i.e. currently the necessary skill is to at least understand English. Adding an incredible amount of complexity to understand when something is a keyword or not, depending on the combination between any number of hundreds of natural languages, and worse live-translating keywords without ever messing up functions, variables, and methods is not going to make it better - if it did everyone would using visual programming languages.

Programming languages with different natural language keywords are useful learning tools, but they are basically training wheels on a bike, they need to come out at some point for someone to be good at it.

_Lory98_@discuss.tchncs.de on 15 Mar 15:50 collapse

Excel does it for its formulas. It ends up being just a pain in the ass when you are looking online for info (which means it ends up increasing the barrier of entry, as most stuff online is in English).

TehPers@beehaw.org on 15 Mar 19:43 collapse

What happens when you import an library written in another language, and one of the functions is a reserved keyword in your language?

This is already possible in Rust. You can import libraries written with different editions, and there are different reserved keywords across editions.

The compiler just looks at what language the library was written in and switches internally based on that.

In my C and C++ example, you’d pass different flags for that library during build time, although I’m not sure how this would work for header-only libraries.

Edit: I see your reserved keywords example is an issue, and I raise you raw identifiers (r#if in Rust, @if in C#, etc)

How would collaboration between people with different native languages work?

Same way it currently does? It’s not like everyone who writes code knows English, but somehow they can all write it despite the keywords being in English.

Who makes sure all language variant have equally good educational resources?

The community around that programming language would be responsible for this, would it not? This is already a thing people do, though it’s impossible to translate all educational resources that exist into all languages. Fortunately we have services that can translate things for us though.

There’s a reason why lingua francas change over time but always exist, and forgetting that will do more harm than good.

It would do no harm here. People already write code in many languages. In most popular programming languages, you can already name things in Korean, French, Russian, and so on. Documentation for the languages exist already in all those languages. There is literally only one thing that would change: the keywords. It’s really not that complicated.