Programming

26050 readers

66 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

GitHub - xodn348/han: A compiled programming language with Korean keywords, written in Rust (github.com)

submitted 11 hours ago by jeena@piefed.jeena.net to c/programming@programming.dev

6 comments fedilink hide all child comments

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.

top 6 comments

sorted by: hot top controversial new old

[–] TehPers@beehaw.org 6 points 11 hours ago (2 children)

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.

[–] Flipper@feddit.org 1 points 35 minutes ago

I mean, if you really want to use a different language, there are macros that enable that for you. Here is the example for Rost. Just Rust, but in German.

[–] ViatorOmnium@piefed.social 2 points 8 hours ago* (last edited 8 hours ago) (2 children)

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.

[–] TehPers@beehaw.org 1 points 3 hours ago

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 amd 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.

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.

[–] Jeffdude@piefed.social 1 points 8 hours ago (1 children)

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 1 points 7 hours ago

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.