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

101–110 of 360 posts

Re: Better C – A subset of D Programming Language

#101

Post by schaefer »

smallstepforman wrote: post #91
pron wrote: post #15

Earlier quoted context omitted.

Mine is Zig.

Andrew needs to radically change his stance on Tabs for the language to be taken seriously. White space must be ignored, and Andrew should overlook his personal bias and cater to the ‘preserve white space’ crowd. Because formatting and readability matter - a lot.

You refer to "Andrew's stance on tabs" without being specific or providing a reference, so I wend digging for more details in the language FAQ.

From the reference I found[1], Andrew's stance is: The current zig tooling forces spaces instead of tabs because the tooling for the language is not yet complete. The self hosted compiler (which the community will start using just as soon as it's ready) already does accept both tabs and spaces.

So, I'm not able to understand your complaint at all. Perhaps you could you elaborate, provide a reference, or soften your stance?

[1]: https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m...

Re: Better C – A subset of D Programming Language

#102

Post by oconnor663 »

neutronicus wrote: post #64
skohan wrote: post #34

Earlier quoted context omitted.

Yeah I think "better C" is a space which has a really good reason to exist and I'm always interested to see new entrants. IMO describing Rust as a "C replacement" is slightly off the mark because Rust's value proposition is very different from C. Rust is about giving you the best possible performance in a safe-by-default language. C is about giving you maximal control over memory, with a very thin layer of abstractio…

Rust is essentially C++ with auto-generated Move Constructors, and compiler errors on use-after-move, at the cost of preventing library developers from providing function overloads that eat temporaries as an optimization. So, yeah, really not a C replacement at all imo

I'm not super familiar with r-value references, but doesn't passing-by-value in Rust do essentially the same thing as that optimization does in C++?

Re: Better C – A subset of D Programming Language

#103

Post by stcredzero »

skocznymroczny wrote: post #33
F-0X wrote: post #3

One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…

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…

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 build time).

It's 2020. Why couldn't things work like this, where one can open a window for a concrete type using templates, and it shows the code?

Re: Better C – A subset of D Programming Language

#104

Post by skocznymroczny »

scott_s wrote: post #96
gmueckl wrote: post #24

Earlier quoted context omitted.

The use of Auto is requires in some places because the standard library returns types that cannot be named in the context of the calling function. This happens for example with algortihms that return a custom Range implementation that is declared within the scope of the function implementing the algorithm. I am not sure what to make of this pattern. At least the documentation should be more explicit about these Volde…

Is Range a kind of interface? If yes, then wouldn't that be the appropriate return type? edit: Looking at other answers, I think Range is probably not an interface like they exist in Java, but rather a pattern of behavior per templates in C++. Concepts are supposed to solve this problem in C++, but I don't know how well they actually do.

In D, you don't declare that a type X should have operations A, B, C. Instead, at the moment of template instantiation, you can verify if the provided type has operations A, B and C.

Re: Better C – A subset of D Programming Language

#105

Post by skocznymroczny »

MaxBarraclough wrote: post #88
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.

Sutter made that point under Maintainability and robustness . Like Sutter's answer, this point doesn't answer the complaint. People on the anti- auto side say it seriously harms readability, as locals' types are no longer clear at a glance. They aren't asking for a list of reasons why some people favour auto , they're asking for an answer to their readability problem. Perhaps IDEs could infer types and display them a…

In IDE-friendly languages like Kotlin, you can enable showing of inferred types, e.g. https://i.stack.imgur.com/tiqjc.png

Re: Better C – A subset of D Programming Language

#106

Post by anaphor »

WalterBright wrote: post #16
F-0X wrote: post #3

One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…

It's helpful to bring up issues you are encountering in the D forums. This is the first I've heard of this particular one.

I had this issue last year when I started learning D. I eventually got used to it, but it was a stumbling block at first. The #d IRC channel helped me out.

Re: Better C – A subset of D Programming Language

#107

Post by jfkebwjsbx »

GoblinSlayer wrote: post #82
MaxBarraclough wrote: post #20

Earlier quoted context omitted.

In the interests of perpetuating this endless flamewar, here's Herb Sutter saying C++ programmers should use auto 'by default'. (I see my snarky comment there got no reply.) https://softwareengineering.stackexchange.com/a/180616/

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.

Re: Better C – A subset of D Programming Language

#108

Post by jfkebwjsbx »

MaxBarraclough wrote: post #20
ahartmetz wrote: post #9

Earlier quoted context omitted.

Ugh, that is even more ill-advised than using auto without good reason in C++.

In the interests of perpetuating this endless flamewar, here's Herb Sutter saying C++ programmers should use auto 'by default'. (I see my snarky comment there got no reply.) https://softwareengineering.stackexchange.com/a/180616/

Herb Sutter is biased. He works on C++ language lawyering, he works on new features, he works in the STL, etc.

People like him tend to be biased about using auto because they write mostly libraries and generic ones at that (data structures, for instance).

In most code out there you actively avoid templates if possible, so that code is concrete, compiles faster and is easier to debug.

Re: Better C – A subset of D Programming Language

#109

Post by rakoo »

sgt wrote: post #14

D is pretty exciting. Seems like a perfect choice for those of us looking for an alternative systems programming language and are not completely convinced we'll be happy in Rust.

I'm not looking for an alternative to C but I used this quarantine to start nim, and it feels quite right until now

Re: Better C – A subset of D Programming Language

#110

Post by jhoechtl »

asdkjh345fd wrote: post #70
jcelerier wrote: post #57

Earlier quoted context omitted.

no ? there are plenty of maps which don't return something which looks like [a] -> [b].

So? They still have a type, it doesn't have to be "screw you figure it out yourself". Functor f => (a -> b) -> f a -> f b

Repeating the same over and over again doesn't make it any clearer for the ones trying to follow your line of argumentation.

Seems like you had some deep exposure to Haskell, ML or Hindley-Milner in general which, when excessively consumed, detaches from reality.

For one reason or the other you take this discussion serious and personal.

Post reply on HN