On Saturday, 31 October 2020 at 20:17:02 UTC, Stefan Koch wrote:
> On Saturday, 31 October 2020 at 19:31:56 UTC, bachmeier wrote:
>> On Saturday, 31 October 2020 at 17:18:30 UTC, Dibyendu Majumdar wrote:
>>
>>> Zig seems like a copy of Jai.
>>
>> How do you copy vaporware? Or has there been a release of a single line of compileable Jai that I missed?
>
> It is not vaporware.
> It is in closed beta right now.

While there is no official body that determines if something is vaporware, my usage is very much consistent with Perl 6, which was the most famous application of the term to a programming language. Heavy hype, excitement over new features, claims progress is being made, and a belief that there will eventually be a release. It has been more than six years (assuming Wikipedia is accurate) and we only have continued promises that Jai will eventually be released. Here is an article from early 2007 talking about Perl 6 as vaporware, and the label was surely used long before that: https://www.techrepublic.com/blog/geekend/transition-from-perl-5x-to-perl-6/

The most important lesson to be learned from the vaporware version of Perl 6 is not that there won't be a release (it was) but that the release won't be the same as the promise. Until Jai is released we can only talk about Jonathan Blow's ideas. An idea without an implementation is as useful as a car without gas.

On Sunday, 1 November 2020 at 01:46:33 UTC, bachmeier wrote:
> That wouldn't make Zig an implementation, not a copy.

I can see why someone would think Zig is inspired by Jai, though. Zig appears to focus on not having any "magic", so that the source is explicit. Not a reasonable design rationale IMO. Properties and exceptions are useful abstractions.

What all these languages have in common is that they are opinionated, but don't bring anything significantly new to table vs C++, except Rust.

So what we end up with is many front ends to LLVM, sketchy interop and starving eco systems...

On Sunday, 1 November 2020 at 02:14:00 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 1 November 2020 at 01:46:33 UTC, bachmeier wrote:
>> That wouldn't make Zig an implementation, not a copy.
>
> I can see why someone would think Zig is inspired by Jai, though. Zig appears to focus on not having any "magic", so that the source is explicit. Not a reasonable design rationale IMO. Properties and exceptions are useful abstractions.
>
> What all these languages have in common is that they are opinionated, but don't bring anything significantly new to table vs C++, except Rust.
>
> So what we end up with is many front ends to LLVM, sketchy interop and starving eco systems...

And Rust buzz has made everyone start looking at ways to integrate affine types alongside automatic memory management, leaving that for hot paths.

So in the end, we that love systems languages with some for of GC will keep our eco-systems, have a couple of extra language features for those 1% use cases that they really matter instead of writing Assembly or what have you, and only the religiously anti-GC crowd might actually keep caring about languages like Rust and C++.

Even C has issues with adoption among some embedded domains where the community is focused on C89 with OEM extensions and doesn't care about anything else.

What D really misses are systems like Oberon, Singularity, Midori, but sadly that is a corporation level effort.

Just something like this would already shut many mouths.

http://www.progtools.org/article.php?name=oberon&section=compilers&type=tutorial

--
Paulo

On Sunday, 1 November 2020 at 01:26:28 UTC, Walter Bright wrote:
> On 10/31/2020 9:22 AM, Paulo Pinto wrote:
>> On Saturday, 31 October 2020 at 01:57:19 UTC, Walter Bright wrote:

> Those are not natively compiled languages, and the compiler is part of the runtime.
>

How is that relevant? There are natively compiled Lisps. Also, to compile D at runtime, you need a D compiler as part of the runtime environment. If you insist on singling out one language that popularized CTFE, Lisp would be a much fairer choice.

On Sunday, 1 November 2020 at 07:27:09 UTC, Paulo Pinto wrote:
> On Sunday, 1 November 2020 at 02:14:00 UTC, Ola Fosheim Grøstad wrote:
> of writing Assembly or what have you, and only the religiously anti-GC crowd might actually keep caring about languages like Rust and C++.

C++ is slowly taking over embedded. Most languages suitable for interactive applications use frameworks built with C++. So, better interop with C++ is important for tiny languages.

For most servers C++ is becoming less important thanks to cloud computing.

On Thursday, 29 October 2020 at 14:28:58 UTC, Mike Parker wrote:
> On Thursday, 29 October 2020 at 11:50:12 UTC, Dibyendu Majumdar wrote:
>
>>
>> I was wondering if it worthwhile branding -betterC differently - e.g. use a brand such as 'micro-D' or some nicer name. That is, give it a new identity that highlights that it not just better C  - but a D version without GC.
>
> I think it's a bad, bad, bad idea to put any emphasis on BetterC other than as a tool to help in porting C or C++ code to D, or to integrate D into existing C and C++ projects. I see too many people reaching for it first thing, probably out of a misguided GC phobia. D is the language we need to be promoting. BetterC was intended for a specific purpose. Beyond that, it's a crippled D. If some people prefer to use it that way, fine, but we shouldn't encourage it.

I use BetterC in my products (car engine/gearbox parts) targeting ARM Cortex MCUs, but once I get a lightweight D runtime up I intend to switch to that.

I think such a thing could reduce reliance on BetterC and allow for quicker easing into full D.

Given it's a real time environment I'm thinking that Phobos allocations will be tracked in a stack like structure per thread and can then be freed at a later, convenient opportunity or immediately after the Phobos call ends.

I could see about making some sort of small scale GC but that's currently out of my depth.

