2
Show HN: Han – A Korean programming language written in Rust (github.com)
submitted 8 months ago by [B] to c/hackernews@lemmy.bestiver.se
1 comment fedilink hide all child comments
 

Comments

1 comment

sorted by: hot top controversial new old
[–] 2 points 8 months ago

https://en.wikipedia.org/wiki/Citrine_(programming_language) already allowed programming in Korean, ttbomk..

Which is good: the more the better, right?

_ /\ _

  • permalink
  • fedilink
  • source
    •
    7 comments in c/programming@programming.dev view that post
    [–] 8 points 8 months ago (5 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.

  • permalink
  • fedilink
  • source
  • hideshow 5 child comments
    •
  • [–] 4 points 8 months ago* (last edited 8 months ago) (4 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 8 months 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 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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 8 months ago (2 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 8 months 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.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 1 point 7 months ago

    I'm also a Swedish programming teacher, but I always tell my students to use English variable names. Irrational perhaps, but it just feels safer to avoid åäö. Even more so in file names, where it can make an actual difference if you move the file between different platforms. It's just safer to not form that habit to begin with.

  • permalink
  • fedilink
  • source
    •