Better C – A subset of D Programming Language • Hacker News Board

Re: Better C – A subset of D Programming Language

#211

Post by jimbob45 » Tue, Apr 28, 2020, 5:08 PM UTC

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 vehemently disagree. Auto/var is a tool that may be used judiciously by your userbase. This new philosophy of blocking your users from using dangerous tools because you know better than them just invites workarounds and kludges. Give the user the tools and warn them of the ways it can go wrong. There's a reason Rust is losing the war to C++.

Anyways, var/auto is critical in some cases. C#'s LINQ, for example, would be very difficult to develop with if you had to manually figure out the type you were returning with long queries every time you wanted to restructure your query.

Re: Better C – A subset of D Programming Language

#212

Post by arunc » Tue, Apr 28, 2020, 5:09 PM UTC

For me the single best feature that stands out in D is the uniform member access using dot.

- Want to access member in a aggregate (class/struct)? Use .

- Want to access member in pointer to an aggregate? Use .

- Want to access member in a module? Use .

- Want to access reference (not free standing)? Use .

This makes switching between different implementations pretty easy. Coupled with UFCS, this is pretty fantastic!

Re: Better C – A subset of D Programming Language

#213

Post by gmueckl » Tue, Apr 28, 2020, 5:10 PM UTC

the8472 wrote: post #200

schveiguy wrote: post #187

Earlier quoted context omitted.

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…

In rust this would be expressed as multiple impl blocks with different generic parameters which show up as such in the documentation. https://doc.rust-lang.org/std/vec/struct.Vec.html#implementa...

This looks insane, mostly because there must be some repeated code in all these impls.

The D way of solving this is to statically query the properties of the passed in type at compile time whenever a part of the template needs to be specialized. It can make for very concise code, but you can't name the exact input type with this approach.

Re: Better C – A subset of D Programming Language

#214

Post by dgellow » Tue, Apr 28, 2020, 5:10 PM UTC

lostmsu wrote: post #198

dgellow wrote: post #193

Earlier quoted context omitted.

I checked your link, each function has a “Returns:” section that describe what to expect. Isn’t that what you want from a documentation?

A type is much denser, than a textual description, and in most cases sufficient.

Depends the type, it can be quite long and complicated. I always have a lot of issues trying to read return types from templated functions in C++ because they look really messy.

Re: Better C – A subset of D Programming Language

#215

Post by schveiguy » Tue, Apr 28, 2020, 5:16 PM UTC

the8472 wrote: post #200

schveiguy wrote: post #187

Earlier quoted context omitted.

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…

In rust this would be expressed as multiple impl blocks with different generic parameters which show up as such in the documentation. https://doc.rust-lang.org/std/vec/struct.Vec.html#implementa...

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, so I just gave up and wrote multiple functions without generics.

I'm sure some people find this documentation helpful, but it doesn't look as useful to me as map's simple one-liner.

Re: Better C – A subset of D Programming Language

#216

Post by benibela » Tue, Apr 28, 2020, 5:20 PM UTC

Koshkin wrote: post #179

benibela wrote: post #169

Earlier quoted context omitted.

I use Pascal as better C

Pascal is not better, it's just more verbose.

Pascal is better, because it has an actual string type that can store \0 characters, and a boolean type, and reference-counted dynamic arrays, and set types, and ranges in case statements (that makes it less verbose!), and a for loop that can go to MAXINT without overflow

Re: Better C – A subset of D Programming Language

#217

Post by thesuperbigfrog » Tue, Apr 28, 2020, 5:22 PM UTC

jbverschoor wrote: post #98

arunc wrote: post #76

Earlier quoted context omitted.

Vim vs emacs, auto inference vs explicit, I don't think it will ever end. :)

Aren't there any type synthesizers which modify your code based on inferenced types?

Isn't that called weak typing? (https://en.wikipedia.org/wiki/Strong_and_weak_typing#Definit...)

Re: Better C – A subset of D Programming Language

#218

Post by ynx » Tue, Apr 28, 2020, 5:23 PM UTC

jimbob45 wrote: post #211

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 vehemently disagree. Auto/var is a tool that may be used judiciously by your userbase. This new philosophy of blocking your users from using dangerous tools because you know better than them just invites workarounds and kludges. Give the user the tools and warn them of the ways it can go wrong. There's a reason Rust is losing the war to C++. Anyways, var/auto is critical in some cases. C#'s LINQ, for example, would…

But they were talking about _docs_.

Re: Better C – A subset of D Programming Language

#219

Post by TwoBit » Tue, Apr 28, 2020, 5:24 PM UTC

jimbob45 wrote: post #211

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 vehemently disagree. Auto/var is a tool that may be used judiciously by your userbase. This new philosophy of blocking your users from using dangerous tools because you know better than them just invites workarounds and kludges. Give the user the tools and warn them of the ways it can go wrong. There's a reason Rust is losing the war to C++. Anyways, var/auto is critical in some cases. C#'s LINQ, for example, would…

I disagree; you don't seem to be addressing what the parent is talking about (documentation). Whatever reason Rust is losing a war against C++ (it's really not), this isn't it.

Re: Better C – A subset of D Programming Language

#220

Post by Konohamaru » Tue, Apr 28, 2020, 5:24 PM UTC

p0nce wrote: post #130

Konohamaru wrote: post #90

Earlier quoted context omitted.

> Chain of lazy computations in D often return unnamed types (so called "Voldemort" types) because finding good names for those inner structs is a challenge There is something so absurd about having "unnamed types" as an antipattern!

Not everything is worth naming, if there isn't an obvious good name for somethink (like say, a Java Anonymous Classes) then why not allow it to have no name?

Java's objects aren't types even though they're mixed up with its type system. Objects are supposed to represent units of computation so anonymous classes aren't absurd.

But the reason why it seems that types without names are absurd is that types are only real for the interpreter or compiler. At runtime they aren't used anymore. So it's absurd that a construct made for humans to understand and describe code starts to become something opaque to human understanding because they're impossible to be named.