Compiler programming comparisons?

Has anyone worked with the three major compilers to create a Xojo/VB6 like language that works on the Big-3 operating systems (Windows, Mac, Linux)?

Since Xojo has been having issues with quality, I have been exploring work with compilers, and more specifically LLVM, GCC, and Clang.

I created a few minor programs in LLVM and it seems easier to program than GCC or Clang. Here are a few questions that I have that I would like your input and experience:

  1. Creating a language takes a long time. Is there a current open-source project that works with VB6-like language? This may shorten the time and not reinvent-the-wheel.

  2. Performance is always an issue, and it appears that Clang has better performance than GCC and LLVM. Is this true or just rumour?

  3. Organic or purchase a language? Sometimes its easier to start a project from the very beginning (organic) which makes the language fit exactly to a VB6-like syntax. Or is there another language that exists which is similar to VB6 that is potentially for sale that can easier to start generating revenue - we all need to eat.

  4. Time is a large factor in this. There are 3 major compilers available and I have read a few books and tending to lean-towards LLVM because of the easier intermediate representation (language). What is a way to get the language created quickly while still maintaining quality? Maintaining quality is the largest factor that I am seeing.

Anything else? Thanks for your thoughts folks!

1 Like

LLVM is the project and clang the C frontend.
GCC is the old GNU compiler project.

And Xojo uses LLVM as backend and has a Xojo frontend.

1 Like

LLVM is a compiler construction tool kit
GCC is a compiler with many possible front ends for different languages
Clang is a front end for LLVM

Personally Iā€™d work with LLVM
It does mean you have to write a front end - the semantic analyzer, tokenizer and parser to generate the LLVM IR but from there you can use what LLVM has

There are specs for VB6 around (although they need a lot of enhancement to support classes, inheritance etc like Xojo does)

1 Like

I am literally working on this as we speak. I had written my own dynamic Python-like language running on a bytecode VM of my own creation, getting it to the point of running basic console apps. It was written in C#.

Iā€™m so fed up of Xojo wasting their community that I started (today) sketching out the syntax for a new Xojo/VB-like language that takes what I like from Xojo but adds things like generics and type inference for variable declarations.

