On Thursday, 8 August 2019 at 10:29:36 UTC, Russel Winder wrote:
> On Wed, 2019-08-07 at 17:16 -0700, Walter Bright via Digitalmars-d wrote: […]
>> 
>> Before ZTC++, C++ was a curiosity on unix platforms that was battling
>> neck-and-neck with Objective C. (The comp.lang.c++ and comp.lang.objectivec
>> newsgroups had about the same traffic volume.) After ZTC++ appeared, C++
>> boomed
>> and ObjC tanked (and was rescued from oblivion by Apple).
>
> Being in the UNIX (well Solaris) world at the time at UCL, C++ was seen as interesting but in need of templates which it then got (1990) and so became viable, and Objective C was seen (possibly wrongly but still) as ramming Smalltalk and C together badly and so not viable. Someone got a few NeXT machines but they got put in a cupboard to gather dust: nice UI paradigm, useless programming platform. Macintosh had already taken hold in the HCI and media communities.
>
> I was teaching C++ to first year second term (first term they did Scheme (1987 and 1988) or Miranda (1989 onwards) undergraduates 1987 to 1992 – all dates ±1. We used the Glockespiel compiler because CFront was an afront, and GCC was not up to it. Students liked it and did very well. After 1990 anyway when we didn't have to do #define/void* hacks to create data structures but could use templates.
>
> Of course templates with untyped parameters was an error, still not fixed in C++20 – apparently Concepts got pulled out again.

Concepts are part of ISO C++20.

It was contracts that got pulled out during the Cologne meeting due to some last minute discoveries of a few semantic issues.

On Thursday, 8 August 2019 at 00:27:03 UTC, Walter Bright wrote:
> On 8/7/2019 9:17 AM, Exil wrote:
>> Right DMC is all but dead,
>
> Mainly because I stopped working on it to do D full time.
>
> Although I remain the only person to have implemented a soup-to-nuts C++ compiler, simultaneously doing two languages proved beyond me :-)
>
> Just to be clear, without the DMC++ back end, D would never have happened. For example, Windows 64 support became critical a few years ago. GDC and LDC were quite inadequate on it (they've since improved greatly) and we would have been severely negatively impacted if I hadn't upgraded the backend for Win64.
>
> It's a great strength of D that we have 3 well-supported compilers, DMD, LDC and GDC.

That's simply because of the backend you chose, and ultimately it is the limiting factor now. LDC originally attempted to just implement their own frontend. Now it is basically what DMD should have been. I don't ever expect DMD to get ARM support, or cross compiling capability. The amount of work needed just isn't worth it, especially when there's a project that takes care of that for you. It seems like the decision is based on some kind of ego thing (as seems to keep being demonstrated) rather than a rational process.

So why continue to use an old dead project in your current active project?

On Thursday, 8 August 2019 at 00:16:22 UTC, Walter Bright wrote:
> On 8/7/2019 4:33 AM, Paulo Pinto wrote:
>>> Not only that, Zortech C++ is the reason C++ itself reached the tipping point and became mainstream.
>> Sorry to say it like this, but Zortech wasn't relevant in Europe, if at all.
>> 
>> I got introduced to C++ via Turbo C++ 1.0 and it was all Borland, Microsoft and Metrowerks from there on.
>
> That came years afterwards. The success of Zortech C++ motivated Borland to drop their project of adding OOP extensions to C and go with C++. (I know the people involved.) The success of Borland C++ motivated Microsoft similarly (I heard at the time that MS was also developing their own OOP C language, but was never able to get confirmation).
>
> But there is little doubt the sharp upward tilt of C++ happened with the introduction of Zortech C++. ZTC++ was on DOS, where 90% of the programming at the time happened.
>
> Before ZTC++, C++ was a curiosity on unix platforms that was battling neck-and-neck with Objective C. (The comp.lang.c++ and comp.lang.objectivec newsgroups had about the same traffic volume.) After ZTC++ appeared, C++ boomed and ObjC tanked (and was rescued from oblivion by Apple).

See "data" means showing the actual statistics when you say "then ZTC++ appeared then C++ boomed", this means nothing without the data to back it up. It means even less when coming from someone with a clear bias.

On Thu, 2019-08-08 at 11:04 +0000, Paulo Pinto via Digitalmars-d wrote: […]
> 
> Concepts are part of ISO C++20.

Many thanks for correcting my claim. I got my internal wires crossed and have confused myself and possibly others. Good to get it right!

> It was contracts that got pulled out during the Cologne meeting due to some last minute discoveries of a few semantic issues.
-- 
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

On Thursday, 8 August 2019 at 13:14:45 UTC, Exil wrote:
> See "data" means showing the actual statistics when you say "then ZTC++ appeared then C++ boomed", this means nothing without the data to back it up. It means even less when coming from someone with a clear bias.

Surely you know how to use Google. Walter's given every bit of information you need and place to look at to verify his claims for yourself.

You know what's cheaper than research? Abject cynicism.

Stop it.

On Thursday, 8 August 2019 at 13:03:17 UTC, Exil wrote:
> On Thursday, 8 August 2019 at 00:27:03 UTC, Walter Bright wrote:
>> [...]
>
> That's simply because of the backend you chose, and ultimately it is the limiting factor now. LDC originally attempted to just implement their own frontend. Now it is basically what DMD should have been. I don't ever expect DMD to get ARM support, or cross compiling capability. The amount of work needed just isn't worth it, especially when there's a project that takes care of that for you. It seems like the decision is based on some kind of ego thing (as seems to keep being demonstrated) rather than a rational process.
>
> So why continue to use an old dead project in your current active project?

I like the DMC++ backend, because it runs faster than the alternatives. If I actually need code that runs as fast as possible I'll use ldc, but that hardly ever happens. Compilation takes too long as it is, I don't want to wait for LLVM as well.

On Thursday, 8 August 2019 at 18:22:56 UTC, Atila Neves wrote:
> On Thursday, 8 August 2019 at 13:03:17 UTC, Exil wrote:
>> On Thursday, 8 August 2019 at 00:27:03 UTC, Walter Bright wrote:
>>> [...]
>>
>> That's simply because of the backend you chose, and ultimately it is the limiting factor now. LDC originally attempted to just implement their own frontend. Now it is basically what DMD should have been. I don't ever expect DMD to get ARM support, or cross compiling capability. The amount of work needed just isn't worth it, especially when there's a project that takes care of that for you. It seems like the decision is based on some kind of ego thing (as seems to keep being demonstrated) rather than a rational process.
>>
>> So why continue to use an old dead project in your current active project?
>
> I like the DMC++ backend, because it runs faster than the alternatives. If I actually need code that runs as fast as possible I'll use ldc, but that hardly ever happens. Compilation takes too long as it is, I don't want to wait for LLVM as well.

idk how to LDC working right now but u have many options to compile D modules with LLVM:
- u can generate IR for CTFE for each func in module and run it concurrently by JIT while generating IR for next funcs.
- u don't need optimize CTFE code with 60+ opt passes, maybe 0-10, cuz this code only for generating final source/IR for module. BUT u still need do best optimization for compiling final/Release App/user code (non CTFE). and no need optimize Debug final code. need to say that Rust-ers complains on LLVM long compilation too.
- u can interoperate with any generated LLVM-IR modules generated by other langs (Swift/ObjC/C++/Rust/..) at IR level not at arch ABI.
- C++ 2x will add dynamic compilation that already supported by LLVM.
- LLVM supports exceptions, coroutines, GC, intrinsics, int128, modules, metadata, debuggers at IR level too.
- LLVM supports many archs: bare-metal that u wanted with betterC, WASM that can be useful to D as native and compatible (WASM wants add exceptions, GC). others users of LLVM adds different Passes/Filters to LLVM for parsing/optimizations and D can use it for free.

someday LLVM users will speed generating/compilation time.
probably D is better compatible with LLVM than with home DMC++. probably DMD is only one user of DMC++.
good projects for all of us such as LLVM should be supported by using/fixing it, not to reinventing own bicycle.
imo if D switches to LLVM, then we will all win.

PS
  I want to remind and waiting
  https://forum.dlang.org/post/lcrsrevmvtnbqsqktsbe@forum.dlang.org

On Thursday, 8 August 2019 at 19:39:14 UTC, a11e99z wrote:
> On Thursday, 8 August 2019 at 18:22:56 UTC, Atila Neves wrote:
>> On Thursday, 8 August 2019 at 13:03:17 UTC, Exil wrote:
>>> On Thursday, 8 August 2019 at 00:27:03 UTC, Walter Bright wrote:

about DPP:
> dpp is a compiler wrapper that will parse a D source file with the .dpp extension and expand in place any #include directives it encounters, translating all of the C or C++ symbols to D, and then pass the result to a D compiler (DMD by default)
with transition D to LLVM probably u can interoperate with C++ sources through Clang at AST level (also D structs should be equal C++ structs/classes with full inheritance as D:Cpp or Cpp:D. classes are still garbage collected).
imo easy(0-cost) interop D and C++ is most useful feature for D future than betterC. the last one will deprecate after such interop.

On 8/8/2019 3:29 AM, Russel Winder wrote:
> On Wed, 2019-08-07 at 17:16 -0700, Walter Bright via Digitalmars-d wrote:
> […]
>>
>> Before ZTC++, C++ was a curiosity on unix platforms that was battling
>> neck-and-neck with Objective C. (The comp.lang.c++ and comp.lang.objectivec
>> newsgroups had about the same traffic volume.) After ZTC++ appeared, C++
>> boomed
>> and ObjC tanked (and was rescued from oblivion by Apple).
> 
> Being in the UNIX (well Solaris) world at the time at UCL, C++ was seen as
> interesting but in need of templates which it then got (1990) and so became
> viable, and Objective C was seen (possibly wrongly but still) as ramming
> Smalltalk and C together badly and so not viable. Someone got a few NeXT
> machines but they got put in a cupboard to gather dust: nice UI paradigm,
> useless programming platform. Macintosh had already taken hold in the HCI and
> media communities.
> 
> I was teaching C++ to first year second term (first term they did Scheme (1987
> and 1988) or Miranda (1989 onwards) undergraduates 1987 to 1992 – all dates
> ±1. We used the Glockespiel compiler because CFront was an afront, and GCC was
> not up to it. Students liked it and did very well. After 1990 anyway when we
> didn't have to do #define/void* hacks to create data structures but could use
> templates.
> 
> Of course templates with untyped parameters was an error, still not fixed in
> C++20 – apparently Concepts got pulled out again.

Templates were a very big deal for templates, but being in the trenches it was clear that C++ was a winner even without them.

The difference Zortech C++ made was:

1. it was cheap
2. it was fast
2. it was on DOS where 90% of the programming action was
3. it was adapted to the DOS near/far memory models

cfront simply fell flat on all 4 points, and only saw use on DOS with Microsoft only shops. Even Microsoft used ZTC++ internally (COM is Zortech's memory model <g>).

On Thursday, 8 August 2019 at 00:16:22 UTC, Walter Bright wrote:
> On 8/7/2019 4:33 AM, Paulo Pinto wrote:
>>> Not only that, Zortech C++ is the reason C++ itself reached

Hi Mr. Bright, I would like to talk to you about D, do you have an e-mail account?