On Monday, 5 February 2018 at 00:56:20 UTC, welkam wrote:
> On Sunday, 4 February 2018 at 22:05:45 UTC, Dgame wrote:
>> I want to use a language and if I see problems which are ignored I move on. That is how it is, no offense.
>
> So you see a problem and do not work on fixing it then complain that other people do the same. Ok.

Nice try in twisting someones words. As I already said, you are one of those guys I spoke about. :) Keep going!

On Monday, 5 February 2018 at 07:46:46 UTC, Dgame wrote:
> On Monday, 5 February 2018 at 00:56:20 UTC, welkam wrote:
>> On Sunday, 4 February 2018 at 22:05:45 UTC, Dgame wrote:
>>> I want to use a language and if I see problems which are ignored I move on. That is how it is, no offense.
>>
>> So you see a problem and do not work on fixing it then complain that other people do the same. Ok.
>
> Nice try in twisting someones words. As I already said, you are one of those guys I spoke about. :) Keep going!

You keep demonstrating the 'actual' problem...everytime you post.

:)

On Monday, 5 February 2018 at 05:28:54 UTC, Walter Bright wrote:
> True, D cannot directly read .h files. There are tools, though, to convert C .h files to D.

'Tools' sounds very capritious, but I have no experience with such things. I somehow doubt things like SWIG will work ok on kernel headers (let's assume driver\LKM development).

> I have thought about building this into D many times, especially since the Digital Mars C compiler is now available since it is Boost licensed.

I think that would be most logical thing to have, but that would also imply preprocessor, or at least it's restricted subset, wich you most probably though about as well.

> D has a pretty good chunk of those already built in. The others don't come up very often, and can be done using D's inline assembler.

I have no doubt it can be done in the end. I solely imply that the disadvantage here is that in C's "main" (imo) use case it has to be done, and that is a thing to be concerned about when picking a language.

Building baroque district in brutalist city is intriguing, but good luck pushing it through municipality and ministry of culture. It's content must be realy fancy. That is not a problem though, if you're building a little town of your own somewhere nearby.

On Monday, 5 February 2018 at 08:06:16 UTC, Boris-Barboris wrote:
> I have no doubt it can be done in the end. I solely imply that the disadvantage here is that in C's "main" (imo) use case it has to be done, and that is a thing to be concerned about when picking a language.

Yes, the wheels are turning. C is for portability and C++ is for system level programming.

On Saturday, 3 February 2018 at 01:52:04 UTC, psychoticRabbit wrote:
> On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
>> [...]
>
> I think that point hits the cause of your problem with D (along with your need to 'choose' something over 'something' else).
>
> [...]

I think it is worth mentioning that D does in fact have corporate interests driving some of the development behind D. They have "sponsors" just like many other languages, we just don't see the direct connection between a sponsor's donations and the focus of development of the language.

On Monday, 5 February 2018 at 10:23:23 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 5 February 2018 at 08:06:16 UTC, Boris-Barboris wrote:
>> I have no doubt it can be done in the end. I solely imply that the disadvantage here is that in C's "main" (imo) use case it has to be done, and that is a thing to be concerned about when picking a language.
>
> Yes, the wheels are turning. C is for portability and C++ is for system level programming.


C is for trusting the programmer, so that they can do anything.

It's also for keeping things fast - *even if not portable*.

Last but not least, C is for keeping things small, and simple.

(btw. these are somewhat paraphrased versions I took from a MISRA C paper)

C does all this really well, and has done so... for a very long time.

I believe this is why its not so easy to create a 'better' C (let alone convince people that there is a need for a better c)

On Monday, 5 February 2018 at 11:25:15 UTC, psychoticRabbit wrote:
> C is for trusting the programmer, so that they can do anything.
>
> It's also for keeping things fast - *even if not portable*.

C++ is the same...

> Last but not least, C is for keeping things small, and simple.

Yes, it takes less discipline to keep executables small in C, thanks to the lack of powerful abstraction mechanisms... Although in theory there is no difference.

> C does all this really well, and has done so... for a very long time.

I don't know how well it does it. When designing for assembly you tend to be annoyed by how inefficient C is in translating to machine language... But people generally don't do that anymore so I guess that perception is lost.

> I believe this is why its not so easy to create a 'better' C (let alone convince people that there is a need for a better c)

I don't think many want a replacement for C, in the sense that the language is very limited.

It is possible to create a much better language for embedde programming than C, but the market is not growing, thanks to CPUs being much more powerful now, even for embedded.

On Monday, 5 February 2018 at 11:38:58 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 5 February 2018 at 11:25:15 UTC, psychoticRabbit wrote:
>> C is for trusting the programmer, so that they can do anything.
>>
>> It's also for keeping things fast - *even if not portable*.
>
> C++ is the same...

No. C++ is primarliy about higher order abstractions. That's why it came about.
Without the need for those higher order abstractions, C is just fine - no need for C++

The benefits of C, come from C - and only C (and some good compiler writers)

>> I believe this is why its not so easy to create a 'better' C (let alone convince people that there is a need for a better c)
>
> I don't think many want a replacement for C, in the sense that the language is very limited.

(depends on what 'many' means)  - There certinaly are 'numerous' (what ever that means) projects trying to create a better c - which contradicts your assertion.

A limited language can be a good thing too.

On 2018-02-05 06:28, Walter Bright wrote:

> True, D cannot directly read .h files. There are tools, though, to convert C .h files to D.
> 
> I have thought about building this into D many times, especially since the Digital Mars C compiler is now available since it is Boost licensed.

I did that as an experiment. Embedding DStep in the compiler [1]. It got a mixed response. Some prefer to have it as a separate tool, some prefer to have it built-in. DStep depends on libclang, meaning the compiler would depend on libclang as well.

[1] https://forum.dlang.org/post/ks3kir$1ubq$1@digitalmars.com

-- 
/Jacob Carlborg

On Sun, 2018-02-04 at 20:15 +0000, bpr via Digitalmars-d wrote:
> 
> […]

> Maybe, Rust is a decent language, and it appears to be getting better faster than D is. I recall the announcement of an experimental precise GC for D in 2013 or so, and Andrei at the time made it clear that a precise GC would be worth it even at some cost in performance. I don't think D will ever get a precise GC. Maybe the Rust and "Modern C++" guys are right and it's not worth it in a systems programming language?

Go is a systems programming language with a GC. Well at any one time there is one GC, but it does keep evolving, changing, and improving. The Go team obsess, and quite right too, about having a GC that has as little effect on the user application as possible.

As does the JVM. I think it is now on the seventh GC, and it always gets better. G1GC is very good but still people are trying to improve it.

The problem seems to be when you have a GC and don't then try to improve it.

[…]
-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk