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

301–310 of 360 posts

Re: Better C – A subset of D Programming Language

#301

Post by gmueckl »

skocznymroczny wrote: post #237
c-cube wrote: post #150

Earlier quoted context omitted.

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"

Well, it is visible in documentation, but even those can be hard to parse: uint startsWith(alias pred = (a, b) => a == b, Range, Needles...)(Range doesThisStart, Needles withOneOfThese) if (isInputRange!Range && (Needles.length > 1) && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[0])) : bool) && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[1..$])) : uint));

You did pick a particularly nasty example for that one. I do agree that it is not so easy to read these constraints. It can also be a bit frustrating when you need to chase down why exactly a particular line of code doesn't meet such a constraint. Tests like isInputRange are themselves fairly involved expressions and in the worst case, you end up staring at those after a template instantiation failed.

Re: Better C – A subset of D Programming Language

#302

Post by asdkjh345fd »

gallier2 wrote: post #255
asdkjh345fd wrote: post #197

Earlier quoted context omitted.

>But the name of that type depends on the type of the range and on the callable. That should not be a problem. It is a problem in D because of a lacking in D. >How would you suggest improving the signature of map given that D doesn't have typeclasses? The language needs fixed so it can express its own types.

> That should not be a problem. It is a problem in D because of a lacking in D. It is not a problem, the compiler copes with it. The problem comes from the fact that such a type is absolutely not interesting to know how it is written. The unmangled type is unreadable.

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.

Re: Better C – A subset of D Programming Language

#303

Post by asdkjh345fd »

jcelerier wrote: post #207
asdkjh345fd wrote: post #199

Earlier quoted context omitted.

If something is unclear, you can ask for clarification. I repeated the statement to three people because three people repeated the same argument to me. This is how conversations work. I have very limited exposure to haskell, am not detached from reality, and am taking nothing personal. Of course the discussion is serious, why would I spend time engaging in a frivolous and meaningless discussion?

could you provide the type of this map function ? auto map(auto x) { if constexpr(is_same ) { struct T1 { int getStuff() { return 0; } }; return T1 {}; } else { struct T2 { void doStuff() { } }; return T2 {}; } }

Read the rest of the discussion.

Re: Better C – A subset of D Programming Language

#304

Post by cesarb »

exiled13 wrote: post #295
throwaway17_17 wrote: post #286

Earlier quoted context omitted.

What is the difference between the two?

Rust was designed from the ground up and every feature is implemented and designed to work with its borrow checker. So it is able to provide a definitive guarantee that memory isn't free'd or used after it is free'd. The only exception is in "unsafe" code, where you can break the borrow checker. But this limits where you have to worry about potential bugs. In D, the ""borrow checker"" is being tacked on as an after t…

> This isn't a problem in Rust because it doesn't have exceptions

Rust does have something similar to exceptions when compiled with "panic=unwind" (the default). It uses the same mechanism as C++ exceptions to unwind the stack (while calling all the necessary destructors), can be caught (std::panic::catch_unwind) and rethrown (std::panic::resume_unwind), and has some of the same concerns as C++ about "exception safety" (mostly within unsafe code - the programmer has to take care to leave the objects in a safe state when it can unwind).

Re: Better C – A subset of D Programming Language

#305

Post by petee »

Dylan16807 wrote: post #287
petee wrote: post #257

Earlier quoted context omitted.

A good dev shouldn't require crutches

Interactivity is not a crutch.

Interactivity is a base attribute of an ide, and not the first reason people use it; the context here is that using an ide doesn't define a good programmer. So being able to clicky click is what makes good programmers to you?

Re: Better C – A subset of D Programming Language

#306

Post by optymizer »

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 compiler/gcc compiler, several debuggers, some BetterC option, etc. I don't know which toolchain is best, and I don't want to deal with the integration issues between them.

All of these options that exist are great, but the brand gets diluted. D seems to be the ideal thing: it's seemingly a better C++, and a better C, with a clean syntax like Java.

I trust it's a better C, but how do I know the combination of the D toolchain that I'm choosing is better than sticking with the devil I know already?

What I would love to see is an opinionated package spun off from D. One compiler, one debugger, one IDE, one standard library. Make my onboarding experience better and take the thinking out of assembling a D toolchain.

Every time I find myself thinking "maybe I should look into using D instead of C for this project", I spend a few hours with D, and then I get frustrated at all the options and I go back to the devil I know.

I truly wish I could be one day convinced that I can install D and I get a solid platform without weird moving parts.

Re: Better C – A subset of D Programming Language

#307

Post by jbverschoor »

thesuperbigfrog wrote: post #217
jbverschoor wrote: post #98

Earlier quoted context omitted.

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

No. I mean altering code to strong typing using type inference. So that auto becomes int, or MyClass*.

Re: Better C – A subset of D Programming Language

#308

Post by Dylan16807 »

petee wrote: post #305
Dylan16807 wrote: post #287

Earlier quoted context omitted.

Interactivity is not a crutch.

Interactivity is a base attribute of an ide, and not the first reason people use it; the context here is that using an ide doesn't define a good programmer. So being able to clicky click is what makes good programmers to you?

They said that good devs use IDEs, not that IDE use makes you a good dev. Those are very different statements.

Re: Better C – A subset of D Programming Language

#309

Post by exiled13 »

cesarb wrote: post #304
exiled13 wrote: post #295

Earlier quoted context omitted.

Rust was designed from the ground up and every feature is implemented and designed to work with its borrow checker. So it is able to provide a definitive guarantee that memory isn't free'd or used after it is free'd. The only exception is in "unsafe" code, where you can break the borrow checker. But this limits where you have to worry about potential bugs. In D, the ""borrow checker"" is being tacked on as an after t…

> This isn't a problem in Rust because it doesn't have exceptions Rust does have something similar to exceptions when compiled with "panic=unwind" (the default). It uses the same mechanism as C++ exceptions to unwind the stack (while calling all the necessary destructors), can be caught (std::panic::catch_unwind) and rethrown (std::panic::resume_unwind), and has some of the same concerns as C++ about "exception safet…

I didn't know that used something akin to exceptions. Still panics aren't as common as exceptions (in D), and still only have to worry about unsafe code (for the most part).

Re: Better C – A subset of D Programming Language

#310

Post by aldacron »

arunc wrote: post #294
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…

OP's point was about auto being littered in documentation and not in the code itself. Having auto is a boon for certain design aspects. As system level programming language D offers everything in betterC mode. Of course it can offer more. But a small community can do only so much.

It's not "littered" in the documentation for anyone who understands the basics of D's ranges. auto is the correct choice here. Range functions are lazy, meaning they are almost always used in a chain of function calls that ends in something like `.array` to get a concrete type -- an array in this case. At no point in that process do you care about the actual return type of any of those functions.
Post reply on HN