My intention is to first write the tokeniser, parser and analyser/type checker and then pause to evaluate whether to convert the parse tree to LLVM IR or write my own bytecode VM again. Iā€™m sure LLVM is the way to go but Iā€™m writing this in a managed language (C#) and have no C or C++ skills so Iā€™m not sure how easy it will be to take a parse tree and spit out memory managed LLVM.

Oh, Iā€™m also using @dwarflandā€™s awesome Elements compiler to build for Mac, Linux and Windows using C#. I donā€™t have to depend on the end user having .NET installed. For example, my Python-like language interpreter compiled to a native Mac binary of a couple of MB in size.

Another idea Iā€™ve had is approaching @dwarfland and asking about licensing their upcoming Mercury (VB) compiler and writing a Xojo-like IDE as a front end for it. RemObjects (who wrote the Elements compiler) have very publicly stated that they arenā€™t interested in creating a tool that is a write once use everywhere application. They also donā€™t seem to interested in the GUI side of things.

@Garry,

You have more experience than I do at this, and it seems like you and I are in the same position - which is to create an alternative that just-works.

This is fantastic. I was going to literally copy-and-paste the VB6 language, as it was already developed and had some serious brain-power assigned to it over the many years of development.

The more I work with code and the way the internals work, LLVM is the way to go. The only poor part about LLVM is that it is changing relatively quickly. This seems to be a good thing as more functions are being added a monthly. The only negative part about LLVM is that some of the code could break because of the changes.

I am ok with C/C++, as this is the language of what the API declares for VB6 and Xojo have been, that I wrote about. Let me work on the LLVM IR a little more to see what I can do.

That is a good option, as this is a large download and a huge set of libraries.

This is another good option, as it would save much programming time. Would this also check all of the checkboxes of your original design? Example: Not be dependent on .NET, able to create a language quicker, etc.?

My ultimate aim would be to reproduce what makes Xojo great, that is its ease-of-use IDE (which needs improvement, donā€™t get me wrong). Designing a language to be tightly tied to a specific editor has its pros and cons but I for one prefer that option. I already picked a name: Objo and found an available domain (obj.io). Itā€™s short and implies ā€œobject orientedā€.

Very true. My only reservation is that there is a lot of legacy cruft in the language that can be omitted.

Iā€™m quite confident I could get a C# prototype that could take a string / text file and output a parse tree for a Xojo-like language. Iā€™ve never written a type-checker/enforcer (I hear they can be a bitch to write) but I reckon I can do that without too much agony. Where I know I will struggle would be in how to get LLVM to traverse that validated tree and spit out IR and then compile that down to an executable. I would certainly need help in that area.

The next challenge would be hooking our language into Cocoa, Win32 and GTK. The Elements compiler allows you to call directly into those frameworks which was one of the reasons I chose to write my own VM because it was written in Elementā€™s managed C# so hooking into native frameworks could be done without diving into C (which I hate).

Absolutely. Elements could output .NET code but is also able to output native machine code (they call it their ā€œIslandā€ platform) that is entirely self-contained garbage collected code. In theory, you could write an IDE like Xojoā€™s, have that output a giant script containing the code entered by the user and the code required for all of the appā€™s controlā€™s and events and then pipe that to their command line compiler to build an executable.

Do people think @eugenedakin and I are crazy for thinking about this? I think Xojo is leaving money on the table personallyā€¦

1 Like

Sounds quite interestingā€¦ kind of makes my Transpiler project pale in comparison :slight_smile:

1 Like

Maybe the name should be Objio then, so they match?

2 Likes

Ha. That seems way more sensible.

1 Like

This idea has been tossed around a few times, and I am at the point where I am going to try something.

My original idea was to create electronics for Xojo and Python, until API2 came out, and I realized that the language change was not going well. Similarly, I had already started a website at: https://scispec.dev/

The way to make this work would have been to create my own language first - which seems silly that there isnā€™t a language that is VB6-like and is stable, and cross platform. I usually perform market-studies on ideas before launching, and this idea just makes sense.

There are very few languages, no complete languages, there are MANY VB6 developers that are still looking for a language and the current languages donā€™t fit. The only part that has been holding me back, is I know I canā€™t do it myself as there is too much work.

This is not an easy task, and will need significant time (years?).

1 Like

Spot on.

#1 is challenging but doable as Iā€™ve done it twice before; once with a tree-walker interpreter written in Xojo (Roo) and the second time a bytecode interpreted language, not publicly released. Both projects took a long time (Roo about a year, the second language about 8 months). I learned a ton making them and feel I have a good grasp of whatā€™s needed. The proviso here is that the previous two languages were (a) interpreted and (b) dynamic, rather than statically, typed. I think having experience writing a bytecode VM should help in writing a compiler that can output LLVM intermediate language (IL) instead of the made-up-as-I-went-along IL I came up with for my VM. Roo was written in Xojo and the other language (Possum) was written in C#.

#3 is maybe harder than #1. An IDE like Xojo has to provide syntax highlighting, code completion (which means deep hooks into the parser), a visual designer (doable but needs lots of custom drawing) and, I think most difficult, a code generator. The IDE essentially would need to create a huge source code file containing not only the userā€™s code (in events and methods for example) but also all the boilerplate and glue code needed to hook up the GUI elements, import modules, etc. Hard but I think knowable, especially with someone like @npalardy about to give guidance on approaches, etc

#2 to me is the great unknown. This is an area (along with LLVM integration) that I would need some significant help with.

The first goal would be to get console apps up and running from simple test scripts. Either compile them down to bytecode and tack them onto a precompiled interpreted as data (so thereā€™s no need for the end user to install other libraries or indeed an interpreter, see Python Hell) or convert the source code to LLVM IL, pass that along the LLVM toolchain to build a binary.

1 Like

This has been my conclusion, mostly. There are other VB-like languages out there (Gambas, FreeBasic, PureBasic, heck even VB.NET is now open source) but there is none that is bundled with a visual IDE like Xojo. Thatā€™s Xojoā€™s killer ability. Open up the IDE, type some code, hit build and voila! This is marketable.

Not an unreasonable suggestion but that entails me learning another language to an incredibly high level. Not impossible but I am pretty proficient in C# but prefer the non-curly braces nature of Xojo. This is where the desire to create a language like Xojo comes from.

I have thought about this but my gut feeling is that it would be too expensive to license their compiler. I have not made any enquiries at all but if you were to ultimately trying to hit Xojoā€™s price point (or lower) I doubt that would be doable under licence from RemObjects. I could be wrong of course but that is my suspicion.

Thatā€™s very kind of you to say. Completely untrue of course but kind nonetheless!

1 Like

My approach which is on hold while my brain cools offā€¦ is way different than what Garry is describing. Iā€™m going to attempt to write a Transpiler instead.
This will take a BASIC like language, a custom IDE builder (which I already have working prototypes of), combine it all together into a ā€œProject Fileā€.

That file would then be handed to a Transpiler, which would ā€œTRANS"late it into ā€œSwiftā€ and then pass that to Xcode to be com"PILEDā€. Any Xcode/Swift errors would need to be analyzed and feed back to the original BASIC code to indicate where things happened.

Biggest downside, it there is no ā€œdebug runtimeā€. It has to be a full round trip since the actual compiler is a few steps away. But it does save the LLVM side of the project. and for now limits it to macOS/iPad/iPhone and maybe AppleTV

1 Like

Developing a new compiler and later a GUI and later an IDE will be a huge effort. You know, thereā€™s a larger market niche waiting for someone wanting to explore it faster than a ā€œVB6ā€ option.

Kotlin is a great language, and is used as a ā€œnativeā€ language for Android instead of Java as Swift is for MacOS instead of Objective-C. The compiler is ready, a GUI lib exists (native widgets on Linux (Gtk3), macOS, and Windows). Someone needs to join both and write an IDE.

https://kotlinlang.org/docs/reference/native-overview.html

1 Like

This is a good idea Dave. When making a transpiler, you donā€™t need to worry about writing code for the compiler. Once you have your original language where you want it, then the ā€œSwiftā€ code could be converted to IR (intermediate representation) to be passed to the compiler at a later time. You would be able to work on a new language that has all of the error checking of Swift. Thats a good idea.

This also looks like a good idea Rick. I see that Kolin supports almost every operating system. Since it is written in LLVM then it would support all of the same compiler functions. The part that seems nice is that there is no virtual machine needed.

When creating the language and install the program, then Kotlin would also need to be installed. Can Kotlin be silently installed?

Iā€™d love to work on ā€œsomethingā€

But I guess the question is ā€œwhat is that somethingā€ ?

Is it creating a new language & IDE compiler etc from scratch ?

Is it a ā€œtranspilerā€ that takes existing Xojo code and rewrites it to something else ?
And if thats the goal - then to what since it seems x-platform IS a goal.

Just trying to sort out which way all the cats are heading here :slight_smile:

https://youtu.be/Pk7yqlTMvp8

1 Like

Lets go down this rabbit-hole first as it may save time to create a compiler from scratch. Which ā€˜something elseā€™ language is able to create a native file for almost all target operating systems?

As Rick mentioned, it appears that Kotlin seems to create executables: Kotlin

Kotlin/Native supports the following platforms:

iOS (arm32, arm64, simulator x86_64)
macOS (x86_64)
watchOS (arm32, arm64, x86)
tvOS (arm64, x86_64)
Android (arm32, arm64, x86, x86_64)
Windows (mingw x86_64, x86)
Linux (x86_64, arm32, arm64, MIPS, MIPS little endian)
WebAssembly (wasm32)

Edit: It seems that Kotlin supports the platforms, but does it create native executables for each platform? - It appears it does :slight_smile:

And is there a UI toolkit binding for each ?
Being able to compiler a macOS/Windows/Linux cmd line app is one thing
Being able to create a GUI app is a different thing entirely