Draig, a Welsh Programming Language(raku.land)
raku.land
Draig, a Welsh Programming Language
https://raku.land/zef:l10n/L10N::CY
45 comments
This is a nice idea but while the home page was correctly localized in French as my browser is, I couldn't find a way to see "teaching" or "learning" parts of the website in French. At least on mobile, there's no way to tell the site to change language, and it doesn't properly do that on its own based on the browser's preferences. This defeats the whole idea…
If the author is reading this: one of the code examples says "use L10N::NL" but I think it should be CY :)
Can't wait for a Raku implementation of Lingua::Romana::Perligata.
Nothing stopping you from creating a L10N::LA module :-)
Richard (the dev) has wrote a good "how to" post on the creation process
https://dev.to/finanalyst/creating-a-new-programming-languag...
https://dev.to/finanalyst/creating-a-new-programming-languag...
Question: is it a good idea to introduce kids to coding in their mother tongue like this?
It's already been linked in comments here but there's been a bit of exploration in that area with Hedy. There's some good references to prior work and comments of relevance in this paper https://hedy.org/research/A_Framework_for_the_Localization_o....
i've always given the advice "program in english, comments, variables, function names, everything", and "always use a uk/us keyboard unless you absolutely have to enter localised strings, and even better get someone else to do that"
I've been working with a codebase for a very specific domain where hardly anyone even knew the English terms for the domain-specific things (and some of them probably didn't even exist - highly localized customs etc.). No point in using English then.
I’ve seen before that this is not followed in certain cases, such as the entire development team being in a specific country where some or many team members don’t know English (well enough). As an anecdote, I’ve seen a team in a large multinational company (US origin) in Spain that used function names, variable names, database table names (and column names), log message text and many other things in Spanish. English was only for the language keywords because that’s what the compiler would accept.
The smart projects that are going for L10N will collect all the UI strings into a file or set of files, separate from the code, and indexed so that the app can just switch language and then begin using a new set of localized strings. This also makes for easy translation where you don't need to rebuild the app, just expand the data files that it's using. Is this not the only way to build apps today, or are "localized strings" still being hardcoded??
Draig is built on L10N and code can be passed to/from Welsh <=> Other (eg English) … the keywords are translated back and forth, but comments and identifiers are whatever the coder writes.
China disregards that and there is an absolutely massive ecosystem of Free and Open Source Software out there if you can read and write their code.
I know little about china (except i like the food and art) but do they actually write code in their native language(s)?!
I can only speak for Japan, but I suspect China is the same. In Japan, English programming is the norm because all mainstream programming languages are written in English. Keywords, libraries and documentation are in English, so there's not really any getting around the fact that you have to learn to read at least some English. Some Japanese developers do write identifiers in Japanese where languages support it, and documentation / comments are often written in Japanese, of course.
I, personally, think this is a lamentable state of affairs that raises the barrier to entry for programming, especially for children. There are education-oriented Japanese programming languages that try to fill the niche for teaching children, but I think it would be beneficial if there were serious languages with a full ecosystem rather than ones designed to be training wheels before learning English programming languages.
I, personally, think this is a lamentable state of affairs that raises the barrier to entry for programming, especially for children. There are education-oriented Japanese programming languages that try to fill the niche for teaching children, but I think it would be beneficial if there were serious languages with a full ecosystem rather than ones designed to be training wheels before learning English programming languages.
how about https://raku.land/zef:l10n/L10N::JA ?
Why not use a pre-processor or something like it to simply translate the keywords etc? I know that there isn’t a 1:1 match between English words and words in other languages, but you should be able to get something close enough.
I actually have done that, but there are still problems. It doesn't really do anything to help somebody who can't read English because things like error messages and libraries are still in English, and it doesn't play nicely with IDE tooling, which is fixable in open-source editors but not proprietary editors. It ends up being a lot of effort for an experience that feels very much second-class.
The first STM32 "bluepill"-based SCSI to SD adaptor I ever used had all its source code in Chinese.
Google Translate did a not terrible job of turning all the comments into English but also mangled the code in exciting new ways, but with a bit of ingenuity to apply the Artificial Intelligence translations, and a bit of bloodymindedness when applying the Analogue Idiocy to hacking it all about with search-and-replace, I got a pretty plausible translation of it.
Google Translate did a not terrible job of turning all the comments into English but also mangled the code in exciting new ways, but with a bit of ingenuity to apply the Artificial Intelligence translations, and a bit of bloodymindedness when applying the Analogue Idiocy to hacking it all about with search-and-replace, I got a pretty plausible translation of it.
Nope, they just add huge Chinese comments.
As someone who's spoken English since 5, I'm perplexed by this question. I'm genuinely unfamiliar with any perceived downsides and I would love to hear more of your thoughts
No. You want 'for' to be a looping construct with no other meanings.
Seeing code in my native language makes me laugh, I can't take it seriously.
Seeing code in my native language makes me laugh, I can't take it seriously.
I strongly disagree. Take, for example...
foreach (apple in fruitbasket)
apple.Eat()
for (int i = 0; while i < fruitbasket.Count; i++)
fruitbasket[i].Eat();
Coming soon to a programming ecosystem near you:
LLM(eat apples in fruitbasket)
vs
foreach (apple in fruitbasket) apple.Eat()
Your comment can be repeated almost word for word here.
LLM(eat apples in fruitbasket)
vs
foreach (apple in fruitbasket) apple.Eat()
Your comment can be repeated almost word for word here.
Not at all. I'm comparing two different syntaxes that can reliably compile to the same machine code. A syntax that produces non-deterministic results is a completely different matter.
> non-deterministic
You can control the amount of non determinism.
And also, it is interesting that you think modern compilers are deterministic.
You can control the amount of non determinism.
And also, it is interesting that you think modern compilers are deterministic.
While an LLM with a fixed seed is technically deterministic, it’s still unpredictable.
> And also, it is interesting that you think modern compilers are deterministic.
A compiler, unless it has a bug, will always produce output matching the specification of the language.
> And also, it is interesting that you think modern compilers are deterministic.
A compiler, unless it has a bug, will always produce output matching the specification of the language.
> the specification of the language
Guess what language the specification is written in (if it exists at all) ?
It's usually natural language, and even then, compilers deviate from the specification all the time, and the specification has bugs.
Formal specifications are a thing, but the science is nowhere mature enough to dictate what compilers do.
> unless it has a bug
Compilers are not magic, the way it follows specifications is up to the interpretation of compiler developers like yours truly. And there are tens of thousands of compiler bugs. There was a notorious LLVM pass that had more bugs than lines of code ;)
https://github.com/llvm/llvm-project/issues?q=is%3Aissue
This is a list for just the last few years after LLVM switched to the using github for tracking issues.
Guess what language the specification is written in (if it exists at all) ?
It's usually natural language, and even then, compilers deviate from the specification all the time, and the specification has bugs.
Formal specifications are a thing, but the science is nowhere mature enough to dictate what compilers do.
> unless it has a bug
Compilers are not magic, the way it follows specifications is up to the interpretation of compiler developers like yours truly. And there are tens of thousands of compiler bugs. There was a notorious LLVM pass that had more bugs than lines of code ;)
https://github.com/llvm/llvm-project/issues?q=is%3Aissue
This is a list for just the last few years after LLVM switched to the using github for tracking issues.
Please do not engage in bad-faith arguments centered around pedantry. You know very well what I mean.
I know what you mean, and it was correct a year or more ago. Now, you are wrong.
AI is reliable enough to not mess up this translation now, especially if you configure it right (top p, and temperature parameters).
This abstraction lifting is absolutely happening in front of our eyes now. For the exact same reason the C for loop is less readable.
The different is that you don't yet store the prompts, just the generated code. That difference is not going to last too long. Storing prompts and contexts along with generated code is likely how we are going to be doing software engineering for a few decades before whatever the next leap in technology works out to be.
AI is reliable enough to not mess up this translation now, especially if you configure it right (top p, and temperature parameters).
This abstraction lifting is absolutely happening in front of our eyes now. For the exact same reason the C for loop is less readable.
The different is that you don't yet store the prompts, just the generated code. That difference is not going to last too long. Storing prompts and contexts along with generated code is likely how we are going to be doing software engineering for a few decades before whatever the next leap in technology works out to be.
You could just lock the seed to get "deterministic" behaviour, but you are missing the point of programming languages completely. Programming languages are a set of rules that ~guarantee predictable behaviour down to the bit level. If you were to try to recreate that with LLMs, you run into two problems: one, your LLM is now a programming language where you have to put exact specific inputs in to get the correct outputs, except you don't have a specification for the inputs and you don't know what the correct outputs even look like because you aren't a software engineer. Two, even with a locked seed, the LLM is still going to output different code based on the exact order of letters in your prompt and any change in that will change the output. Compilers can execute a variety of optimizations on your code that change the output, but in the end they are still bound to hard rules and you can learn the rules when you get output that does not match what your expectations were from the input. And if there is a bug in the execution of the rules by the compiler, you can fix it; that is not possible with an LLM.
This talk about replacing software engineering by people who have no idea what software engineering is gets unbelievably tedious. The advent of Javascript did nothing to replace software engineers, it just created an entirely new class of developer. It lowered the barrier to entry and allowed anybody to write inefficient, bloated, buggy, and insecure programs. Our hardware is advanced enough that for many trivial applications there is sufficient overhead for inefficient and bloated programs to exist and be "good enough" (although they are causing untold damage in the real world with security breach after security breach). However, lowering the barrier to entry does not replace the existing engineers. You still need a real software engineer to develop novel applications that use the hardware efficiently. The Duchies of Javascript and Python are simply a new country founded adjacent to, and depending upon, the Software Engineer Kingdom. Now a new duchy is being founded, one that lowers the barrier to entry further to make even more inefficient, even more bloated, even more buggy, and even more insecure programs easier than ever. For some use cases, these programs will be good enough. But they will never replace the use cases that require serious engineering, just as Javascript never did.
This talk about replacing software engineering by people who have no idea what software engineering is gets unbelievably tedious. The advent of Javascript did nothing to replace software engineers, it just created an entirely new class of developer. It lowered the barrier to entry and allowed anybody to write inefficient, bloated, buggy, and insecure programs. Our hardware is advanced enough that for many trivial applications there is sufficient overhead for inefficient and bloated programs to exist and be "good enough" (although they are causing untold damage in the real world with security breach after security breach). However, lowering the barrier to entry does not replace the existing engineers. You still need a real software engineer to develop novel applications that use the hardware efficiently. The Duchies of Javascript and Python are simply a new country founded adjacent to, and depending upon, the Software Engineer Kingdom. Now a new duchy is being founded, one that lowers the barrier to entry further to make even more inefficient, even more bloated, even more buggy, and even more insecure programs easier than ever. For some use cases, these programs will be good enough. But they will never replace the use cases that require serious engineering, just as Javascript never did.
> Programming languages are a set of rules that ~guarantee predictable behaviour down to the bit level.
No, that’s your interpretation of what a programming language is, based on nostalgia and wishful thinking.
If you get a programming system that sacrifices these and works better, people are going to use those.
FYI I am a compiler developer who has contributed to about three widely used compilers, I assure you I understand what programming languages and compilers are.
No, that’s your interpretation of what a programming language is, based on nostalgia and wishful thinking.
If you get a programming system that sacrifices these and works better, people are going to use those.
FYI I am a compiler developer who has contributed to about three widely used compilers, I assure you I understand what programming languages and compilers are.
> If you get a programming system that sacrifices these and works better, people are going to use those.
Sure. That's a very large "if", though, one that evaluates to false and will continue evaluating to false for the foreseeable future. I am told over and over that I am being replaced and yet I have not seen one singular example of a real-world application of vibe coding that replaces existing software engineering. For starters, where is the vibe-coded replacement for Clang? For Linux? For IDEs? For browsers? I don't mean a concept of an idea of a browser, of course. To make the claim that the new programming system works better than the old system, it must produce something that is actually superior to what people currently use. LLMs are clearly completely and totally incapable of this. What they are capable of is making inferior software with a lower barrier to entry. Superior software is completely off the table, and it is why we don't see any existing software being replaced at scale, even though existing software absolutely has flaws and room for improvement that a "better programming system" would be able to seize upon if it existed.
That you can confidently assert that I am wrong, while having zero real-world evidence of superior software engineering produced by the new system, is indicative of a certain level of cultish thinking that is overtaking the world. Over and over and over again, people keep making these grand claims promising the world is changed, and yet there is no tangible presence of this in reality. You simply demand belief that it will change, as though LLMs are a new religion.
Sure. That's a very large "if", though, one that evaluates to false and will continue evaluating to false for the foreseeable future. I am told over and over that I am being replaced and yet I have not seen one singular example of a real-world application of vibe coding that replaces existing software engineering. For starters, where is the vibe-coded replacement for Clang? For Linux? For IDEs? For browsers? I don't mean a concept of an idea of a browser, of course. To make the claim that the new programming system works better than the old system, it must produce something that is actually superior to what people currently use. LLMs are clearly completely and totally incapable of this. What they are capable of is making inferior software with a lower barrier to entry. Superior software is completely off the table, and it is why we don't see any existing software being replaced at scale, even though existing software absolutely has flaws and room for improvement that a "better programming system" would be able to seize upon if it existed.
That you can confidently assert that I am wrong, while having zero real-world evidence of superior software engineering produced by the new system, is indicative of a certain level of cultish thinking that is overtaking the world. Over and over and over again, people keep making these grand claims promising the world is changed, and yet there is no tangible presence of this in reality. You simply demand belief that it will change, as though LLMs are a new religion.
You are wrong about modern AI not being able to produce deterministic output for the for loop we are talking about.
You are right about modern AI producing superior software engineering.
You should read the chain of comments again and try to understand the non deterministic leaps of logic you have made :)
You are right about modern AI producing superior software engineering.
You should read the chain of comments again and try to understand the non deterministic leaps of logic you have made :)
I was hoping some people would mention other interesting programming languages in this thread, with links.
Da iawn!
whenever you would use 'l', you have to use 'll'?
i'llll get my coat
i'llll get my coat
I know it’s just a joke but the “ll” in Welsh is a completely distinct character in the Welsh alphabet and doesn’t sound anything like “l”, nor is it used as a substitute for l. It’s rarely used but it has its own Middle-Welsh character: ỻ
https://en.wikipedia.org/wiki/Ll
https://en.wikipedia.org/wiki/Ll
> I know it’s just a joke
Yeah, sorry, I couldn't resist. I'm not Welsh but I lived there when I was a small child, and happily holidayed there after. It is a great country.
Yeah, sorry, I couldn't resist. I'm not Welsh but I lived there when I was a small child, and happily holidayed there after. It is a great country.
[deleted]
429 - Too many requests
[0] https://www.hedy.org/