On Tuesday, 24 July 2018 at 01:31:13 UTC, JohnB wrote:
> On Tuesday, 24 July 2018 at 00:41:54 UTC, RhyS wrote:
>> Customers do not understand **** about programming. Your lucky if most clients can even get a proper specification formulated for what they want. If clients are that knowledgeable we do not need to constantly deal with issues where clients had things in their heads different then what they told / envisioned.
>
> I think that what Walter meant was when the customer have this problem where their data is leaking (and perhaps losing money) they will ask why, and an alternative to avoid this in the future will rely on a language that tend to follow the safety aspect.
>
> John B.

Having read all the forum thread around the necessity to terminate an application on bugs or catch-them-and-keep-going, I'm not sure if the programmers folk are not to blame also for that problems.

I agree also on the discussion about management, but, sometime, little companies has illuminate technical management, that can dare to rely on innovative languages to do their job, and compete (against big companies with no-so-illuminate-management). So definitely D has some value for them.

/Paolo

On Monday, 23 July 2018 at 22:45:15 UTC, Walter Bright wrote:
> On 7/23/2018 5:39 AM, Joakim wrote:
>> In my experience, people never learn, even from the blatantly obvious, _particularly_ when they're invested in the outdated. What inevitably happens is the new tech gets good enough to put them out of business, then they finally pick it up or retire. Until most system software is written in D/Go/Rust/Swift/Zig/etc., they will keep mouthing platitudes about how C is here to stay.
>
> I've predicted before that what will kill C is managers and customers requiring memory safety because unsafeness costs them millions. The "just hire better programmers" will never work.

My son broke the handle of a jug a few days ago and spent about 10 minutes arguing with me about how it wasn't really broken you just had to hold it differently.

"C" you just need to hold it differently.

On Tuesday, 24 July 2018 at 00:41:54 UTC, RhyS wrote:
> On Monday, 23 July 2018 at 22:45:15 UTC, Walter Bright wrote:
>> I've predicted before that what will kill C is managers and customers requiring memory safety because unsafeness costs them millions. The "just hire better programmers" will never work.
>
> I have yet to see a company Walter where higher ups will take correct actions to resolve issues.
>
> Customers do not understand **** about programming. Your lucky if most clients can even get a proper specification formulated for what they want. If clients are that knowledgeable we do not need to constantly deal with issues where clients had things in their heads different then what they told / envisioned.
>
> And most manager are not going to rock the boat and stick their necks out. Not when they can simply blame issues on programmer incompetence or "it has always been like that with programming languages". I have yet to see managers really taking responsibility beyond guiding the projects so they do not get fired and hope to rack in bonuses. Issues can always be blamed on the tools or programmers.
>
> Sorry but that response is so naive Walter that it surprises me. Its like wanting a unicorn.
>
> And frankly, good luck convincing any company to convert millions of C code into D code. Not when manager hear about some new language or framework or whatever that is the chizz. They rather keep running the old code and move to something new. D is not something new, its not the chizz, its the same issue that D has struggle with for years.
>
> Its the same reason why that topic derailed so fast. You want to see something fun. Mention PHP on HackerNews/Reddit and you see the exact same trolling. People rather push their new favorite language, be it Go, Rust, ... then pick D.
>
> Response at my work when i made some stuff in D... "Why did you not use Go". Because the managers knew Go from the hype. They know Google is behind it. And some of our colleagues in sister companies already used Go. And that is all it takes.
>
> I am sorry to say but to succeed as a language beyond being a small or hobby language it takes: Being established already or having a big name to hype behind your "product". Anything beyond that will have topic derail and frankly, its more negative then positive.
>
> And D has too much old baggage. Its the same reason why PHP despite being a good language ( for what it is ), still keeps getting the exact same crude on forums.
>
> If i am honest, DasBetterC is a for me unreliable D product because using specific D library function can be GC. Or DasBetterC needs to be sold as C only, ever, forget about everything else that is D ( library, packages, ... ). Until everything is 100% GC free, your going to run into this. And even when its 100% GC free, people have long memories.
>
> Its always a struggle swimming up a river.

+1

IMO, D in its current state, and with its current ecosystem, even after more than a decade of existence, is still NOT the best alternative to C/C++ where they HAVE to be used (microcontrollers, game engines, etc), despite D has always had this objective in mind. And despite C++ is an unsafe language which makes it easy to have memory leaks, dangling pointers, etc.

