Compiler programming comparisons?

+10 for this. Writing a command line compiler and interpreter is hard but within the skill set of many developers.

I’ve looked at a bunch of well known languages with liberal licenses to see which one has a GUI library for the main desktop platforms and is able to be packaged up in a convenient manner. It is astonishing how few of the big languages can make a simple desktop app. For example, take Python. There are loads of GUI libraries for it that let you write the code for a window, a button, etc and hook them up but it has no visual designer like Xojo. Add to this the fact that it is virtually impossible to reliably spit out a single file containing your obfuscated Python code, the correct interpreter and all the compatible libraries.

Kotlin (like Dart) are promising targets as they are open source, have robust compilers and runtimes, have desktop GUI libraries and can be compiled down to single executables. I dislike that they are curly brace languages as I think the market for an all-in-one paid for solution will probably find a more receptive audience amongst people who dislike curly braces but I’m happy to be proven wrong.

Another option is to use Roslyn which is now open source. If we could figure out a way to abstract all the underlying Mono issues and find a way to hook into GTK on Linux we could make an IDE for the actual VB language. When I first started using Visual Studio my brain hurt from having to get me head around the different runtimes. Xojo completely insulates developers from that (which is great).

@npalardy You have the most experience in this area. Which approach would you take? I would seriously consider putting proper money or time into this as an idea.

I think there is a business opportunity in this space.

Maybe we could write the IDE in Xojo :smile:

You’re one of the most talented developers I know @DaveS so I have no doubt you can do this. My reservation about transpilers is the debugging issue. Being able to step through code will be virtually impossible in your IDE if you transpile. This is what put me off using Haxe (an amazing language btw) and I think is what has prevented it’s wider use. You have to debug Haxe code in a browser in its JavaScript form.

Never. Eat your dogfood. Write it in Kotlin.

As for a prior question about “can we install Kotlin silently?”, the answer is yes, but you will write the installer (or use one of those ready to build your pack) as the install is just writing a bunch of files and folders and setting environment variables. Also, besides Kotlin-native producing independent native code for many targets, the current compiler depends of having a JDK 8+ previously installed in the machine, and that also com be pre-installed silently if you want to (like “JDK.exe /s”). The executables that you will produce will not be Java dependent, just your development tooling needs it… currently.

Kotlin is a native option for Android. And have, as I pointed out with links, libs for native UIs for Windows, Linux and Mac.

The number #1 language in TIOBE is C. #2, #4, #5, #7, #9 are also curly-braces languages… You are proved wrong.

Will it be easy? Create a RAD Kotlin? Nope. If it was a weekend job I would do it. But it will be easier than writing another a new compiler, writing UI libs, writing an IDE, maturing all those, and convincing people about how great is your new language design asking for adoption until it gets just cited in the TIOBE ranking as something that exists.

lets avoid roslyn, until, unless its portable (which I dont believe it is now)
A good example of why not to use it is Delphi
They cant make a cross platform IDE - for 2 reasons

  1. they dont use their own x-platform framework
  2. roslyn is NOT portable

I respectfully disagree. I didn’t say curly brace languages aren’t popular, just that the market for developers who will pay for tooling to do RAD is likely strongly for those that prefer non-curly brace languages.

2 Likes

Kotlin looks interesting. On the other hand, it’s a completely different language. Wouldn’t a similar project with Elements Mercury give us the bonus to stay with a Basic dialect?

1 Like

Well… You guys doesn’t seem looking for solutions, but for BASIC alternatives. I can’t help with that. :smiley: Good luck.

I think all the B4X tools are transpilers, and all of them can step through code, even can do a hot swap.

Maybe @Erel could say something about it, or think of a B4Desktop (Native)

I chose BASIC as the base, not because it is “basic”, because it is not, but because the syntax has been around since forever, and is easily extendable.

As far as curly brackets… I can see everyones reasoning and to an extent agree. It can become quite easy to not be sure what level you are at… but proper code formatting helps considerable with that.

And yes, the ability to step thru the code is something a transpiler cannot easily do at the design level. but it can be done at the compiled level with proper callbacks

I think there’s a couple motivations going on
At least there is in my own case

  1. feeling I need to move to “something else”
  2. I have a ton of code in Xojo and dont want to have to rewrite it all with whatever gets created IF I can avoid it

