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

71–80 of 360 posts

Re: Better C – A subset of D Programming Language

#71

Post by atilaneves »

asdkjh345fd wrote: post #49
logicchains wrote: post #27

Earlier quoted context omitted.

>so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Especially given that D functions like "map" and "reduce" tend to return special iterator types so that the compiler is able to smarty fuse them where possible. If D had concepts l…

>With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Of course it is. Map's type is "(a -> b) -> [a] -> [b]". D just absolutely and completely failed here, despite this being a solved problem 40 years ago.

Not in D, it isn't, for performance reasons. It takes an input range and returns a type that iterates through that range applying the callable (doesn't have to be a function!) to each element as requested.

Re: Better C – A subset of D Programming Language

#72

Post by arunc »

slezyr wrote: post #17
WalterBright wrote: post #5

Earlier quoted context omitted.

You don't have to wait for the compiler to complain. Using: pragma(msg, T); where T is any type will print the type to the screen during compilation. pragma(msg) will print all kinds of things, making it a very handy tool to visualize what is happening while compiling. I use it all the time.

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

Why so?

Re: Better C – A subset of D Programming Language

#73

Post by claudiug »

WalterBright wrote: post #4

Walter here - AMA!

- what is the status of the language now?

- what is the status of the ecosystem now?

- what are the big issues that make d less appealing?

- ms alexandrescu is still involved in the project?

- where do you see the language in 2 years for now?

Re: Better C – A subset of D Programming Language

#74

Post by GoblinSlayer »

asdkjh345fd wrote: post #49
logicchains wrote: post #27

Earlier quoted context omitted.

>so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Especially given that D functions like "map" and "reduce" tend to return special iterator types so that the compiler is able to smarty fuse them where possible. If D had concepts l…

>With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Of course it is. Map's type is "(a -> b) -> [a] -> [b]". D just absolutely and completely failed here, despite this being a solved problem 40 years ago.

That still means "it returns something".

Re: Better C – A subset of D Programming Language

#75

Post by asdkjh345fd »

atilaneves wrote: post #71
asdkjh345fd wrote: post #49

Earlier quoted context omitted.

>With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Of course it is. Map's type is "(a -> b) -> [a] -> [b]". D just absolutely and completely failed here, despite this being a solved problem 40 years ago.

Not in D, it isn't, for performance reasons. It takes an input range and returns a type that iterates through that range applying the callable (doesn't have to be a function!) to each element as requested .

>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 point is that D has something, and it doesn't tell us what that something is. It should. Documentation is good.

Re: Better C – A subset of D Programming Language

#76

Post by arunc »

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…

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

Re: Better C – A subset of D Programming Language

#77

Post by asdkjh345fd »

GoblinSlayer wrote: post #74
asdkjh345fd wrote: post #49

Earlier quoted context omitted.

>With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Of course it is. Map's type is "(a -> b) -> [a] -> [b]". D just absolutely and completely failed here, despite this being a solved problem 40 years ago.

That still means "it returns something".

It gives us much more information than "something". It tells us it is a list of the type of the second argument to the function we passed it. Or in the generic version a "something you can iterate over" of things of the type of the second argument to the function we passed.

Re: Better C – A subset of D Programming Language

#78

Post by Koshkin »

logicchains wrote: post #30
pansa2 wrote: post #22

Earlier quoted context omitted.

I think it’s really interesting that as dynamically-typed languages increasingly encourage explicit type hints, statically-typed languages are recommending “almost always auto”.

In dynamically typed languages, adding types can stop things blowing up at runtime. In compiled languages, all the type-inference is still done at compile time, so if it compiles than you're not going to get a crash from accidentally adding a string to an integer at runtime.

The template language is weakly typed and code written in it, too, can “crash” when it runs (which is the compilation time) for the same reasons.

Re: Better C – A subset of D Programming Language

#79

Post by bachmeier »

WalterBright wrote: post #16
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…

It's helpful to bring up issues you are encountering in the D forums. This is the first I've heard of this particular one.

It's been raised many times before. By me and numerous others. The standard library is generic, which isn't the end of the world, but you can't tell from the documentation how you can work with the output. It's common for someone to ask a question and be told "add .array to the output". They'd never know that after reading the documentation.

Re: Better C – A subset of D Programming Language

#80

Post by mhd »

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 have been many, many "Fixed C"'s.

That's the problem. This isn't a technology issue, it's a social one.

Post reply on HN