Live data from Hacker News

Contracts for C

gustedt.wordpress.com

71–80 of 114 posts

Re: Contracts for C

#71
post #2

I like Eiffel. But if I want to use Eiffel, I’ll use Eiffel (or Sather). I’d rather C remained C. Maybe that’s just me?

Are you being really honest with yourself that you would renounce c90, c99 additions to stay with the original language as it was introduced in K&R C book?

Re: Contracts for C

#72
post #25

Earlier quoted context omitted.

> Digital Mars C++ has had contracts since, oh, the early 1990s? I think that implementations trying out their own experimental features is normal and expected. Ideally, standards would be pull-based instead of push-based. The real question is what prevented this feature from being proposed to the standardization committee.

It was proposed by Walter and denied by Stroustroup, probably to save C++. Karma hits back and he is trying to save C++ from Rust.

D is the result of lack of interest by the C++ committee, and I had little interest in spending literally years trying to get useful things adopted into C++.

Ironically, over the years, C++ has adopted many features popularized by D.

(like contracts!)

C++ should adopt a few more D features, like https://www.digitalmars.com/articles/C-biggest-mistake.html, compile time expression evaluation (C++ did it wrong), forward references, and modules that work. C++ should also deprecate the preprocessor, a stone-age kludge that has long been obsolete.

Re: Contracts for C

#74
post #2

I like Eiffel. But if I want to use Eiffel, I’ll use Eiffel (or Sather). I’d rather C remained C. Maybe that’s just me?

Ada / SPARK has contracts, too, that can be proven at compile-time. In fact, Ada alone suffices, it has pre- and post-conditions. I think Ada has more libraries than Eiffel does. Does anyone even write Eiffel? I am really curious if it is still alive anywhere, in some form.

Eiffel failed largely because of licensing restrictions.

Re: Contracts for C

#75
post #4

Earlier quoted context omitted.

Java 24 and C# 9 resemble little of their first versions. C++ might as well not even be the same language at this point. Why are we so conservative with C but then so happily liberal with every other language?

People chose C because they liked C. Of course they don't want C to change. The only thing the ISO committee should be adding is stuff for filling in the holes in language (C23's Improved Tag Compatibility and __VA_OPT__ are good examples), not add features that were never part of C and were never supposed to be there. Your question can be reflected back to you: if you want an ever changing languages, go to Java, C#…

C added the absurd normalized Unicode identifiers.

Re: Contracts for C

#76

Earlier quoted context omitted.

People chose C because they liked C. Of course they don't want C to change. The only thing the ISO committee should be adding is stuff for filling in the holes in language (C23's Improved Tag Compatibility and __VA_OPT__ are good examples), not add features that were never part of C and were never supposed to be there. Your question can be reflected back to you: if you want an ever changing languages, go to Java, C#…

> People chose C because they liked C. Of course they don't want C to change. The same thing can be said for every other language, yet they change.

A common thing people write about D is don't add any more features except for their feature proposals. :-)

Re: Contracts for C

#77
post #4

Earlier quoted context omitted.

Java 24 and C# 9 resemble little of their first versions. C++ might as well not even be the same language at this point. Why are we so conservative with C but then so happily liberal with every other language?

The complexity of C# and C++ should be a warning, not something to strive towards. C++ has 3 reasonable implementations, C has hundreds, for all sorts of platforms, where you don't get anything else. Most C developers don't want a modern C, they want a reliable C. WG14 should be pushing for clarifications on UB, the memory and threading model, documenting where implementations differ, and what parts of the language c…

Check out all the extensions added to C, all incompatible with each other.

Re: Contracts for C

#78

Earlier quoted context omitted.

The vast majority of C programmers will agree that they don't care for any of the new features, as is clearly evident by the fact that almost nobody elects to use the latest standards. The "most popular programming languages" are irrelevant here. C and C++ are standardized languages, and also the tools we use for code that actually matters. A standard that can't be implemented is worthless, and even the "3 high quali…

> The vast majority of C programmers will agree that they don't care for any of the new features,(...) I think this belief is based on faulty assumptions, such as survivorship bias. C++ became popular largely because it started off by extending C with the introduction of important features that the developer community wanted to use. The popularity of C++ over C attests how much developers wanted to add features to C.…

C++ became popular because in the late 80s, 90% of programming was done on the PC. Zortech C++, with the first native compiler, provided the most powerful metal programming language available.

Zortech C++ is what gave C++ critical mass to succeed.

P.S. before ZTC++, the traffic in the usenet C++ newsgroup was neck-and-neck with the objective C newsgroup. After ZTC++ was released, traffic in the C++ newsgroup took off and the objective C one faded away. Borland saw our success, and pivoted away from their nascent attempt at an OOP language towards implementing Borland C++. Microsoft then also abandoned their OOP C project (called C) in favor of developing C++.

(I've never been able to get any information about C, I was just told about it by a Redmondian.)

Re: Contracts for C

#79
post #40

Earlier quoted context omitted.

The complexity of C# and C++ should be a warning, not something to strive towards. C++ has 3 reasonable implementations, C has hundreds, for all sorts of platforms, where you don't get anything else. Most C developers don't want a modern C, they want a reliable C. WG14 should be pushing for clarifications on UB, the memory and threading model, documenting where implementations differ, and what parts of the language c…

Most single C implementations have died out. There is hardly any C compiler worth using that isn't equally a C++ compiler . In fact, there is any C compiler left worth using that hasn't been rewriten into C++.

My current C compiler is implemented in D :-)

Re: Contracts for C

#80
post #65
post #40

Earlier quoted context omitted.

Most single C implementations have died out. There is hardly any C compiler worth using that isn't equally a C++ compiler . In fact, there is any C compiler left worth using that hasn't been rewriten into C++.

That may be true in your bubble, but I don't think this is true in general. There are still a lot C compilers out there, compared to 3 or 4 that do C++.

Other than legacy embedded CPUs like PICs, I doubt it.
Post reply on HN