Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better C – A subset of D Programming Language

dlang.org

Post reply on HN
Print view View original

341–350 of 360 posts

Re: Better C – A subset of D Programming Language

#341

Post by kazinator »

The problem is that since this Better C is not compatible with any C dialects, and requires a D compiler, there is no reason to restrict D programs to this subset. At least no reason that is related to simply working in something better than C. The real reasons can be articulated better, starting with a different name, like "Reduced D" (D that avoids garbage collection, exceptions and/or has a smaller footprint or whatever). How about "Dm": D Minor: a sad subset of D.

A subset of C++ is a better C, that can be written in such a way that C compilers translate it, so that is meaningful. Well, at least a slightly better C, anyway.

Re: Better C – A subset of D Programming Language

#342

Post by kazinator »

schveiguy wrote: post #187
fluffything wrote: post #116

Earlier quoted context omitted.

I'm glad that Rust has no `auto`. I find this: fn map (it: I) -> impl Iterator where I: Iterator , U: From { it.map(|t| From::from(t)) } infinitely more readable than fn map (it: I) -> auto where I: Iterator , U: From { it.map(|t| From::from(t)) } The type signature of the first one clearly tells me that the return type is an `Iterator `, even though the actual type cannot be named because of the anonymous closure. T…

This wouldn't work for D. D doesn't constrain return types to something less than what they are. A Range is not just an Iterator, it has optional pieces that depend completely on the given type. For example, the return of map could provide indexing, or it could provide forward and backward iteration, or it might have methods that are completely unrelated to the type. There is no good reasonable and non-confusing way…

Though it doesn't work for D, it could work for the documentation of D (what is being discussed), in some usefully hand-wavy way.

If I'm working in a typed language, and are dealing with functions max(a, b, c) and list(a, b, c), I would expect the documentation to say that one returns T, whereas the other a list(T). If it says auto, then I'm guessing from the names.

Maybe the target audience is programmers familiar with dynamic languages, who don't care so much and are used to reading the descriptions of functions about what is returned.

Re: Better C – A subset of D Programming Language

#343

Post by [deleted] »

Dylan16807 wrote: post #318
petee wrote: post #315

Earlier quoted context omitted.

They said "A" good dev uses an ide, and a snappy 'in 2020' retort. It's plainly clear their intention is to imply only good devs use ide's in the modern era.

No, that's not how simple if statements work. I don't know what else I can say. If I say "A good CPU has more than two cores in 2020." then I'm just saying it's a requirement, not sufficient all by itself. I'm not calling a twelve-year-old phenom X3 a good CPU. The "in 2020" is just to emphasize that anyone failing this standard is falling behind the times.

[deleted]

Re: Better C – A subset of D Programming Language

#344

Post by AndyKelley »

kreco wrote: post #281
snazz wrote: post #260

Earlier quoted context omitted.

Do you not like those because they're unfamiliar? What about the syntax indicates over-engineering? Here's what I see in your example: - @ indicates built-in function, which avoids namespace collisions. - Optional types via the ?, which solves the null pointer problem. - Real iterators, which are less error-prone and nicer to read than traditional for loops in a lot of common applications. - The || syntax is better t…

Thanks for spending your time explaining this. I think a lof people will understand those lines better. I actually already knew everything. I watched closely the development of Zig, and just give up when I realized all those decisions where made carelessly in my view or I just simply disagree with the direction of the syntax. Since you took your time I will take mine to address what I don't like: - There is no way to…

> The worst, no default values for struct.

This is incorrect. There are other factual errors here as well.

Re: Better C – A subset of D Programming Language

#345

Post by benibela »

sitkack wrote: post #338
strbean wrote: post #285

Earlier quoted context omitted.

At university, my classes in C required using C89. The rationale given by the professor was that he wanted us prepared for industry, and if you learn to stick to C89 you will be able to write C for any job out there. I argued that C99 block scoped variables free up stack space (pretty silly argument but true), he wasn't buying it. I think this kind of thinking is very common across the C community.

And to be clear, this kind of thinking hampers progress in the name of genericity. The ironic thing, is when someone makes that argument, they are admitting that the education they are giving creates students around the mean. When I teach someone, I try to give them a mental framework that others don't have and some unique skills that will differentiate them. Learning C89 gives someone the "most chances" of getting a…

Well, I learned the better technology (Pascal) rather than the popular tech (C), and then I could not find a development job

Re: Better C – A subset of D Programming Language

#346

Post by 1980phipsi »

masklinn wrote: post #234
schveiguy wrote: post #215

Earlier quoted context omitted.

What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"? I've dealt with generics in other languages such as Swift and C#, and they were substandard to D's templates IMO. I remember in C#, I could not get a simple generic function that accepted both a string and Int to work…

