I know it takes advantage of some technicalities (end-of-input separators and such), but it's still a remarkably impressive piece of engineering. I put that up there with some really hairy quines (https://github.com/mame/quine-relay), except it can actually be useful!
I'm counting different editions of POSIX-compliant shell languages (e.g. ksh93, zsh, bash, [t]csh) as different, as well as massively different editions of DOS (freeDOS, MSDOS).
Hence the approximating tilde on "~12". Reasonable minds may consider there to be many fewer, or many more, compatible interpreters.
EDIT: There also appear to be multiple compatible JavaScript interpreters--browser V8 (though not Node, oddly--it's detected as generic; I may send a PR sometime), SpiderMonkey, and older IE. I'm no expert on JS runtimes, though, so the differing results I'm observing may be due to something else.
"OneLang is the love child of @koczkatamas and it was not a planned child. ....
OneLang is six months old at the time of writing and it already speaks, but don't expect any comfortable conversation with it yet. It cannot grow without a loving family, and as a single dad I cannot take care of it alone. It needs more mommies and daddies who can help raise it up."
indeed, I like your project. Negativity of the community can be discouraging. I stopped a project of mine because of a combination of the negativity and from the reality of having to hiring and train people to use my language.
/r/programming is one of the most pedantic forum I have ever seen but I also see it as a place where programmers flee and shelter from the non-technical bullshit and vent a bit.
If you submit anything there, be prepared for harsh criticism. There is some real value in there, but encouragement and cheerings won't come from there.
My experience is that there is a lot of toxicity on the internet, but also outside of it. I'm disappointed by how toxic, money-obsessed, and ignorant many people are. On the internet, all that is concentrated and delivered straight to your face.
I would recommend presenting projects first in person to people before putting them on the internet for debate.
Imagine how it must be for the people behind Rust. Yet, people from the team regularly show up, are polite and nice and are open to arguments in spite of all the negativity they surely face. I think it is easy to become bitter, suspicious, and unfriendly when faced with social pressure, but they seem to continuously find the arguments in even not so polite comments and patiently give good insights and own arguments.
I intend to write about this, and this is a reason I am keeping some of my personal projects less open source and invite very few people in that I can mentor.
I think it is a shame that the default tends to be negative comments rather than constructive, but I also recognized that giving into toxic emotions is easy.
It seems like a really strange choice for the "source" language to be JS - a language without any real static typing capability (even with TS).
The most limited & basic kinds of static analysis are technically possible, but why not just start with an entirely static language and translate from that to dynamic languages? Would seem much simpler...
> It seems like a really strange choice for the "source" language to be JS
I can't speak for the author, but I can think of several reasons I might choose JS:
1. Almost everyone working on the web knows it, so not knowing the source language won't be a roadblock right away.
2. Precisely because of the issues you mentioned, JS is a lot easier to translate with perfect (or close to perfect) fidelity. If the source were something like Haskell, every translation would be very lossy.
3. JS has no boilerplate, like setting up a class or something. You can just type statements.
4. OneLang itself is written in TS, which means working with JS as the source might be easier than, say, C#.
> 2. Precisely because of the issues you mentioned, JS is a lot easier to translate with perfect (or close to perfect) fidelity. If the source were something like Haskell, every translation would be very lossy.
On the contrary, the fewer restrictions a language has, the more difficult it becomes to translate it into languages with stricter requirements. If this were built on JavaScript and not TypeScript, it couldn't even generate the correct type annotations for the other languages that require them. I doubt that this project is going to grow a Haskell backend anytime soon.
That would fail to compile in TypeScript as well, and you should get a red squiggly or other syntax error indication in most IDEs. Math.random() takes no parameters.
From lib.d.ts:
interface Math {
// ...
/** Returns a pseudorandom number between 0 and 1. */
random(): number;
// ...
}
I am probably not emphasizing this enough, but One is currently a "toolkit" for converting syntax between languages.
`Math.random()` is ~a standard library function. One has limited knowledge about language's StdLibs. But you can make `Math.random` (or any method) work without modifying the compiler, only by adding the appropriate implementation and StdLib definitions to appropriate files. (Even now only using the WebIDE).
The plan is to make One plugin-able and create a "package" manager infrastructure, so anybody can implement `Math.random()` or any other methods, publish it and then you can just download that package.
Implementing every language's StdLib is not a one-man job, so I've always considered this out-of-scope.
Sorry if any published information regarding this was misleading.
Oh, ok I think I understand it better. That sounds like a really useful tool. Actually in a project I was in last year we really hesitated between writing a lib in C++, C# or Java (Native android, Unity3D lib, Android java) and had good arguments for either but no budget for maintaining all three.
I would have seriously considered your option at the time.
I have no time to dive into this now but I'll bookmark it and come to wave at your gitter.
Is it realistic to contribute to it with knowledge of C++/C#/Java/Python but a pretty poor grasp of JS?
For anyone interested in cross platform development, check out Haxe and its testing process. Writing a target that passes those tests is like finishing Dark Souls. The level of effort here is about on par with finishing the character selection screen.
Programming language translation has to be on the horizon. The cost of switching is currently too high.
I got into a project years ago with this ambition using an AST and allowing each language to provide their own translation for each syntax element or block of code.
It also had the unique benefit of being able to take larger blocks like a function and allowing the translator to provide a full function in some native programming language so that a login or Fibonacci function could have multiple translations in the same language allowing the translation to evolve and adapt to use the most efficient one as new translations were introduced.
In the demo video (https://youtu.be/Rwo6KJ_Pa9Q) there is a part where I am editing the same code in 4 languages (C#, TypeScript, Ruby and PHP) simultaneously.
But yeah, generally only a limited subset of a language is supported. This is the price of writing code targeting multiple language. That's why you cannot (and probably won't be able to) convert existing code.
Hey I'm curious about your journey than the final result. I only skimmed through the code, so I don't understand everything, but it seems that the list of things it will identify is in the "yaml" files. Did you write out all of them or was there a pre-existing database somewhere?
Tl;dr: you cannot use One in production now, but the grand plan is to make One as hackable and flexible as I can.
So here is the plan:
- the compiler does not contain any target language-specific part, you can add a new language by creating a few hundred lines of template file (this actually works already, it is not just a plan)
- rewrite One in One, so you can convert from any language to any language in any language
- there is no StdLib, but libraries can be created by anyone. We publish interface and implementation definition separately, and you can eg. implement a Web client interface for PHP and Node, while somebody else can implement it for C# and Swift. Behaviour defined by interface tests, if your implementation passes interface test => good. If there is no test for an edge-case => undefined behaviour. Read more here: https://github.com/koczkatamas/onelang/issues/9
- you write a library in One and it helps you to publish to every language's package manager (npm, pip, NuGet, etc). You can reach much more developer with your library compared to targeting only one lang's developer base
This idea has been ronning around in my head, paired with a mining and crypto element.
The language specific implementations of those interfaces could be mined(by hand or automated) for coins to directly incentivise engineering effort. The block acceptance would be based on the universal tests/benchmarks passing.
Try writing "let i = 1". I think the assumption is that if you use undeclared identifiers, you'll provide them to the generated code in some other way.
For some reason, the first time I looked at Haxe I got the impression that Haxe is an open-source Flash / Flash successor. (Mostly, I think, because Flash keeps getting mentioned with projects associated with Haxe, like OpenFL and Flambe, and several times in the Haxe Wikipedia article).
Clearly Haxe isn't "just" an open Flash, but how is Haxe related to Flash?
Haxe is a programming language and should be compared to as3. It is much more powerful and can compile to 12 targets including JavaScript,php, c++, and as3.
OpenFL is a cross-plateform port of the flash API in Haxe.
All this flash stuff are just a part of an amazing technology.
I realize it's sometimes not considered cool to point out competing projects, but the OneLang project FAQ explicitly says that it's a proof of concept, not ready for production use, with no documentation, and may never be finished.
OneLang does seem like a nifty project, but given its current state, it seems pretty reasonable to point toward Haxe for anyone interested in something similar that has been around for years, well documented, and used in production by many teams.
How so? Haxe is the de facto king of the compile-to-everything space. Therefore, it's inevitable that Haxe will be mentioned on a submission like this.
> Truffle is a framework for writing interpreters with annotations and small bits of extra code in them which, when Truffle is paired with its sister project Graal, allow those interpreters to be converted into JIT compiling VMs … automatically.
> If Truffle is a framework for writing AST interpreters, then Graal is the thing that makes them fast.
> Truffle provides a language interop framework called Polyglot that allows Truffle languages to call each other
> Haxe is the de facto king of the compile-to-everything space.
Indeed, I remember stumbling across it years ago while looking for a way to develop Flash games without Adobe Flash Professional. I never got around to actually try it but I keep seeing it every now and then, even saw a couple of books about it in a physical bookstore some years ago. It was the first thing that popped to mind for me as well when I saw that OP title mentioned write code in multiple languages at the same time.
Opening the site on my 3GB RAM laptop froze it - could you please not pile web frameworks atop one another?
Being able to translate between languages in all cases is intrinsically impossible because of the halting problem; that this works is a testament to how restrictive and bland the Von Neumann language paradigm is, seeing as these languages aren't terribly different and all have ridiculously long specs.
The closest you could get to doing this for most languages would be to specify sets of composable, first-class macros in a purpose-written Lisp (almost certainly a Scheme derivative) and write FFIs to port in standard libraries around the core languages made from macros.
The halting problem has nothing to say against translating between languages. A non-terminating program will simply be translated into another non-terminating program. In fact, Turing completeness is all about the fact that a program in any language can be translated into an equivalent program in another.
Some languages can't be parsed without solving the halting problem, but even in such cases, you can simply bundle it with an interpreter in the target language. And the subset of programs humans are actually likely to write should be much saner.
https://github.com/stephane-chazelas/misc-scripts/blob/maste...
I know it takes advantage of some technicalities (end-of-input separators and such), but it's still a remarkably impressive piece of engineering. I put that up there with some really hairy quines (https://github.com/mame/quine-relay), except it can actually be useful!