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

351–360 of 360 posts

Re: Better C – A subset of D Programming Language

#351

Post by guai- »

tomp wrote: post #120
FeepingCreature wrote: post #84

Earlier quoted context omitted.

D has functors, but it doesn't have 'Functor'. Or rather, D doesn't have concepts (of which 'Functor' is a special case); that is, the notion of a type that is characterized by having the ability to execute operations is not expressible in its typesystem. Or rather, it is, but only with classes. You want something like "a return type; fulfilling the condition of being able to be used in this way." This is not somethi…

What you're describing has names - structural types, refined types (a.k.a. contracts a.k.a. pre- and post-conditions)... It's simply a failure of D the language/compiler (and a huge anti-pattern) to not expose internal types in a way that can be displayed to the programmer.

java can't express its types in its own syntax either. nor scala, nor sharp.

ceylon could, but they are barely readable anyway.

Re: Better C – A subset of D Programming Language

#352

Post by GoblinSlayer »

jfkebwjsbx wrote: post #107
GoblinSlayer wrote: post #82

Earlier quoted context omitted.

Another reason for C/C++ is that they are very permissive with implicit lossy conversions. If you specified explicit type, chances are the compiler helpfully made a lossy conversion for you.

If you use only explicit constructors and ban cast operators except for the most basic of types, then you have a sane language and explicitness in your code.

It's sane on C++ scale, but on absolute scale that sanity is still wanting, Sutter mentions this.

Re: Better C – A subset of D Programming Language

#353

Post by dllthomas »

strbean wrote: post #285
pjmlp wrote: post #242

Earlier quoted context omitted.

Not really, hence why I mentioned 1992. C has had plenty of time to catch up, but apparently it wasn't something that WG14 cared about. And it is not like many aren't actually coding in GCC C, Clang C, TI C, xlc C, aC C and so on. Which even with those C extensions fail on the security story.

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.

From an educational standpoint, C89 is a bit further from modern languages, so might be a better call on that basis. If you know C89 and some recent languages, you can probably roll forward to C99 or C11 without much trouble. If you started with C11, and haven't every worked in something from the 80s... well, that's an education.

> C99 block scoped variables free up stack space

I'm not sure that's actually true. Or at least if it is, I think it's the choice of a particular implementation. The compiler doesn't actually need to allocate anything until first use, and nothing prevents it from hoisting allocations earlier.

Re: Better C – A subset of D Programming Language

#354

Post by Koshkin »

dllthomas wrote: post #353
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.

From an educational standpoint, C89 is a bit further from modern languages, so might be a better call on that basis. If you know C89 and some recent languages, you can probably roll forward to C99 or C11 without much trouble. If you started with C11, and haven't every worked in something from the 80s... well, that's an education. > C99 block scoped variables free up stack space I'm not sure that's actually true. Or a…

It's actually true - in the sense that at the end of the block the part of the stack frame used by the variables defined in it becomes available for reuse (which is normally done at compile time).

Re: Better C – A subset of D Programming Language

#355

Post by dllthomas »

Koshkin wrote: post #354
dllthomas wrote: post #353

Earlier quoted context omitted.

From an educational standpoint, C89 is a bit further from modern languages, so might be a better call on that basis. If you know C89 and some recent languages, you can probably roll forward to C99 or C11 without much trouble. If you started with C11, and haven't every worked in something from the 80s... well, that's an education. > C99 block scoped variables free up stack space I'm not sure that's actually true. Or a…

It's actually true - in the sense that at the end of the block the part of the stack frame used by the variables defined in it becomes available for reuse (which is normally done at compile time ).

Hmm, I think I might've misread, but I interpreted what was being asked for the ability to mix declarations and statements, as C99 allows. If what's being asked for is simply the ability to declare variables at the top of blocks, I think that's allowed in C89? Certainly GCC and clang both allow it without warning with -std=c89 and -pedantic. I agree that there are cases where enclosing a variable in a block will allow earlier reuse of the memory that backs it.

Re: Better C – A subset of D Programming Language

#356

Post by Koshkin »

dllthomas wrote: post #355
Koshkin wrote: post #354

Earlier quoted context omitted.

It's actually true - in the sense that at the end of the block the part of the stack frame used by the variables defined in it becomes available for reuse (which is normally done at compile time ).