> What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"? No. The type which tells you that Vec works like a slice of T is https://doc.rust-lang.org/std/vec/struct.Vec.html#impl-Deref The others are separate abstract operations which are available (implemented) on vecs e.g…

On the "auto auto", I'm pretty sure I filed a bug report on that. There are alternate D docs that don't produce the "auto auto" (and it goes without saying that it isn't that way in the code itself).

Re: Better C – A subset of D Programming Language

#347

Post by WalterBright »

kreco wrote: post #335
WalterBright wrote: post #326

Earlier quoted context omitted.

> It's like everything has been carefully design to be even less readable than C code. D is designed to be very readable to the C programmer. Some changes, like replacing: (int)(expression) with: cast(int)(expression) is designed to make the code more readable, and greppable. Cast is a fundamentally dangerous operation, so being able to grep-and-check for such is worthwhile. The D compiler actually recognizes the C f…

Yes, I can see the design of D was made carefully. D is actually a great language. I just "don't understand" why it's not massively used instead of more recent versions of C++, I consider newer version of C++ as a totally different language with more drawbacks than advantages. Half of new features are present to fix previous half baked features. This is quite embarrassing. Sorry for my selection of words (and for the…

The performance of D vs C and C++ should be identical for code written the same way, as they share the same optimizer and code generators.

Also, we used to publish benchmarks. These inevitably did not produce illumination, but long ripostes from people arguing that the benchmark was unfair, inaccurate, nobody would write code that way, we sabotaged other languages, etc.

We encourage people to run their own benchmarks on their own code and let the results speak for themselves.

One issue with moving to D is it takes a while for people to learn "the D way". For example, if they come from C they write C style code in D. From C++, they write C++ style in D. From Python they write Python style in D. Inevitably they'll run into some difference where D doesn't have an analogous feature, and would get a bit frustrated (even though in D the task would be accomplished a different way).

It takes a bit of perseverance and faith to get through that until one discovers "the D way" and then they're hooked.

One of the reasons for DasBetterC was to reduce this issue as much as possible, though the people who like metaprogramming with the C preprocessor will have more work to do in getting adapted to D's powerful metaprogramming features, which of course work nothing like text macros.

Re: Better C – A subset of D Programming Language

#348

Post by alexhutcheson »

setpatchaddress wrote: post #204
logicchains wrote: post #67

Earlier quoted context omitted.

Ah, that's awesome! Really cool to see a new language taking compile-time so seriously.

Fast compile time isn't actually that hard for a C-like language. Good code optimization and fast compile time is hard.

Fast compile time on large projects is really hard for C and C-compatible languages due to the preprocessor and #include. Not an issue if you're comparing compilation for a single file, but it turns into a substantial fraction if your compile time when that file transitively #includes 10s or 100s of headers.

Re: Better C – A subset of D Programming Language

#349

Post by exiled13 »

WalterBright wrote: post #320
exiled13 wrote: post #295

Earlier quoted context omitted.

Rust was designed from the ground up and every feature is implemented and designed to work with its borrow checker. So it is able to provide a definitive guarantee that memory isn't free'd or used after it is free'd. The only exception is in "unsafe" code, where you can break the borrow checker. But this limits where you have to worry about potential bugs. In D, the ""borrow checker"" is being tacked on as an after t…

D's version of Ownership/Borrowing adheres to the notion: "only one mutable reference to a mutable object OR many const references to an object" and that's where the similarity to Rust begins and ends. The realization of that principle is quite different.

Rust guarantees memory safety, or are you saying D isn't similar in that regard as well? If that's what you are saying, then I agree completely. D's ownership/borrowing does not provide memory safety, and that makes it pretty much useless.

There's really no point discussing this with you any further. You don't contribute anything to the discussion. That's just PR babble, and provides zero information and doesn't even deny the fact that exceptions break memory safety with D's borrow checker (you know it that's why you don't deny it like a "good" PR person).

Re: Better C – A subset of D Programming Language

#350

Post by sitkack »

benibela wrote: post #345
sitkack wrote: post #338

Earlier quoted context omitted.

And to be clear, this kind of thinking hampers progress in the name of genericity. The ironic thing, is when someone makes that argument, they are admitting that the education they are giving creates students around the mean. When I teach someone, I try to give them a mental framework that others don't have and some unique skills that will differentiate them. Learning C89 gives someone the "most chances" of getting a…

Well, I learned the better technology (Pascal) rather than the popular tech (C), and then I could not find a development job

I am going to weaken my argument a bit and say that once something gets to be a large enough part of status quo, you have to learn it, at least enough to get by. Back then it was C, now it is JavaScript, Python and Kubernetes.
Post reply on HN