Hope to bring Kotlin to the Elements family

Let me take a gander. I would imagine for a language to be considered, it would have to rank fairly high in the Tiobe index (or most loved languages on Stack Overlfow) to make it somewhat worthwhile for RemObjects. Although there are some very cool technologies like BEAM - Erlang virtual machine which is much more ubiquitous than one may suspect .

New dynamic, functional languages like Elixir and Gleam have been developed for the BEAM. But this ecosystem may be straying too far away from REMObjects business model. :grinning:

Getting back to the top languages on the Tiobe Index, it looks like RemObjects has quite a few already listed in the top 20 (eg. Java, Go, C#, VB, Swift, Delphi/Oxygene). I guess one could add C, C++ and Objective-C as un-managed languages to the mix. The rest of the Tiobe index is replete with scripting languages like Python, Javascript, PHP and Ruby. Groovy ranks at #20. On Stack Overflow’s index, Rust is the most loved language but that would be more of an un-managed language like C/C++. TypeScript comes in at #2. Kotlin ranks #4 ahead of Swift at #9. Dart which ranks at #7 may be a consideration since Google is slating to use it as one of its principle languages for its future OS (Fuschia). Good thing Kotlin is diversifying. Julia ranks at #6, and although described as a general purpose programming language, it appears to be geared for data science and is attempting to de-thrown the parallel high-performance computing champion, Fortran. This arena is probably not a strong consideration for RemObjects.

Most Loved languages on Stack Overflow

1 Rust 86.10%
2 TypeScript 67.10%
3 Python 66.70%
4 Kotlin 62.90%
5 Go 62.30%
6 Julia 62.20%
7 Dart 62.10%
8 C# 59.70%
9 Swift 59.50%
10 JavaScript 58.30%
10 JavaScript 58.30%
11 SQL 56.60%
12 Bash/Shell/PowerShell 53.70%
13 HTML/CSS 53.50%
14 Scala 53.20%
15 Haskell 51.70%
16 R 44.50%
17 Java 44.10%
18 C++ 43.40%
19 Ruby 42.90%
20 PHP 37.30%

I think Kotlin may be a strong contender as well for RemObjects future line up because of its growing popularity in various indices and it would sync up well with RemObjects existing frameworks. :nerd_face:

Be careful; most loved doesn’t mean most used, and lesser loved doesn’t mean lesser used :slight_smile:

If I look at the usability of the current stack of languages, I think RemObjects did already an outstanding job. But, what is missing are the native parts; Microsoft is using C++ for everything that is native, most others are using C. An example of this is the native WebView component from Microsoft - build in C++ and thus unusable in RemObjects, as it cannot import the header files.

There is an import tool available for C header files, but it would give real power to just to be able to host the sources, so C and C++ are high on my list when it comes to the use of native libraries of the different OS’ses.



Oh yes, Fuchsia. Is that still happening? it’s been years since I heard about this. Definitely something we’ll want to be targeting as a new Island sub-mode, once it materializes.

Indeed. it also doesn’t mean “will be paid for”.

I’ts important (i’m just pointing this out for context, i know you are aware) of the distinction between language and platform. All our languages are managed (on .NET and Java) and unmanaged (on Island). (i consider Cocoa “half-managed”).

Adding a new language is not a concern of supporting managed vs unmanaged, it’s just syntax. eg if we/d add Kotlin, it would still e managed, on .NET, and unmanaged, on Island. Same for C++ (see below).

C is doable (and i think @ck has something that we never finalized/shipped that basically converts C to pseudo-C# internally for being able to build it. This was a skink-work project, and I don’t recall the status, I’ll let Carlo answer this. But I know he used this for the Elements-native SQLite implementation he did. Short of adding C as an official language (probably not anytime soon, if ever), maybe that’s something we can make available for more general use.

C++ is out of the question, unless someone wants to sponsor us the resources to hire a couple dozen extra compiler engineers for a few years. Not only is it a nightmare and a mess that no single person fully understands, but it’s also an exponentially growing problem space that we could never keep up with in our wildest dreams.

We also don’t support importing and accessing C++ objects, for that reason (only C and Objective-C), as the ABI is (a) way too complicated and (b) too inconsistent between existing compiler vendors to make this feasible.

So C++ will never, ever happen. Yes, sometimes you can say “never”.

For C, i think it makes more sense to improve the ways to to import and work with existing bianry+header files (which does work very well, so feedback appreciated on what improvements there would actually help make this more useful/usable that the current Import Projects.


Thanks for the overview Marc et al … always very interesting to learn about what is feasible and why. I’m getting smarter being in this group :nerd_face: The only time I mess with C++ is when I play around with the Unreal engine :gun: :gun:. Yeah, Fuschia looks like it’s moving along and is actually in the first gen Nest hubs. Here are the languages that are currently supported in Fuschia, but there appears to be room for other languages to be added (maybe). :upside_down_face:



Cool, i’ll have a look! Is this actually someiohtng one can install and run (eg in a VM) yet?

It appears that way, Marc :cowboy_hat_face:

Get started with Fuchsia

The steps are:

  1. Download the Fuchsia source code.
  2. Configure and build Fuchsia.
  3. Start the Fuchsia emulator.
  4. Explore Fuchsia.

Cool. I’ll get out one of my older Intel MacBooks later and check this out, as it seems arm64 is not supported yet. thanx!

1 Like

So there’s a lightweight thing where we convert C to C#/pascal and a special mode to allow running “less restrictions” mode: IslandRTL/rpmalloc.pas at master · remobjects/IslandRTL · GitHub is a possible result.

But this is really a thing I only tested as far as I needed for rpmalloc and not tested further than that (only the result of this conversion, rpmalloc).

1 Like

Speaking of Kotlin, it looks like it’s evolving nicely. Context receivers (still in prototype) looks like it may prove to be a useful function. :cowboy_hat_face:

Interesting. those “Lambdas with Receivers” sound interesting, even though their “with()” example function shows everything that’s wrong with classic Pascal’s with construct, which we purposefully dropped for Oxygene :wink:

Watching on thru the store() example, the actual context receivers sound, to be honest, like a similarly pretty terrible idea.

Kotlin and Swift seem to have in common (aside from the syntax), that they are very focused on creating obfuscated code that is basically unreadable, once written. Which is bad, because it is far more important for code to be clear to read than it is for it to be quick to write. IMHO.


So, do you mean this? :cowboy_hat_face:

The With keyword is a convenience provided by Delphi for referencing elements of a complex variable, such as a record or object.

It simplifies the code by removing the need to prefix each referenced element with the complex variable name.

For example :

myObject.colour := clRed;
myObject.size   := 23.5;
myObject.name   := 'Fred';

can be rewritten :

With myObject do
  colour := clRed;
  size   := 23.5;
  name   := 'Fred';

However be warned that it can surprisingly make your code more difficult to read, especially when nesting With clauses. More disturbingly, it can create maintenance problems, where a code change can mean that the wrong target for the ‘child’ field referenced.


1 Like

That’s where Mercury comes in; clear to read and quick to write :grinning:


I don’t know which language introduced this keyword. In practice this language construct was helpful in VBA for example to keep the code morde readable in Excel scripts for example. So I think this feature made sense applied in the context of COM and/or Active X together with VB or components in general these days especially.

In VBA the with keyword was very helpful especially when nested, one interface after the other. Properties are an old concept found long time before being introduced to popular programming languages in concepts for databases (university), plain theory long/some time before relational databases started to spread on the PC.

These days properties were really nothing but mapped functions/procedures written in more or less just procedural languages.

There is nothing wrong with having Kotlin at hand. In the end we implemented what those guys showed in practice on Oberon (compiler not the environment) together with co-routins already before 2k at university in a course called Operating Systems II. Short afterwards the dominant forces in the IT-community decided for threads since they didn’t work (clean) anywhere. Co-routines worked, so no need to investigate further. Out of sight, out of mind, buried in the dust and 20 to 30 years later introduced as the next new big thing, think of Kotlin and co-routines or C++ and co-rounties.

Remember Java in the 1990s, People were crying ‘Synchronize! Be king, be king!’. Praised everywhere, took long until this ‘feature’ started to operate.

That’s very typical for IT. Introduce new features and invite people to waste their life-time, especially those who have to live with the results provided by their predecessors. Language features are helpful and allow to achieve a lot in one place have to be considered in all the others.

I’d love a keyword forget/forget about, where everything that I know/remember and should not be touched is listed. A certain kind of ‘I really don’t want to use things such as/like …’.

program Hoppy forget about GUI, case sensitivity;
system.out…println(‘Howdy neighbors!!!’);
forget java, remember .net;
Console.WriteLine("Howdy Julian, the wise owl!);
forget 00;
writeln('Welcome Titanic and passengers!);

That’s just an example, but it’s not meant to be applied this way or for such purposes.

In general when it comes to ‘Pascal’ I miss a simple way to initialize several properties or members being part of a compound structure in one line. That’s a requirement very typical for people used to shells and used to more or less still line oriented languages or grown from such a tradition.

(clRed, 23.5, ‘Fred’) =: myObject(color, size, name); Or something similar should be possible too.

That’s not a requirement!

Since Oxygene does a pretty good job and allows to pleasantly write readable code. That’s one above is good example which shows that Pascal already failed at the Altair computer. The more ‘hostisch’ (terminal and/or line oriented) the environment becomes, it’s more likely that some old fashioned ideas will return.

1 Like

Good conference talk YouTube served me up as follow-up to the Kotlin one: The Worst Programming Language Ever - Mark Rendle - NDC Oslo 2021 - YouTube


Too funny :smile: Some years ago, I watched Mark Rendle’s The Worst Programming Language Ever (Mark Rendle, 2014). It should be entitled How to Make the Worst Programming Language Ever, because Mark takes what he finds to be the worst bits out of various languages to create the worst one. He rips on just about every language including Visual Basic for using parentheses vs square brackets for arrays (@ 27:00 min). I know, sorry, @Theo69. :grimacing: But Mark is pretty darn funny. :joy: Thanks, @mh, for posting the updated 2021 version.


Round brackets for indexing - yes, that is a big mistake in VB, it should have been square brackets.
Same for Option Strict off - only needed because there was no dynamic type, all other usages are only to build bugs very fast, so it shouldn’t have been there too. Option explicit off is also something that should not be there.
Another thing of VB is the following: a = b = c
What moron thought of that syntax? As VB has no difference between assignment and comparison (both =), it should have made the parentheses mandatory, making the statement a = (b = c). But luckily, this syntax is allowed too and good programmers use this style.

But as they say in the C++ world: We have the right to shoot in our own foot.
The usage and way of usage of those options do not say anything about the program language, but about the programmer.


Objective-C! :slight_smile:


Believe it or not, an “Objective-C, but better” was on there drawing board at one stage. Some artifacts of t are still in Fire, such as:

Although Apple retired it, and not many will agree with me, it’s still a great language.

Nitrogene is a nice name. Would be stupid to not pick that project up again … :wink:

1 Like