On Sunday, 1 November 2020 at 01:26:28 UTC, Walter Bright wrote:
> On 10/31/2020 9:22 AM, Paulo Pinto wrote:
>> On Saturday, 31 October 2020 at 01:57:19 UTC, Walter Bright wrote:
>>> On 10/29/2020 5:48 AM, Abdulhaq wrote:
>>>> I'm pretty sure that Jai is not mimicking D, also I doubt that Zig is either.
>>>
>>> D popularized CTFE, and other languages followed suit, including Jai.
>> 
>> Sorry but that flag belongs to Lisp and Dylan macros, Java compiler plugins, Java/.NET manipulation of attributes/annotations
>
> Those are not natively compiled languages, and the compiler is part of the runtime.
>
>> and C++ template meta-programing.
>
> Having implemented a full C++ compiler, I don't agree:
>
> 1. it was discovered as a side effect, not designed
> 2. it does not do iteration
> 3. it only does integers - not floating point, not strings, not pointers
> 4. it cannot allocate memory
> 5. it is incredibly limited
> 6. it cannot call or execute a single C++ function
> 7. C++ template metaprograms are limited to trivial ones, due to fundamental problems with it
>
> and, most tellingly,
>
> 8. C++ has gone on to copy D's CTFE
>
>> D CTFE has definitely a very important value, but not everything that other languages adopt was created by D.
>
> I did say popularized, not created. To round this out a bit, the C preprocessor can do compile time computation, too, but to compare it to D's CTFE is like comparing the pre-existing electric arc lamp to to Edison's incandescent bulb, and saying the bulb wasn't revolutionary.

I respect both Paulo's and Walter's opinion, but speaking as a single data point I think Walter is right here in that D has been very influential regarding CTFE in the C universe - I say that as someone for whom Lisp was one of the first languages I learnt, sitting as a teenager in the library, together with PL/1! I later managed to get my hands on an actual physical computer and progressed (ha!) to the dizzy heights of BASIC and Z80 assembly. Seeing as I'm on the topic, 68000 was a blessing, 1980s C++ was a curse, Delphi was a blessing, MFC was a curse, dBase was, well...., now we have python, C++11, D, modern Java, all good, DHTML, node.js, CSS argh please no. What next we ask ourselves...

On Sunday, 1 November 2020 at 01:26:28 UTC, Walter Bright wrote:
> On 10/31/2020 9:22 AM, Paulo Pinto wrote:
>> On Saturday, 31 October 2020 at 01:57:19 UTC, Walter Bright wrote:
>>> On 10/29/2020 5:48 AM, Abdulhaq wrote:
>>>> I'm pretty sure that Jai is not mimicking D, also I doubt that Zig is either.
>>>
>>> D popularized CTFE, and other languages followed suit, including Jai.
>> 
>> Sorry but that flag belongs to Lisp and Dylan macros, Java compiler plugins, Java/.NET manipulation of attributes/annotations
>
> Those are not natively compiled languages, and the compiler is part of the runtime.


Sure they are, one just needs to make use of the existing AOT compilers, including Java and .NET. Maybe time to actually learn about those platforms?

Java world is not the same as during Visual Caffe days.

Secondly, those features don't require shipping the compiler on the runtime.

>
>> and C++ template meta-programing.
>
> Having implemented a full C++ compiler, I don't agree:
>
> 1. it was discovered as a side effect, not designed
> 2. it does not do iteration
> 3. it only does integers - not floating point, not strings, not pointers
> 4. it cannot allocate memory
> 5. it is incredibly limited
> 6. it cannot call or execute a single C++ function
> 7. C++ template metaprograms are limited to trivial ones, due to fundamental problems with it
>
> and, most tellingly,
>
> 8. C++ has gone on to copy D's CTFE
>
>> D CTFE has definitely a very important value, but not everything that other languages adopt was created by D.
>
> I did say popularized, not created. To round this out a bit, the C preprocessor can do compile time computation, too, but to compare it to D's CTFE is like comparing the pre-existing electric arc lamp to to Edison's incandescent bulb, and saying the bulb wasn't revolutionary.

You have implemented a C++ compiler in the old ISO C++98 days, many of your posts regarding C++ seem to be out of date with what ISO C++20 looks like.

I usually see some of this recurring statements that D popularized something, that anyone with IEEE or ACM/SIGPLAN account can easily find otherwise.

This only makes a disservice to D's credibility among those with CS knowledge in programming language design, one of my majors, hence why I tend to get sidetracked who did what.

--
Paulo

On Sunday, 1 November 2020 at 09:58:39 UTC, Paulo Pinto wrote:
> I usually see some of this recurring statements that D popularized something, that anyone with IEEE or ACM/SIGPLAN account can easily find otherwise.

Well, yes, D and Rust are not popular so they cannot popularize anything.

But it is true that some of the designers of system-oriented languages that came after D has looked at D's feature set for inspiration. I believe that applies to Go, Nim, Zig, Jai… What they took away from it, who knows?

And some C++ proposals have been informed by D, e.g. the one on ranges. Although some of D's features were first proposed for C++, even though D implemented them first.

A very tangled web.

On 2020-11-01 11:25, Ola Fosheim Grøstad wrote:

> But it is true that some of the designers of system-oriented languages that came after D has looked at D's feature set for inspiration. I believe that applies to Go, Nim, Zig, Jai… What they took away from it, who knows?

As far as I know, there's only one language that has taken a feature from D and gave it credit, that's Swift. The feature is how it handles special symbols like __FILE__ and __LINE__, when they're used as default arguments [1].

[1] https://developer.apple.com/swift/blog/?id=15

-- 
/Jacob Carlborg