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

141–150 of 360 posts

Re: Better C – A subset of D Programming Language

#141

Post by dirtydroog »

jfkebwjsbx wrote: post #108
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/

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.

Bingo! Writing a template library is totally different to writing an application.

Re: Better C – A subset of D Programming Language

#142

Post by atilaneves »

Konohamaru wrote: post #90
p0nce wrote: post #18

Earlier quoted context omitted.

It's often because these functions have unnamed types. 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, they have a single use (which is to have a particular signature).

> 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 really - the concrete type isn't important, but what you can do with it is. One could argue that instead we'd use a concept in place of `auto`, and Bjarne has argued exactly that for C++.

Re: Better C – A subset of D Programming Language

#144

Post by enitihas »

hibbelig wrote: post #89
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…

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…

You can just use map.forEach and avoid the types in the next two lines too.

Re: Better C – A subset of D Programming Language

#145

Post by ddevault »

kreco wrote: post #45

It's interesting how this works: - enumerate everything C is doing bad. - presents fixes with a full bag of unnecessary features that no c programmer wants. I wonder why there is no "Fixed C".

Sorry to see this at the bottom of the thread, because you have a real point here. None of the attempts at "better C" or even "replacing C" have been serious attempts, and it's frankly getting a bit insulting. No one who still uses C wants its replacements to "catch up" on the past 20 years of new language development. We want C, but without the problems. We don't want D but less so. The response below - "you don't have to use any features if you don't want to!" - is a ridiculous cop-out and the same thing people who defend C++ are saying.

Re: Better C – A subset of D Programming Language

#146

Post by entropicdrifter »

qqssccfftt wrote: post #133
kevin_thibedeau wrote: post #128

Earlier quoted context omitted.

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

A good dev uses an IDE. In 2020.

Two things can be true. You shouldn't need an IDE to grok the code.

Re: Better C – A subset of D Programming Language

#147

Post by self_awareness »

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 never programmed in D so I don't know, but from curiosity I wanted to check if what you write is true. However, I can't find any function that is declared as auto.

Could you please paste some example of a function that has a return value which is declared as auto?

Re: Better C – A subset of D Programming Language

#148

Post by entropicdrifter »

arunc wrote: post #72
slezyr wrote: post #17

Earlier quoted context omitted.

Print-debug you program before it's even compiled and even have a bug is a bag idea.

Why so?

You shouldn't need to reverse-engineer your own program just to understand the code you wrote yourself.

Re: Better C – A subset of D Programming Language

#149

Post by choward »

Pxtl wrote: post #134
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…

Hard disagree. MyClass myVar = new MyClass() is not DRY. It also makes it practical to use complicated structures out of generics/templates without killing the developer With , Declarations>.

Hard disagree. If you are assigning a value that's the result of an expression you might have somewhat complicated logic. Being able to say what you expect returned is very useful.

    MyClass myVar = something ? SomeFunction() || somethingThatMightBeASubClassOfMyClass

Re: Better C – A subset of D Programming Language

#150

Post by c-cube »

skocznymroczny wrote: post #104
scott_s wrote: post #96

Earlier quoted context omitted.

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.

That makes for terrible docs and discoverability, which is the problem here.

Maybe D should allow the user to name the return type (an existential variable) and static assert stuff on it:

`SomeVar f(…) with isRange!SomeVar` or whatever. `auto` just means "you have to read the implementation because it can be literally anything"

Post reply on HN