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

331–340 of 360 posts

Re: Better C – A subset of D Programming Language

#331

Post by fluffything »

EvenThisAcronym wrote: post #164
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…

Rust does have auto; "let" and function literal parameter type inference, for a start. It just doesn't let you use it in the return type position.

`auto` is just a keyword, that's used in D and C++ to implement many many different language features.

Rust does not have

    fn foo() -> let { ... }
where

    fn foo() -> let { 0_i32 }
    let x: i32 = foo();
    fn bar() -> let { 0_f32 }
    let y: f32 = bar();
That is, you can't have an opaque function return type, that's both opaque, but simultaneously the user can name and use all interfaces from.

If you change the implementation of `bar` with such a feature to return `i32` instead, all calling code of `bar` would break. And that's precisely why Rust doesn't have D/C++'s `auto` in return position.

Re: Better C – A subset of D Programming Language

#332

Post by MaxBarraclough »

WalterBright wrote: post #39
MaxBarraclough wrote: post #29

Earlier quoted context omitted.

Hi Walter. I have two and a half questions: * Regarding the syntax of 'lazy'. It seems to me that it would make for better readability if the lazy keyword were required at the callsite, along the lines of doStuff(lazy getValueUsingExpensiveComputation()); rather than the current syntax where it's not clear at the callsite which, if any, of the arguments are lazy. C# does something similar with ref . What's the thinki…

> What's the thinking behind D's syntax? Mainly that it be easy and quick for those familiar with C and C++ to get up to speed. With C, C++, and D, you cannot really know what will happen with the argument without looking at the corresponding parameter declaration.

Got it, thanks.

Re: Better C – A subset of D Programming Language

#333

Post by dgellow »

optymizer wrote: post #306

Mr. Walter Bright, I'm late to the party here, but I hope you will see my comment. I have a lot of respect for you and Andrei, and I think D deserves much more love than it gets. I personally feel like there are too many options when it comes to D. Perhaps it would be good to double down on some combination of those options and make that widely known? As a newcomer to D, I am exposed to GC/non-GC code, dmd/llvm compi…

Yes, I completely agree, the onboarding experience is daunting. It's quite hard to understand all the moving parts and figure out which one I should care about or not.

Re: Better C – A subset of D Programming Language

#334

Post by maxsam »

WalterBright wrote: post #321
skohan wrote: post #190

Earlier quoted context omitted.

I think a lot of people would argue that many C++ features, like OO, are not strictly improvements. Also C++ is a massive language, and part of the beauty of C is it's simplicity. I think what a lot of people would want is something which maintains that simplicity, but mainly delivers on basic QOL lessons we've learned in the past 40 years, like that it's nice not to have to pass around array lengths as separate vari…

> part of the beauty of C is it's simplicity. True, but the trouble with simplicity is a number of things become excessively tedious and error-prone to code - such as ensuring no buffer overflows. C makes up for its lack of expressivity by adding a text preprocessor. The preprocessor is a tacit admission that the core language simply isn't powerful enough. When people find themselves doing metaprogramming with the C…

> its metaprogramming facilities far outstrip the C preprocessor.

...and are severely crippled by applying betterC constraints to CTFE:

  // CTFE-only
  string genint(string name) {
      return "int " ~ name ~ ";";
  }

  void main() {
      mixin(genint("x"));
  }
Error: array concatenation of expression "int " ~ name ~ ";" requires the GC which is not available with -betterC

Re: Better C – A subset of D Programming Language

#335

Post by kreco »

WalterBright wrote: post #326
kreco wrote: post #281

Earlier quoted context omitted.

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…

> 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 unrelated opinion, I had to rant), I'm not good at spending time to rephrase when the end content is the same.

I remember one time I spent the whole day browsing the website of D, everything actually make sense. There are still features that I wouldn't use, but this is what I expect from a programming language design. I was impressed by a lot of decisions.

