On Wednesday, 11 November 2015 at 18:25:59 UTC, deadalnix wrote:
> Nim does everything according to their marketing department. The engineering department remains to be found.

Pretty sure you know where you can find me and discuss these things with me. Not sure if I count as a software engineer by your twisted logic though. Either way I won't say more here because then Reddit will complain again and I try to always obey.

On Friday, 13 November 2015 at 21:54:25 UTC, Araq wrote:
> On Wednesday, 11 November 2015 at 18:25:59 UTC, deadalnix wrote:
>> Nim does everything according to their marketing department. The engineering department remains to be found.
>
> Pretty sure you know where you can find me and discuss these things with me. Not sure if I count as a software engineer by your twisted logic though. Either way I won't say more here because then Reddit will complain again and I try to always obey.

To be fair, I was unaware that you were behind Nim and I always though you were a reasonable person.

That is also not a comment about Nim, of which I know very little, but the communication around Nim. When I say the engineering department remains to be found, that is almost meant literally: I never hear of engineering decisions around Nim. I can't even say they are bad, i literally never hear of them.

Which is weird, because I hear about Nim all the time. But every time, this is some grandiloquent speech with very little actual content.

You know what i think about targeting C. Now, this may be a good solution to get something bootstrapped fast, but this isn't something that should be promoted as an advantage or worse, something that is part of what the language is.

You guys have a PR problem.

On 11/13/2015 1:35 PM, Ola Fosheim Grøstad wrote:
> In C the OS/hardware vendors define the binary interface and provides the
> tooling... So what is your point?
>
> Plenty if useful tools and languages compiles to C successfully. That's a
> undeniable fact. That's reality.

True, but that doesn't support your assertion that transpiling to C produces better C interop.

Setting aside compatibility with the C preprocessor, I've asked for a single instance where a language that transpiles to C has better C interop than D does.

2015-11-11 15:19 GMT+03:00, Walter Bright via Digitalmars-d
> I've looked into generating C code as an output format. I found the problems to be endemic and working around them was harder than just generating native code:
>
> 1. You're at the mercy of bugs in the C compiler you cannot fix.
> 2. C leaves quite a lot as "implementation defined", causing endless compatibility issues with >  various C compilers.
> 3. C's integral promotion rules.
> 4. Generating exception handling code for C is miserable and inefficient.
> 5. Your compiler is going to be slower than C.
> 6. You'll suffer from endless bug reports caused by a mismatch between your
....
All this problems are not fatal. There is plenty of the "X" to C
translators, even C++. Most interesting for me is Vala. And generated
by Vala C code looks nice. Your point of view is a point of the
translator writer. From the user point having a C generated code drops
all needs to descripe how this or thats is implemented by translator,
a more portable code because a C compilers are written for everything
(8051 for example), chance quickly replace and compare different C
compilers and interpreters as backends, chance to use different C
tools  to transform and analyze a code, etc....

PS: you just say that C is not suitable for the system programming

On 11/13/2015 10:31 PM, Sergey Korshunoff via Digitalmars-d wrote:
> 2015-11-11 15:19 GMT+03:00, Walter Bright via Digitalmars-d
>> I've looked into generating C code as an output format. I found the problems to
>> be endemic and working around them was harder than just generating native
>> code:
>>
>> 1. You're at the mercy of bugs in the C compiler you cannot fix.
>> 2. C leaves quite a lot as "implementation defined", causing endless compatibility issues with >  various C compilers.
>> 3. C's integral promotion rules.
>> 4. Generating exception handling code for C is miserable and inefficient.
>> 5. Your compiler is going to be slower than C.
>> 6. You'll suffer from endless bug reports caused by a mismatch between your
> ....
> All this problems are not fatal.

True, it just makes things a lot harder.

> There is plenty of the "X" to C
> translators, even C++.

I'm familiar with cfront from the 80's, and it definitely negatively influenced me on generating C code. Zortech C++ was the first native C++ compiler, and it compiled 4x faster than cfront. cfront was never able to handle "near" and "far". Exception handling didn't exist at the time, but cfront never survived as a viable translator after EH appeared. And, in fact, native compilers completely destroyed the viability of cfront.

> Most interesting for me is Vala. And generated
> by Vala C code looks nice. Your point of view is a point of the
> translator writer. From the user point having a C generated code drops
> all needs to descripe how this or thats is implemented by translator,
> a more portable code because a C compilers are written for everything
> (8051 for example), chance quickly replace and compare different C
> compilers and interpreters as backends, chance to use different C
> tools  to transform and analyze a code, etc....

That's all fine until you, as translator writer, have to deal with some stupid bug in version X.XX of a C compiler you never heard of used by an important customer of yours.


> PS: you just say that C is not suitable for the system programming

No, that is an entirely different statement.

On Saturday, 14 November 2015 at 06:16:15 UTC, Walter Bright wrote:
> True, but that doesn't support your assertion that transpiling to C produces better C interop.
>
> Setting aside compatibility with the C preprocessor, I've asked for a single instance where a language that transpiles to C has better C interop than D does.

I'm not sure if it reasonable to set aside the preprocessor, but it depends on what you mean by interop:

1. portability

- A language like Nim obviously has a better portability future since that is the one of the primary goal of having portable C source code.

2. ability to use language X as a C library