Combine those two and some mechanism to move existing Xojo code to “something else” would work
Whether that is a “Xojo/VB like” IDE for something like Kotlin I dont know

I do know I do now want to go back to writing code to design a UI

1 Like

My take is this:

  • In principle, Xojo is a great idea. A pleasant syntax, integrated visual GUI designer and one-click building to an executable
  • Xojo Inc have spread themselves too thin, have become unresponsive to constructive feedback and the toolchain is riddled with bugs
  • The Xojo language, whilst pleasant, lacks some functionality that is essential in modern day programming. The main culprit being the lack of generics but also their interface implementation needs reworking (for instance, why can’t I define a static method in an interface or provide a default implementation?)
  • The Xojo runtime is frankly underwhelming. You get so much “for free” with Java and .NET that you have to reinvent constantly with Xojo. Xojo Inc seem unwilling / unable to address this

What I want and what I’m proposing is thus:

  • An object-oriented, event-driven BASIC-like programming language targeting desktop and command line applications. I am willing to use a curly-brace language so long as the following points can be met
  • A compiler for the above language that can (ideally) produce a single file binary for macOS, Linux and Windows. Specifically, the built app should not require the end user to install the JVM, .NET, Mono or a Python interpreter + dozens of libraries
  • I have no real preference as to whether the compiler produces native code or produces an interpreter (as a self-contained executable) with bytecode appended to it, thereby giving the illusion of a single-click app
  • An IDE that provides a library of controls that can be arranged visually and an easy way to associate code with each control’s events. The IDE needs to provide syntax highlighting, code completion and, ideally, some form of package management to make sharing libraries of code easier
  • The runtime classes should be open source. Ideally it should be written in the base language. This way people can contribute to the runtime separately from the IDE. Check out RemObject’s Elements runtime library (RTL). This provides common classes (file access, serialisation, etc) that can be added to by the community.
3 Likes
  1. There is, take a look on Gambas.

  2. Clang has a good performance as frontend of llvm

  3. It would be possible to bring up organic. Again: take a look on Gambas for it

  4. I would ever start with LLVM/Clang cause it is the Solution for all platforms together with gcc

  5. It is all time a question if you want to earn money with the IDE or if you want to get a smart IDE and earn money with support and Addons. If you would make your IDE open source it would be able to fork as startpoint gambas and work it out.

The Clang/LLVM suite is good at creating c to executable code, and this will take a significant amount of time to create code that cross-compiles. My suggestion would be to try another language (Kotlin maybe?) that has already developed a language, and then transpile the language to Kotlin working in the background to create native executables.

I am not sure if Kotlin can do this work, as this may be the reason for LLVM existing.

P.S. My simple Clang-LLVM programs work well, with and without full optimization enabled.

Edit. Another idea is to use clang/llvm and be specific with each target. Cross-compiling will take more time to complete.this would mean windows compiles on a windows machine, mac on a mac, etc.

Unsurprisingly, that’s against their EULA… :grin:

I’m not sure if it against it technically. You can’t create a derivative and you can’t essentially repackage their runtime. Writing an IDE for a different language written in a different language is probably within the letter of the law. I think you have to put “made with Xojo” in the app though. That’s like saying they would disallow you to write an IDE for Python in Xojo.

I wouldn’t use Xojo though :slight_smile:

That is right, it is not against the EULA, BUT any app designed to “aid in the development of software using a language other than Xojo”, must include a “Made with Xojo” logo in the application’s about box and also in a splash screen.

I’m not sure the EULA has changed or if I didn’t understood it right in the beginning.
I’m currently seeing this:

• You won’t create a derivative of the Xojo IDE, frameworks or compiler.
• If you are creating a development tool, you will include the “Made with Xojo” logo.

Which look less restrictive than I thought it was some years ago.

Any attempt to create a competing product to Xojo (an effort I am fully supportive of), should in no way utilize Xojo in any way for any part of the newly created codebase.

Using Xojo as an inspiration for what to do, and more importantly what NOT to do, but not as a tool.

This (to me) has two major advantages

  • Xojo has zero standing to infer any violation of their EULA (real or contrived)
  • Gives the new developers the option of shoving their results in Xojo’s face. with “See it CAN be done”…
1 Like

Not sure it is
You just have to put a “Made With Xojo” in it I think