51–60 of 360 posts
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.
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".
Fortunately, you can simply not use any feature you find unnecessary. We won't harangue you about it, I promise! (Well, maybe a little bit if it's so cool we just can't resist.)
This is a great idea. I maintain that Ada is a better "better C" than any of the alternatives I've looked into, but it has an obvious big hurdle: while it has approximately the same use cases as C, it is completely different in terms of looks and handling. One of the strong points of D is that it still seems very much like C. Very good call to emphasise this.
I like Ada. D took inspiration from it.
Walter here - AMA!
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 sensitive parts of my (non-x86) code that were dominated by the compiler's builtin memcpy, due to my struct-happy coding style (e.g. rolling my own range struct and passing it by value everywhere).
I understand mostly why eliding argument copy is so much harder than eliding a return object copy, there are so many ways to observe its effect, and you have to obey the calling convention. Another aspect is the lack of programmer-communicated immutability in C, which you have addressed with D. Does the D compiler help in this situation? Can it guarantee that (immutable) argument copies will be elided in certain circumstances? (e.g. in file-scope static functions)
D is pretty exciting. Seems like a perfect choice for those of us looking for an alternative systems programming language and are not completely convinced we'll be happy in Rust.
It basically follows on the school of thought at Xerox PARC, ETHZ, and Microsoft Research.
Now what it lacks is more more manpower to improve its runtime capabilities and having a big name actually pushing it forward.
However this doesn't need to be a zero sum game, any language that helps to fix C is welcomed to the party, including attempts like Checked C and Frama-C.
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.
Earlier quoted context omitted.
Hi Walter. I have two and a half questions: * Regarding the syntax of 'lazy'. It seems to me that it would make for better readability if the lazy keyword were required at the callsite, along the lines of doStuff(lazy getValueUsingExpensiveComputation()); rather than the current syntax where it's not clear at the callsite which, if any, of the arguments are lazy. C# does something similar with ref . What's the thinki…
Relevant post in a discussion thread that's related to the future of lazy in D: https://forum.dlang.org/post/ngkvntcrfdbsnxzfmcky@forum.dlan...
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.
Ahh.. welcome to computer "science", the ever repeating cycle of 'inventions'
D is pretty exciting. Seems like a perfect choice for those of us looking for an alternative systems programming language and are not completely convinced we'll be happy in Rust.
Yeah I think "better C" is a space which has a really good reason to exist and I'm always interested to see new entrants. IMO describing Rust as a "C replacement" is slightly off the mark because Rust's value proposition is very different from C. Rust is about giving you the best possible performance in a safe-by-default language. C is about giving you maximal control over memory, with a very thin layer of abstractio…
So as long as UNIX clones exist C will be around. OSes with POSIX APIs is a different matter, because there the kernel can be something totally different, e.g. mainframes.
So for that, we still need something like Checked C.
Or as Oracle, ARM, Google are doing, hardware memory tagging.