- Plenty of tools (specialised languages, like generators for parsers etc) do very well in this department, fully supporting ability to inline the code across compilers.

- D does ok, for the platforms it integrates with, but you have to generate the header files.

3. ability to use C libraries and engines from language X

- D does ok here if the C header files are suitable for translation

Compile time does not have to be a big issue, if you have a good build system and changes are kept locally in the generated C files (smart partitioning of the code into C files). Language semantics efficiency is really the primary reason for not targeting C, imho.

On 11/14/2015 12:06 AM, Ola Fosheim Grøstad wrote:
> I'm not sure if it reasonable to set aside the preprocessor,

If your new language doesn't have the C preprocessor in it, then you must set it aside. If it does have a C preprocessor in it, then it really isn't a new language at all, it's just a C permutation.


> but it depends on what you mean by interop:
>
> 1. portability
>
> - A language like Nim obviously has a better portability future since that is
> the one of the primary goal of having portable C source code.

That's all very fine until the that C compiler evaluates expressions in a different way than the one you debugged it with, and your language fails on your customer's machine with your customer's C compiler, and fails in weird ways.

You can't just dismiss the points I made and say "It's C, so it's portable." It isn't. If you're anxious to learn the hard way, feel free :-) It's one thing to read the C standard and pontificate about it, it's quite another to actually be in the trenches and deal with it.

BTW, although C compilers exist for all kinds of weird machines, the weirder the machine is, the worse (i.e. more limited and buggier) the C compiler is for it (as a general rule).

Good luck porting your language to a C compiler that has 10 bit bytes in it, or one with 32 bit bytes. Yes, those compilers exist. Yes, those are C standard conforming variations. Nope, none of your "portable" C code will work on it.


> Compile time does not have to be a big issue,

It always is once your project exceeds trivial size. Remember, my experience is a factor of 4x slower. And you cannot fix it.

On Saturday, 14 November 2015 at 08:28:08 UTC, Walter Bright wrote:
> If your new language doesn't have the C preprocessor in it, then you must set it aside. If it does have a C preprocessor in it, then it really isn't a new language at all, it's just a C permutation.

But you can do code gen with standard macro invocations present, without the compiler having the actual macro definitions (just a representation of the semantics for the standard headers).

> That's all very fine until the that C compiler evaluates expressions in a different way than the one you debugged it with, and your language fails on your customer's machine with your customer's C compiler, and fails in weird ways.

IIRC C99 defines sequencing points. Granted Microsoft does not support C99, but I'd say C99 is the standard to aim for these days.

> BTW, although C compilers exist for all kinds of weird machines, the weirder the machine is, the worse (i.e. more limited and buggier) the C compiler is for it (as a general rule).

Sure enough, there are weird C compilers for DSP chips that have 32 bit integers with 24 bit ALU operations over it.

But changing the backend to emit different C for weird targets is less work than changing a full backend...

> Good luck porting your language to a C compiler that has 10 bit bytes in it, or one with 32 bit bytes. Yes, those compilers exist. Yes, those are C standard conforming variations. Nope, none of your "portable" C code will work on it.

Modern C has headers with exact bit representations though.

> It always is once your project exceeds trivial size. Remember, my experience is a factor of 4x slower. And you cannot fix it.

Is the fastest non-optimizing C compiler is 4x slower than D?

Compiling to C is actually a very nice thing to have, it keeps languages alive and limits lockin. Thanks to that we have access to classic languages like Simula or interesting niche languages like Mercury on a wide range of platforms. And you can make it work (with a little effort) even if the compiler is old.

http://folk.uio.no/simula67/cim.shtml
http://www.mercurylang.org/backends.html

I could probably make these languages run as asm.js. Having a C generating backend is an enabler.

On Saturday, 14 November 2015 at 09:58:19 UTC, Ola Fosheim Grøstad wrote:
> http://www.mercurylang.org/backends.html

Btw, didn't Ali convert his book on D using princeXML?

princeXML is written in Mercury:

https://en.wikipedia.org/wiki/Prince_(software)

On 11/14/2015 1:58 AM, Ola Fosheim Grøstad wrote:
> [...]

Like I said, you think the points I raised are all non-issues. You'll change your mind once you try to implement one, and then try to support it with a diverse group of customers.


> C99 defines [...]

I just have to laugh. You even admit that Microsoft C doesn't implement C99. What do you think is going to happen when you file a bug report? Do you really believe that all the other C compilers out there are C99 compliant? Or even C89 compliant?

Remember the Warp C preprocessor I wrote a couple years ago?

https://github.com/facebookarchive/warp

Guess what happened when I found out that people were relying on bugs in gcc's preprocessor, not to mention all of its non-standard behavior.

> Modern C has headers with exact bit representations though.

I'm sorry, but Modern C does not provide exact representations for 10 bit bytes unless the underlying hardware supports 10 bit bytes. And the 10 bit byte Modern C compilers do not provide representations for 8 bit bytes.

----------------------------------------------

Your posts on this subject remind me of when I learned how to do data flow analysis from Ullman and Hennessy. The algorithms looked great, and were provably correct. I implemented them. They did not work - because real CPUs and languages did not behave according to Ullman's mathematical models. Getting things to work right required considerably more effort. The Dragon Book was not terribly concerned with the dirty details of how things really work.

There's a huge difference between reading an academic paper about something and getting it to work in the field, one you discount completely.