Hmm, I think I might've misread, but I interpreted what was being asked for the ability to mix declarations and statements, as C99 allows. If what's being asked for is simply the ability to declare variables at the top of blocks, I think that's allowed in C89? Certainly GCC and clang both allow it without warning with -std=c89 and -pedantic. I agree that there are cases where enclosing a variable in a block will allo…

I don't think that the mixing of definitions and statement has any effect on how the stack frame space is (re)used: even if all variable definitions are collected at the beginning of the block, it may still be possible for the compiler to find the points inside the block after which some of the variables are no longer used while some others are brought into action; such variables could, then, share the same space despite having the same lexical scope.

Re: Better C – A subset of D Programming Language

#357

Post by kreco »

WalterBright wrote: post #347
kreco wrote: post #335

Earlier quoted context omitted.

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…

> 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.

Oh, this is pretty sad...

Anyway thanks for your time. Was nice to interact with the author of D. I truly believe what you've done will inspire a lot of people.

I hope you didn't encounter too many people saying creating D was foolish.

I spent time checking about a lot of languages and only D (and Jai, but it's not released) would restore my joy of programming.

Re: Better C – A subset of D Programming Language

#358

Post by pjmlp »

skocznymroczny wrote: post #238
stcredzero wrote: post #103

Earlier quoted context omitted.

Personally I dislike var/auto in languages because I like having types explicitly written. But in case of languages like Java or Kotlin you can move the cursor over the variable name and you will see the type, also you can right-click and select "replace with explicit type" and it will work. In D, IDEs struggle with templates and can rarely index templated code (no wonder, because most of the code doesn't exist until…

Templates don't exist until compile time, until you build the code, the IDE plugin doesn't have the full data on what types exactly are there. Java/C# generics are more limited in functionality, but it's a tradeoff in exchange for better ahead of time knowledge of types.

Visual Studio can do that, you just provide an example type and the IDE shows what the result would be.

https://devblogs.microsoft.com/cppblog/template-intellisense...

Now try that on vim.

Re: Better C – A subset of D Programming Language

#359

Post by strbean »

dllthomas wrote: post #355
Koshkin wrote: post #354

Earlier quoted context omitted.

It's actually true - in the sense that at the end of the block the part of the stack frame used by the variables defined in it becomes available for reuse (which is normally done at compile time ).

Hmm, I think I might've misread, but I interpreted what was being asked for the ability to mix declarations and statements, as C99 allows. If what's being asked for is simply the ability to declare variables at the top of blocks, I think that's allowed in C89? Certainly GCC and clang both allow it without warning with -std=c89 and -pedantic. I agree that there are cases where enclosing a variable in a block will allo…

I misremembered my C89 gripe! The issue was that the following is not allowed:

    for (int i = 0; // ...
Forcing you to write

    int i;
    for (i = 0; // ...
The real annoyance here is that you can't restrict the scope of a variable you need initialized at the start of a for loop to the loop block. It's all fine and dandy when you are just using `i` (and never miss resetting it, or use it somewhere expecting it to be one thing and have it end up being another). When you have several complex loops in a function, it can be a bit aggravating.

(Declaring variables willy nilly anywhere in a block is nice too)

Re: Better C – A subset of D Programming Language

#360

Post by dllthomas »

strbean wrote: post #359
dllthomas wrote: post #355

Earlier quoted context omitted.

Hmm, I think I might've misread, but I interpreted what was being asked for the ability to mix declarations and statements, as C99 allows. If what's being asked for is simply the ability to declare variables at the top of blocks, I think that's allowed in C89? Certainly GCC and clang both allow it without warning with -std=c89 and -pedantic. I agree that there are cases where enclosing a variable in a block will allo…

I misremembered my C89 gripe! The issue was that the following is not allowed: for (int i = 0; // ... Forcing you to write int i; for (i = 0; // ... The real annoyance here is that you can't restrict the scope of a variable you need initialized at the start of a for loop to the loop block. It's all fine and dandy when you are just using `i` (and never miss resetting it, or use it somewhere expecting it to be one thin…

Ah, yeah. There shouldn't be any runtime difference if you don't leak the address of `i` somewhere the compiler can't see, which should be uncommon for an iterator. But I agree it's awkward.

You can wrap the whole thing in an extra block, so at least you don't have to hoist `i` to the top of the function.

> (Declaring variables willy nilly anywhere in a block is nice too)

You can always introduce another block, although it's not uncommon that that's harder on legibility than just hoisting.

Post reply on HN