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

181–190 of 360 posts

Re: Better C – A subset of D Programming Language

#181

Post by shrimpx »

harikb wrote: post #167
kevin_thibedeau wrote: post #128

Earlier quoted context omitted.

A well designed language should be usable from a text editor. Even in 2020.

I agree. I will paraphrase this as - a well designed language should be usable, at minimum, from a pure text editor, and should not put unreasonable burden on an IDE.

The cynic in me wants to say that such a language doesn’t lend itself to static analysis. As soon as you can do great things with static analysis you can build those features into an IDE, therefore causing the “pure text editor” to feel crippled giving rise to the idea that this language is “unusable from a pure text editor”.

Re: Better C – A subset of D Programming Language

#182

Post by lumberjackstian »

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…

I've felt this as well, been using D for a couple years now, and this is the kind of thing that just makes me have to context switch more than I'd like. With the current implementation of the language it's hard to avoid, and function's return type can be quite complex, so writing it down can be hard.

Another reason is the (ironically) dynamic nature of a return type. E.g.

auto whatDoesItReturn(int i)() { static if (i == 0) { return int.init; } else { return string.init; } }

Template code can do that quite easily and then you don't have a choice but to write auto as the return value.

What would be fantastic if the documentation could be given access to the the compiler's return type inference, so that it could document the auto returns with a little more info.

Another way useful approach would be to implement protocols like in swift, or traits like in scala/rust/others, signatures in ml, etc. Then you would be able to define the interface of what a function returns.

Re: Better C – A subset of D Programming Language

#183

Post by johannes1234321 »

hiq wrote: post #86
skocznymroczny wrote: post #33

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…

var/auto is a trade-off which requires good tooling support, as you said. Once you're able to see the types as you see fit in your IDE, I feel that you're mostly better off, for all the reasons already mentioned in the thread. Of course good tooling is still a big requirement, but I still think it's the best decision in the long-term: it's way easier to improve and change tools like IDEs (especially with LSP?), rathe…

In places where you need to know the exact type auto probably isn't the right choice.

There are many cases where the type is clear however or irrelevant or in generic code is hard to express (thus depending on documentation/comments unless obvious) which would also be hard to read.

Re: Better C – A subset of D Programming Language

#184

Post by hibbelig »

jerven wrote: post #151
hibbelig wrote: post #89

Earlier quoted context omitted.

In Java, `var` comes in useful at times. For example: for (Map.Entry x : someMap) { final SomeLongType key = x.getKey(); final AnotherLongType value = x.getValue(); ... } In the above code snippet, `var x` would have been very useful because the actual type just repeats information that can be found in the next two lines. Also, usually, I'll use more speaking names instead of `key` and `value`. But if the body of the…

In java 10+ for (Map.Entry x : someMap) { final var key = x.getKey(); final var value = x.getValue(); ... } Is valid.

I prefer to put "var" into the loop header because the combination of two types is hard to read. It's easier to read (for me!) when the type of the key and the type of the value are separated, like they are on the first two lines of the loop body.

    for (var x : someMap) {
        final SomeLongType key = x.getKey();
        final AnotherLongType value = x.getValue();
        ...
    }

Re: Better C – A subset of D Programming Language

#185

Post by kllrnohj »

skohan wrote: post #34
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.

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…

> However I think there are other cases where the strengths of C still add value; for instance in game development you're largely trying to do high-throughput processing over large swaths of structured data

That world is dominated by C++ for the most part, though. So D's -betterC would be fighting against an incumbent that is itself also already a "better C".

What value does D's -betterC bring to the table here? Skimming through it, it doesn't look like there's any compelling reason to switch to -betterC from an existing C++ code & knowledge base.

Re: Better C – A subset of D Programming Language

#186

Post by EvenThisAcronym »

masklinn wrote: post #180
EvenThisAcronym wrote: post #163

Earlier quoted context omitted.

Returns A range with each fun applied to all the elements. If there is more than one fun, the element type will be Tuple containing one element for each fun.

Yes, D has prosaic descriptions. So does Python. Or Ruby. Maybe read and try to understand the complaint instead of pointing out something unrelated?

I get it; you posted before reading the docs first. Don't get mad, it's okay - we've all done it. Take this as a learning experience and move on.

Re: Better C – A subset of D Programming Language

#187

Post by schveiguy »

fluffything wrote: post #116
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…

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 to describe all the things map could return depending on the input. It's much better to just describe it conceptually in the human-readable docs, and let the person understand the result.

I'll note that just above the function map in D's source is the documentation. You just need a little more context, and it will describe what map returns in a much more (IMO) useful fashion than a return type that might be several lines long and consist of various static conditionals:

"The call map!(fun)(range) returns a range of which elements are obtained by applying fun(a) left to right for all elements a in range."

This is the difference between duck typing and generics.

Re: Better C – A subset of D Programming Language

#188

Post by kibwen »

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.

That's the salient point of this thread though; Rust doesn't have type inference in any position that shows up in API documentation. (The closest thing Rust has is return types of `impl Trait`, but even that imposes a contract that the caller must adhere to and that the callee cannot see through.)

Re: Better C – A subset of D Programming Language

#189

Post by throwaway894345 »

stevefan1999 wrote: post #153
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…

Well, not everyone likes automatic type deduction -- some people just like to torment him/herself by repeating information that is unneeded. Why?

Type inference systems generally have crumby error messages, and are harder to reason about all around. The best type inference systems are those that allow inference within a function definition, but the function signature requires explicit annotation. This keeps the inference local, which is easier for humans to read about. Good tooling can make either system easier to work with, but tooling is much less important in the type annotation case because the cost of adding annotations is trivial (contrary to your "torment" vocabulary) compared to reasoning about (non-local) type inference.

In general, this reduces to the principle that concrete is easier to reason about than abstract. The type signature of an unannotated function in a type inference system is maximally abstract, while (especially in practice) the signatures for functions that are manually annotated are more concrete if not fully concrete. There are still problems in non-type-inferred systems with programmers who try to be egregiously abstract, but these are fewer and farther between.

Re: Better C – A subset of D Programming Language

#190

Post by skohan »

kllrnohj wrote: post #185
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…

> However I think there are other cases where the strengths of C still add value; for instance in game development you're largely trying to do high-throughput processing over large swaths of structured data That world is dominated by C++ for the most part, though. So D's -betterC would be fighting against an incumbent that is itself also already a "better C". What value does D's -betterC bring to the table here? Skim…

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

Post reply on HN