Because in those case, most of the time, when you use C or C++, it's because you HAVE to, not only because they run fast, but also because they can run without on a garbage collector. Just that simple.

In C++, the memory is immediately released to the allocation system by the collections and smart pointers as soon as it's no longer used.

This may not be perfect, but this process is continuous and predictable. In D, unused memory block are progressively filling the available memory until the non-incremental GC is triggered, either automatically or manually. Completely the opposite way. Not really appropriate for a "forever" event loop, where the unused memory HAS be released in a continuous way, not once in a while.

And when you CAN afford to use a garbage collector, unfortunately D is still not the best pick in many use cases.

While D's standard library makes D a great "plug-n-play" language for file processing and data analysis, for many other use cases, like web development for instance, some very recent languages already provide better alternatives "out of the box" (Go, Crystal, etc), as there have PLENTY of third party libraries (web frameworks, etc) built on top of the SAME building blocks provided by the default libraries of those languages.

So, at the moment, I don't see how you can EASILY convince people to use BetterC for C/C++ use cases, like programming games, microcontrollers, etc.

Same if you want to EASILY convince people to start to use D today for many Go/C#/Java/etc use cases, like developing online services, web sites, etc.

Despite I know that some pioneer companies may have already chosen D for those same use cases, and are perfectly happy with D for that...

So my opinion remains that  :
- become a TRUE and COMPLETE C++ replacement, D should provide the FULL D experience (arrays/strings/slices/maps/etc) using automatic reference counting INSTEAD of the garbage collector (like Kotlin/Native);
- become a TRUE and COMPLETE Go/C#/Java/Scala/Crystal/etc replacement, D should provide the FULL Go-like experience (i.e. BUILTIN fibers/channels/server/etc).

Of course, removing everything that makes D a pleasant language to use (i.e. arrays/strings/slices/maps/etc), calling it "BetterC", and expecting people to use this instead of C++ might also work...

On Monday, 23 July 2018 at 15:06:16 UTC, Ecstatic Coder wrote:
> And something that REALLY must be integrated into BetterC's low-level standard library in some way IMHO...

They already work, except for the concatenation operator because it obviously requires the GC. And converiting a pointer from C code to D is easy, because you can slice pointers just like arrays -it's just that it won't be bounds checked.

On Tuesday, 24 July 2018 at 10:40:33 UTC, Dukc wrote:
> On Monday, 23 July 2018 at 15:06:16 UTC, Ecstatic Coder wrote:
>> And something that REALLY must be integrated into BetterC's low-level standard library in some way IMHO...
>
> They already work, except for the concatenation operator because it obviously requires the GC. And converiting a pointer from C code to D is easy, because you can slice pointers just like arrays -it's just that it won't be bounds checked.

Nice.

But if you want D to be REALLY appealing to a majority of C++ developers, you'd better provide them with the FULL D experience.

And unfortunately, using builtin arrays/strings/slices/maps in the usual way is probably a big part for it.

Don't forget that concatenating strings in C++ is perfectly ALLOWED in C++, WITHOUT using a GC...

#include <iostream>

using namespace std;

int main()
{
    string str, str1, str2;
    str1 = "Hello";
    str2 = "World";
    str = str1 + " " + str2;
    cout << str << endl;

    return 0;
}

Instead of removing D's GC and the feature which rely on it, you'd better replace it by something which releases the unused memory blocks as soon as they have to be, like the reference counted approach used not only in C++, but also in Kotlin Native, Crack, etc...

THAT would make D stand above its competition, by making it more pleasing and enjoyable to use than C, C++ and Rust for instance for their typical use cases...

On Tuesday, 24 July 2018 at 11:53:35 UTC, Ecstatic Coder wrote:
> On Tuesday, 24 July 2018 at 10:40:33 UTC, Dukc wrote:
>> On Monday, 23 July 2018 at 15:06:16 UTC, Ecstatic Coder wrote:
>>> [...]
>>
>> They already work, except for the concatenation operator because it obviously requires the GC. And converiting a pointer from C code to D is easy, because you can slice pointers just like arrays -it's just that it won't be bounds checked.
>
> Nice.
>
> But if you want D to be REALLY appealing to a majority of C++ developers, you'd better provide them with the FULL D experience.
>
> And unfortunately, using builtin arrays/strings/slices/maps in the usual way is probably a big part for it.
>
> Don't forget that concatenating strings in C++ is perfectly ALLOWED in C++, WITHOUT using a GC...

