Ć Programming Language - Compile C# subset to C, Java, C#, JS, AS, Perl and D

[monarch_dodra]

On Tuesday, 18 June 2013 at 02:17:19 UTC, Andrej Mitrovic wrote:
> On 6/18/13, monarch_dodra <monarchdodra at gmail.com> wrote:
>> On Monday, 17 June 2013 at 21:33:20 UTC, Walter Bright wrote:
>>> I tried it on a machine I never use google on, and I got the
>>> same autocomplete results.
>>
>> So anybody want to talk about the language?
>
> I don't see much point in the language. If you limit yourself 
> to a
> minimalistic language in order for your library to be 
> translatable,
> how will the API look like in the target languages? It won't 
> use any
> language-specific features that make APIs easy to uses (for 
> example it
> likely won't provide any range functionality or templates in 
> D..).
>
> You might as well use C, or C++ with some extern "C" API 
> functions.
> Then you can write a stable API, have full optimizations, and 
> can even
> distribute the built binaries for some platforms (and you build 
> once
> per platform, instead of N*platforms * N*languages). Most 
> languages
> can interface with C too.

One of the problems (which is always a pain), is to link the 
actual C code, which is always a task in itself. Also, as the 
authors presented it, it can also work for "deployable 
languages", such a javascript, which wouldn't work with C.

It's true the language only has access to the lowest common 
denominator of features.

I hadn't thought about "API stability": indeed, looking through 
the examples, each language has its own variants in the 
translation: EG the casing between C# and Java:
http://cito.sourceforge.net/hello.html

It also seems to be trying to target both GC and non GC 
languages, which appears to make a mess of things... For example 
it currently doesn't allow string concatenation.

Also, for classes: "new C() allocates new instance of class C and 
returns a pointer to it. If you target the C programming 
language, delete the allocated object some time later." Ouch.