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

191–200 of 360 posts

Re: Better C – A subset of D Programming Language

#191

Post by dfawcus »

yvdriess wrote: post #55
WalterBright wrote: post #4

Walter here - AMA!

A compiler related question: A often recurring C idiom is passing a pointer to a struct as function argument where passing the plain struct by copy would do. A big reason is the good old 'passing by pointer is faster', which I thought to be no longer relevant with modern optimizing compilers. Of course I found out the hard way that even on modern compilers object copies are not elided on call. I had performance sensi…

The proposed NUBI ABI[1] for MIPS was interesting here in that for call by value if a struct was register sized, it would be passed in a register, but if larger it would be implicitly passed by reference. See section 3.4, Arguments.

It was then up to the callee to make a copy if necessary, say if it modified the struct contents.

Hence it would have been possible to elide the copies, on a per function basis, depending upon how the function used the structure.

[1] ftp://ftp.linux-mips.org//pub/linux/mips/doc/NUBI/MD00438-2C-NUBIDESC-SPC-00.20.pdf

Re: Better C – A subset of D Programming Language

#192

Post by kllrnohj »

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

There are already two very successful "Fixed C"'s in wide usage: C++ & Objective-C.

The remaining C usage is a mix of existing domain expertise, existing large codebases impractical to migrate to anything else (eg, Linux), or a rejection of anything more than what C provides.

In all of those cases anything that's not exactly C is unlikely to motivate any changes. The users that could change to a "Fixed C" already did decades ago.

Re: Better C – A subset of D Programming Language

#193

Post by dgellow »

masklinn wrote: post #161
takeda wrote: post #154

Earlier quoted context omitted.

Maybe it was fixed? I would imagine that saying in documentation that return type is auto is equivalent to not mentioning return type at all, so feels like something not intentional.

> Maybe it was fixed? It wasn't. They probably didn't look into the more "generic" functions e.g. hofs and algorithms. The vast majority of functions in https://dlang.org/phobos/std_algorithm_iteration.html returns "auto"

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

Re: Better C – A subset of D Programming Language

#194

Post by kllrnohj »

skohan wrote: post #190
kllrnohj wrote: post #185

Earlier quoted context omitted.

> 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 vari…

> I think a lot of people would argue that many C++ features, like OO, are not strictly improvements.

Sure, but D has those OO features, too, so that's an argument against both, not one.

> like that it's nice not to have to pass around array lengths as separate variables.

-betterC doesn't have dynamic arrays, though. That's one of the "unavailable features" currently.

But that's also sommething C++ solved as well - std::vector does exist, after all, as does move semantics to avoid copying it unnecessarily.

C++ is far from perfect, of course, but D's -betterC doesn't really fix any of C++'s issues and it doesn't retain C's simplicity. It's in an awkward middle ground between the two - is that really a viable place to be? For users that already know & have C++ codebases, what's the sales pitch here? For existing C users, what does -betterC do that hasn't already been done and already failed to attract the C holdouts?

Re: Better C – A subset of D Programming Language

#195

Post by enhray »

Pxtl wrote: post #176
Koshkin wrote: post #166

Earlier quoted context omitted.

Anything wrong with var myClass = ... (or some other descriptive name of the variable)?

Personally I prefer this, since it also carries on to every following line. Like, in C# List accountsToDelete = accountService.GetAccountsToDelete(); repository.Delete(accountsToDelete); becomes var accountsToDelete = accountService.GetAccountsToDelete(); deleterService.Delete(accountsToDelete); So as much type information is already encoded into names so that all references to this object are clear in what we're han…

Beware the m_pszSlipperySlope [0].

[0] https://en.wikipedia.org/wiki/Hungarian_notation

Re: Better C – A subset of D Programming Language

#196

Post by thesuperbigfrog »

pjmlp wrote: post #178
thesuperbigfrog wrote: post #162

Earlier quoted context omitted.

Ada ( https://learn.adacore.com/courses/intro-to-ada/chapters/cont... ) and Eiffel ( https://www.eiffel.com/values/design-by-contract/introductio... ) also support contracts. Contract-based programming is a very nice way to quickly find errors and specify how different parts of the program should interact.

C++20 almost got them. There are some Java annotation processors that rewrite the bytecode for contracts. As extra info.

Java annotations have always struck me as interesting since they fill the Lisp macros and C preprocessor niche for Java.

It's another layer of complexity, but it extends the language to offer a bit more richness or layers of abstraction.

I would not be surprised if a future C++ standard adds contracts officially. Boost seems to already have contracts: https://www.boost.org/doc/libs/1_67_0/libs/contract/doc/html...

Re: Better C – A subset of D Programming Language

#197

Post by asdkjh345fd »

atilaneves wrote: post #139
asdkjh345fd wrote: post #75

Earlier quoted context omitted.

>It takes an input range Which should have a type. >and returns a type that iterates through that range Which should have a type. The entire point is that this is a solved problem, there is no excuse to simply throw up our hands and say "screw documentation we'll just say this function is a mystery". Functor f => (a -> b) -> f a -> f b And please don't miss the point and tell me D doesn't have Functor. The entire poi…

> > It takes an input range > Which should have a type. It does. That'd the `Range` here: https://dlang.org/phobos/std_algorithm_iteration.html#.map.m... > > and returns a type that iterates through that range > Which should have a type. It does. But the name of that type depends on the type of the range and on the callable. > Functor f => (a -> b) -> f a -> f b This doesn't work because the return type isn't `f b`,…

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

Re: Better C – A subset of D Programming Language

#198

Post by lostmsu »

dgellow wrote: post #193
masklinn wrote: post #161

Earlier quoted context omitted.

> Maybe it was fixed? It wasn't. They probably didn't look into the more "generic" functions e.g. hofs and algorithms. The vast majority of functions in https://dlang.org/phobos/std_algorithm_iteration.html returns "auto"

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.

Re: Better C – A subset of D Programming Language

#199

Post by asdkjh345fd »

jhoechtl wrote: post #110
asdkjh345fd wrote: post #70

Earlier quoted context omitted.

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.

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?

Re: Better C – A subset of D Programming Language

#200

Post by the8472 »

schveiguy wrote: post #187
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…

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

Post reply on HN