Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Obvious things C should do

digitalmars.com

Post reply on HN
Print view View original

261–270 of 310 posts

Re: Obvious things C should do

#261

Post by WalterBright »

bluGill wrote: post #199
WalterBright wrote: post #44

Earlier quoted context omitted.

The ideas for advancing D come thick and fast. C and C++ will never merge with D, because we have different philosophies of what makes for a great programming language. For example, D will never have a preprocessor. Or over my dead body :-/

C++ is trying to eliminate the use of preprocessor. they can't get rid of it but you shouldn't use it.

I see revision after revision of Standard C++, and no progress in that direction. I (along with Andrei Alexandrescu and Herb Sutter) made a proposal to add D's static if feature to eliminate the need for #if. It was vehemently rejected.

Re: Obvious things C should do

#262

Post by WalterBright »

agumonkey wrote: post #181
WalterBright wrote: post #44

Earlier quoted context omitted.

The ideas for advancing D come thick and fast. C and C++ will never merge with D, because we have different philosophies of what makes for a great programming language. For example, D will never have a preprocessor. Or over my dead body :-/

Thanks a lot for your answer, I have another one, what languages or topics do you follow for inspiration regarding concepts ?

I could spent 500% of my time studying other languages. So I don't, but the D user community isn't shy about doing that for me!

Re: Obvious things C should do

#263

Post by lazystar »

josephg wrote: post #149
TheNewAndy wrote: post #130

Earlier quoted context omitted.

That's an interesting assertion, but not one that matches the experience I've had. It is one of those things that sounds "obviously true", but in practice I've found that it doesn't really live up to the promise. As a concrete example of this, having a plain text header file as documentation tends to mean that when people are reading it, if they spot a mistake or see that something isn't documented that should be doc…

I know people look at me like I’m a heathen and a scoundrel, but I think a lot of software teams spend too much time trying to make things consistent. Where’s the ROI? There is none. GitHub readmes? Bring on the weird quirks, art, rants about other software, and so on. I’ll take it all. Don’t get me started on linters. Yes, there’s lots of things that should actually be consistent in a codebase (like indentation). Bu…

> Where’s the ROI? There is none.

> Oh, my JavaScript has a mix of semicolons and non semicolons? Who cares?

i had to refactor and port a javascript codebase that contained a mix of all of javascripts syntactic sugar, no comments anywhere in the codebase, and i was unable to ask the original devs any questions. the high amount of syntactic sugar gave me "javascript diabetes" - it was fun figuring out all the randomness, but it delayed the project and has made it extremely difficult to onboard new folks to the team after i completed the port.

painting is a creative discipline, and the mona lisa has stood the test of time because davinci used a painting style and materials that set the painting up for long term use.

a codebase without standards is akin to drawing the mona lisa on a sidewalk with sidewalk chalk.

Re: Obvious things C should do

#264

Post by lazystar »

XorNot wrote: post #183
josephg wrote: post #149

Earlier quoted context omitted.

I know people look at me like I’m a heathen and a scoundrel, but I think a lot of software teams spend too much time trying to make things consistent. Where’s the ROI? There is none. GitHub readmes? Bring on the weird quirks, art, rants about other software, and so on. I’ll take it all. Don’t get me started on linters. Yes, there’s lots of things that should actually be consistent in a codebase (like indentation). Bu…

I don't like complaining linters. I do like auto fixing linters I can leave running in the background.

> auto fixing linters

any advice on how to implement an auto linter in an old codebase? i hate losing the git blame info.

Re: Obvious things C should do

#265

Post by WalterBright »

ksec wrote: post #109
WalterBright wrote: post #13

Earlier quoted context omitted.

Yup. D is the source for a number of recent features in other languages. The reason I embarked on D is because C and C++ were too reluctant to move forward.

>The reason I embarked on D is because C and C++ were too reluctant to move forward. I just want to take this opportunity to say thank you. While D may not taken up from the rest of the world. It has surely lived on in C, C++ and many other languages. Still wish more people would use Das C.

Yes, the influence is there.

For example, C++ pivoted to using ranges instead of iterators, and even C# changed their iterators to be like D's ranges (or so I've been told).