Same in D, it's just that nobody's bothered writing a string class/struct.

Atila

On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder wrote:
> So, at the moment, I don't see how you can EASILY convince people to use BetterC for C/C++ use cases, like programming games, microcontrollers, etc.

*Extremely powerful meta programming that blows c++ meta programming out of the water
*Clean readable syntax
*No header file nonsense
*Standard keyword for ASM if you really need the performance boost.
*Compiler enforce memory safety.

-Alex

On Tuesday, 24 July 2018 at 12:13:27 UTC, Atila Neves wrote:
> On Tuesday, 24 July 2018 at 11:53:35 UTC, Ecstatic Coder wrote:
>> On Tuesday, 24 July 2018 at 10:40:33 UTC, Dukc wrote:
>>> On Monday, 23 July 2018 at 15:06:16 UTC, Ecstatic Coder wrote:
>>>> [...]
>>>
>>> They already work, except for the concatenation operator because it obviously requires the GC. And converiting a pointer from C code to D is easy, because you can slice pointers just like arrays -it's just that it won't be bounds checked.
>>
>> Nice.
>>
>> But if you want D to be REALLY appealing to a majority of C++ developers, you'd better provide them with the FULL D experience.
>>
>> And unfortunately, using builtin arrays/strings/slices/maps in the usual way is probably a big part for it.
>>
>> Don't forget that concatenating strings in C++ is perfectly ALLOWED in C++, WITHOUT using a GC...
>
> Same in D, it's just that nobody's bothered writing a string class/struct.
>
> Atila

Indeed...

On Tuesday, 24 July 2018 at 13:23:32 UTC, 12345swordy wrote:
> On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder wrote:
>> So, at the moment, I don't see how you can EASILY convince people to use BetterC for C/C++ use cases, like programming games, microcontrollers, etc.
>
> *Extremely powerful meta programming that blows c++ meta programming out of the water
> *Clean readable syntax
> *No header file nonsense
> *Standard keyword for ASM if you really need the performance boost.
> *Compiler enforce memory safety.
>
> -Alex

I know.

And D's builtin strings/arrays/slices/maps/etc and automatic memory deallocation are part of what makes D a better alternative to C++ too.

I'm just saying : Kotlin Native automated memory management through automated reference counting with cycle detection.

That solution may have its own drawbacks over a "true" traditional garbage collector, but its main advantage is that it's transparent. Business as usual...

And IF you need to disable the cycle collector, you can still have a TRUE and COMPLETE replacement for C++, by simply using weak references to avoid strong reference cycles, just like in the provided standard library.

Best of both worlds, no need for a "nogc" standard library, as it IS nogc by default, while still providing exactly the same functionalities as in the "gc" standard library...

On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
> On Tuesday, 24 July 2018 at 13:23:32 UTC, 12345swordy wrote:
>> On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder wrote:
>>> So, at the moment, I don't see how you can EASILY convince people to use BetterC for C/C++ use cases, like programming games, microcontrollers, etc.
>>
>> *Extremely powerful meta programming that blows c++ meta programming out of the water
>> *Clean readable syntax
>> *No header file nonsense
>> *Standard keyword for ASM if you really need the performance boost.
>> *Compiler enforce memory safety.
>>
>> -Alex
>
> I know.
>
> And D's builtin strings/arrays/slices/maps/etc and automatic memory deallocation are part of what makes D a better alternative to C++ too.

No. For many C++ users, tracing GC is absolutely not an option. And, if it were, D's GC is not a shining example of a good GC. It's not even precise, and I would bet that it never will be. If I'm able to tolerate a GC, there are languages with much better GCs than the D one, like Go and Java.

I work in a mostly C++ shop where exceptions are intolerable in C++ code, and in many places we use CRTP to eliminate dispatch overhead. DasBetterC would be usable here but it's too late given the existing investment in C++. Obviously there's no CRTP in DasBetterC without struct inheritance, but there are other designs to address this issue.

Besides having more betterC libraries, I'd like to see some kind of restricted approach to exception handling, like the ones being investigated in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf. If you want a better C++, look at what people who have to use C++ use it for, and where the pain points are.