Attention to detail comes with the territory for programming roles. People who can't or don't want to pay attention to details are not fit to be programmers. We are working with precise binary digital machines, FFS. I sometimes find this attitude among students of my training courses - the misconception "computer, do what I mean, not what I say". Obviously such students don't do well in my course or in their career.
A “Better C” Benchmark
151–160 of 192 posts
Re: A “Better C” Benchmark
#152Re: A “Better C” Benchmark
#153Re: A “Better C” Benchmark
#154Earlier quoted context omitted.
Within a single compilation unit, and only in this most trivial case.
Here's an example of a much more complex case that is detected: https://issues.dlang.org/show_bug.cgi?id=21745
Re: A “Better C” Benchmark
#155Earlier quoted context omitted.
I originally wrote a slide titled "D as Better C", and since I was in München at the time, it suddenly morphed into "Das Better C" and so the pun was born. In my head it is always said with a German accent.
If I was the marketing manager of D I would turned this "pun" into Super Hype. And yes this got me interested in D. I always knew of its existence but for some reason I never really looked into it.
Re: A “Better C” Benchmark
#156Earlier quoted context omitted.
Unsophisticated engineering solutions are not always the best. Modern CPUs are monstrously complex, for example. Modern airliners are incredibly complex. Simple solutions would be woefully uncompetitive. In the domain of programming languages, minimalistic low-level languages like assembly, C, and Forth, tend to be unsafe. They enable categories of serious bugs that never occur in safe languages. Modern garbage colle…
> Modern CPUs are monstrously complex, for example. But not all of that complexity is good. For example, things like branch-prediction vulnerabilities exist as a result of that complexity, which makes it extremely difficult to reason about the entire system and predict which interacting systems might lead to security issues. And it looks as if some of the complexity of the x86_64 instruction set is a liability with r…
I don't think any of the issues with Intel's x86-64 chips are due to the instruction-set, they're due to the chips' internal architectures. ARM CPUs are by no means 'safe by nature'.
> the more that I write, the more that I wonder if some of that complexity is due to unsolved design problems in the core of the language
> Rust sometimes feels like a language which is missing that one key piece which would keep all of this complexity under control.
I'm reminded of a quote [0] from Bjarne Stroustrup, creator of C++:
> Within C++, there is a much smaller and cleaner language struggling to get out.
Re: A “Better C” Benchmark
#157Re: A “Better C” Benchmark
#158I threw together a D Programming language glob-grep based off of the Zig version the author posted, if anyone is curious: https://gist.github.com/aruthane/005c6c48f0deb9c4bfc83bc75e0...
Re: A “Better C” Benchmark
#159Seeing the title, I expected an article benchmarking DLang "Better C". Instead, the author even don't mentioned anything about DLang...