Re: Obvious things C should do

#266

Post by WalterBright »

WhereIsTheTruth wrote: post #129
WalterBright wrote: post #13

Earlier quoted context omitted.

Yup. D is the source for a number of recent features in other languages. The reason I embarked on D is because C and C++ were too reluctant to move forward.

I'm curious, is there any features, from any language, that you wish you had implemented, or want to copy, in D?

There's active work going on to add pattern matching. Just recently I completed the addition of move constructors. They are different from C++'s, and I bet they'll turn out to be much better.

Re: Obvious things C should do

#267

Post by WalterBright »

sundarurfriend wrote: post #206
WalterBright wrote: post #64

Earlier quoted context omitted.

D had compile time execution of functions in 2007. Order-independent top level declarations. Underscores embedded in integer literals. (I stole this idea from Ada, which had been forgotten. Soon after D popularized it, it became standard in other languages.) Continue or break to labeled loop. Fixed sizes for ints, longs, etc. Of course, I don't know if there's a straight line here, and Zig is welcome to use any featu…

> Underscores embedded in integer literals. Perl had this years before D even existed [1]. Given its earlier age and higher reach, it's likely that Perl did more to popularize the idea as well. > Continue or break to labeled loop. Also a feature that Perl had years before D's existence [2]. These two are the ones I immediately recognized because of my familiarity with Perl, but given the trend, I'm doubtful of the ot…

I did not know Metaware and Perl did this, as I've never used either. I know that my inspiration for it came from Ada.

I accept that Metaware and Perl did this before D. But I still claim that adoption of it in other languages came shortly after I popularized it in D, as I included it in many presentations about it.

Re: Obvious things C should do

#268

Post by WalterBright »

dfawcus wrote: post #223
WalterBright wrote: post #64

Earlier quoted context omitted.

D had compile time execution of functions in 2007. Order-independent top level declarations. Underscores embedded in integer literals. (I stole this idea from Ada, which had been forgotten. Soon after D popularized it, it became standard in other languages.) Continue or break to labeled loop. Fixed sizes for ints, longs, etc. Of course, I don't know if there's a straight line here, and Zig is welcome to use any featu…

Metaware High-C version 1.2 (Nov 1985) had underscores in floating point and integer literals. Possibly it had that even earlier. Possibly also taken from Ada, as other text in that section of the manual reference Ada. See A.3 pg 169 (and 58+) of 235 in: https://bitsavers.org/pdf/metaware/High_C_Language_Reference...

I did not know that. Thanks for pointing it out.

Re: Obvious things C should do

#269

Post by ufo »

WalterBright wrote: post #258
ufo wrote: post #202

Earlier quoted context omitted.

I know that in other languages, one obstacle for "just compile the C files" is that the target language might not have pointers and thus have difficulty representing things such as return-by-pointer. I suppose in D this was less of an issue because D has pointers?

I'm not sure what you mean.

A foreign function interface that's based on parsing C files must translate C types and interfaces into types and interfaces of the target language. I suppose it helped that D's type system has many similarities with C, including support for pointers.

(The issue with return-by-pointer is that in C it's common to use the return value for an error code and use pointer arguments to pass data back to the caller. These are awkward to map to a target language that doesn't have pointers)

Re: Obvious things C should do

#270

Post by uecker »

WalterBright wrote: post #251
uecker wrote: post #219

Earlier quoted context omitted.

It is difficult to imagine that compile-time interpretation of tests is faster than compiling and running them for anything more complex. And for trivial stuff it should not matter. Not being able to do I/O is a limitation not a feature.

Linkers are slow and clunky. Yes, there is a crossover point where executable tests are faster.

For one of my C projects (ca. 450 c-files), full rebuild time on my (not super fast) laptop is just below 10 seconds (incremental builds < 1s). Compiling and linking all unit tests takes a second, and running all unit tests takes 6-7 seconds. So even running the optimized code for the tests almost doubles the time for rebuilding the full project. Although I like the machine code to be tested that is actually used. (BTW: A single C++ file with templates for CUDA someone added to the project - when activated - almost doubles the build time.)
Post reply on HN