I seemed to remember that I was a bit sad to not find proper performance benchmarks against other languages. I was intrigued because the documentation was so complete, it was just lacking this (maybe I just couldn't find them). It was a long time ago so it has probably been fixed. I will give it a try at some point.

Re: Better C – A subset of D Programming Language

#336

Post by kreco »

dgellow wrote: post #317
kreco wrote: post #281

Earlier quoted context omitted.

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…

Did you reach Zig’s developer regarding the issues you mention? The language isn’t stable yet, good time to try to influence it if you think they are doing some mistake.

I'm not interested in spending time fixing something that is not considered broken by someone else. They are not bugs that have been introduced by mistakes.

Don't get me wrong, I like to help people. But I learnt to not help people that do not seek help.

You get a plumber fixing your pipes because you need your pipes to be fixed, but if every single plumbers were offering there help it would be annoying.

There are already more that three hundreds proposals:

https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...

A lot of them are about the syntax. Maybe this won't be endless but I'm sure a lot of time are being wasted. The root of the issue I point seems to be bound to the way the devs are working. Not sure if it will be efficient to tell them to "think more carefully". I do believe my time can be more profitable elsewhere (like commenting here, ah ah).

Re: Better C – A subset of D Programming Language

#337

Post by asdkjh345fd »

aldacron wrote: post #311
asdkjh345fd wrote: post #302

Earlier quoted context omitted.

Yes, the type is very interesting to know. That's why other languages make it known. Ignoring the entire discussion to reply twice with "nu uh!" is not very productive.

There's usually no reason to know the return type of any range-based function in D. It's not like auto is applied as a return type willy nilly. And anyone who understands D's ranges and how they are used should have no problem seeing a function declaration that returns auto.

Right, the entire world is wrong because you can't admit a fault in a random piece of software you are emotionally invested in. Makes sense.

Re: Better C – A subset of D Programming Language

#338

Post by sitkack »

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.

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 random job who hasn't upgraded to better technology (◔_◔). Where if I show someone how to use a constraint solver to optimize something, or how to run a quick Monte Carlo simulation to test a hypothesis, those folks will have a huge advantage over the C89 slinging autobot. The only reason to learn "popular tech" is to hide within a flock of nameless cogs.

Re: Better C – A subset of D Programming Language

#339

Post by lumberjackstian »

WalterBright wrote: post #58
lumberjackstian wrote: post #50

Earlier quoted context omitted.

Relevant post in a discussion thread that's related to the future of lazy in D: https://forum.dlang.org/post/ngkvntcrfdbsnxzfmcky@forum.dlan...

Yeah, lazy is a failure. Can't hit a homer every time. I'm not sorry we tried it. But it's time to take it behind the woodshed.

Why is lazy a failure and what makes it so?

And are there any languages where lazy is not a failure in your opinion?

Edit: removed link to wrong swift feature proposal.

Re: Better C – A subset of D Programming Language

#340

Post by aldacron »

asdkjh345fd wrote: post #337
aldacron wrote: post #311

Earlier quoted context omitted.

There's usually no reason to know the return type of any range-based function in D. It's not like auto is applied as a return type willy nilly. And anyone who understands D's ranges and how they are used should have no problem seeing a function declaration that returns auto.

Right, the entire world is wrong because you can't admit a fault in a random piece of software you are emotionally invested in. Makes sense.

Not quite. I'm saying that in this case it doesn't matter because of the way the API is used. Is it confusing for people who don't understand D ranges? Yes, it certainly can be. It was for me when ranges first came along. But once you understand how D ranges are intended to be used, then you realize you rarely ever care what the return type is. D is not Rust, or C++, or (insert language here).

When the return type actually matters, auto should be avoided unless there's no way around it. But that's why we have "Returns:" in Ddoc. The function signature itself is not the complete documentation. I mean, you're acting like all D functions are documented to return auto. They aren't. It's used where it needs to be.

Post reply on HN