Remix.run Logo
__d 4 days ago

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?

johnisgood 4 days ago | parent | next [-]

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.

WalterBright 4 days ago | parent [-]

Eiffel failed largely because of licensing restrictions.

pjmlp 4 days ago | parent | prev | next [-]

Languages are software products like everything else in computing, either they evolve or they whither and die.

C especially was designed with lots of security defects, and had it not been for UNIX being available for free, it would probably never taken off.

HexDecOctBin 4 days ago | parent [-]

More likely they evolve AND they whither and die. The number of software I have stopped using due to bad updates is much higher than those with not enough updates.

veltas 4 days ago | parent | prev | next [-]

Truly I agree, but if we can add features to improve C codebases without rewriting them then that's a win, and you can just ignore them if you don't like them (as I will), but to the people where this has benefit they can be used.

jimbob45 4 days ago | parent | prev | next [-]

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?

nananana9 4 days ago | parent | next [-]

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 can be relied and what not.

Nobody really needs a new way to do asserts, case ranges, or a new way to write the word "NULL".

motorest 4 days ago | parent | next [-]

> The complexity of C# and C++ should be a warning, not something to strive towards.

I think this talk about "complexity" is a red herring. C++ remains one of the most popular languages ever designed, and one of the key reasons is that since C++11 the standardization effort picked up steam and started including features that the developer community wanted and was eager to get.

I still recall the time that randos criticized C++ for being a dead language and being too minimalistic and spartan.

> C++ has 3 reasonable implementations, C has hundreds, for all sorts of platforms, where you don't get anything else.

I don't understand what point you are trying to make. Go through the list of the most popular programming languages, and perhaps half of them are languages which only have a single implementation. What compelled you to criticize C++ for having at least 3 production-quality implementations?

> Most C developers don't want a modern C, they want a reliable C.

You speak only for yourself. Your personal opinion is based on survivorship bias.

I can tel you that as a matter of fact a key reason why the likes of Rust took off was that people working with low-level systems programming were desperate for a C with better developer experience and sane and usable standard library.

> Nobody really needs a new way to do asserts, case ranges, or a new way to write the word "NULL".

Again, you speak for yourself, and yourself alone. You believe you don't need new features. That's fine. But you speak for yourself.

babaceca 4 days ago | parent | next [-]

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 quality" implementations of C/C++ haven't fully implemented the latest 2 editions of either language.

There's a lot more riding on these two languages than you give credit for, and they should be held to a higher standard. C is not the language to experiment with shiny new features, it's the language that works.

> I can tel you that as a matter of fact a key reason why the likes of Rust took off

So what's the problem? If Rust is gaining traction on C/C++, and people are excited about what it brings to the table, use it. We'll both do our thing, let it play out - we'll see which approach yields better software in 10 years.

motorest 4 days ago | parent | next [-]

> 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++ also started being used over C in domains where it was not an excellent fit, such as embedded programming, because the C community prefered to deal with C++'s higher cognitive load as an acceptable tradeoff to leverage important features missing from C.

The success of projects such as Rust and even Zig, Nim also comes at the expense of C's inability to improve the developer experience.

Not to mention the fact that some projects are still developed in C because of a mix of inertia and lack of framework support.

So to claim that the C programmers do not want change, first you need to ignore the vast majority that do want but already dropped C in favor of languages that weren't frozen in time.

It's also unbelievable to claim that a language that precedes the concept of developer experience represents the apex of language design. This belief lands somewhere between Stockholm syndrome and being mentally constrained to not look beyond a tool.

WalterBright 4 days ago | parent | next [-]

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.)

babaceca 4 days ago | parent | prev [-]

> So to claim that the C programmers do not want change, first you need to ignore the vast majority that do want but already dropped C...

Good, we can ignore them. It's not a language for everybody, and if you're happily using C++, or Zig, or Nim, keep doing that.

Developer experience is a weigted sum of many variables. For you cool syntax features may play a huge role of that, for most C programmers a simple language with clear and understandable semantics is much more important.

There are many languages with cool syntax and shiny features, and very few of the latter kind. C belongs to the latter, and it also happens to be running a vast majority of the world's most important software.

You keep bringing up Rust as an example. It's probably the most famous of the new-age systems languages. If it's such a great language, when will we see a useful program written in it?

motorest 3 days ago | parent | next [-]

> Good, we can ignore them.

Who do you think you're representing? At best you only speak for yourself. It's perfectly fine if you choose to never update any tool you use, but that's just your personal opinion. You are free to stick with older standard versions of even compiler releases, but that is no justification to prevent everyone around you to improve their developer experience.

> It's not a language for everybody (...)

You might believe it isn't, but that's hardly a sane or rational belief.

babaceca 3 days ago | parent [-]

Reality isn't on your side.

  1. A lot of people use the old C standards.
  2. Not a lot of people use the new ones.
  3. A lot of useful software is written in C.
  4. Not a lot of useful software is written in any of the other languages you've listed in this conversation, despite the fact that you can hardly call them "new" at this point.
I'm done with you, I'll leave you to puzzle out the obvious conclusion of these 4 points.

You write software your way, I'll write it mine, and in 10 years we can check our homework. The first 10 years of Rust haven't really given us any results software-wise, but I'm sure with language design powerhouses such as yourself on the case, and just a few more pieces of syntax sugar, you can turn it around.

aw1621107 3 days ago | parent | prev [-]

> If it's such a great language, when will we see a useful program written in it?

I think it should have been simple enough to find examples, though I suppose there might be some dependence on what you mean by "useful".

For standalone stuff, some examples might be Ripgrep, ruff, uv, Alacritty, and Polars. Rust is also used internally by some major companies, such as Amazon, Dropbox, Mozilla, Microsoft, Google, Volvo, Discord, and CloudFlare.

babaceca 3 days ago | parent [-]

> there might be some dependence on what you mean by "useful".

I should've been clearer about that, but what I mean by that is pretty much what a normal non-technical person would consider an useful piece of software - Photoshop, Figma, Excel, Chrome, Windows, Android, Blender, AutoCAD, Unreal Engine, any Office Suite...

Since this is a technical forum I think we'd both easily agree on a bunch of very technically impressive software that the average person hasn't heard of - ffmpeg, qemu, LLVM, Linux, Postgres, V8, etc.

It would be a stretch to put any of the tool on either of those lists. Given the popularity of Rust, and that it's now over 10 years old, I'd expect at least one major program that can serve as an example of "here's this very useful, complex software package, as proof that our methodology works and you can do cool things this way."

aw1621107 3 days ago | parent | next [-]

> but what I mean by that is pretty much what a normal non-technical person would consider an useful piece of software

That seems like an... interesting... definition of "useful" to me. Why that definition?

> Photoshop, Figma, Excel, Chrome, Windows, Android, Blender, AutoCAD, Unreal Engine, any Office Suite...

To be fair, there is Rust in Windows and Android, and IIRC there's movement towards using it in Chrome as well.

> It would be a stretch to put any of the tool on either of those lists.

OK, but your second list has a different set of qualifications than the first. You originally just asked for "useful" programs, and that's what you asked for in the original comment I responded to. Now it's "very technically impressive". So which do you want?

I feel like it's probably not a bad idea to ask exactly what you mean by "technically impressive" as well, since I think it's hard to argue that ripgrep and polars don't at least have technically impressive parts in them.

> Given the popularity of Rust, and that it's now over 10 years old, I'd expect at least one major program that can serve as an example of "here's this very useful, complex software package, as proof that our methodology works and you can do cool things this way."

That seems like a bit of a questionable metric to me.

Given that Rust was explicitly designed and intended to be incrementally adoptable in existing codebases, it doesn't make sense to me to solely look for standalone programs since incremental adoption is very much part of "our methodology". This also sort of ties into your expectation in the first place - I'm not sure I'd expect the same given Rust's design and niche, as well as the general software landscape now vs. when C/C++ were a similar age.

burntsushi 3 days ago | parent | prev [-]

Classic example of moving the goalposts. You'll keep doing it no matter what examples people give you.

aw1621107 3 days ago | parent | prev [-]

> 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.

I think there might be some mix between "we don't want any of the new features" and "we want the new features but can't". Probably hard to get good data on the precise split.

> A standard that can't be implemented is worthless, and even the "3 high quality" implementations of C/C++ haven't fully implemented the latest 2 editions of either language.

This is a bit black-and-white. Just because a standard isn't fully implemented doesn't mean the parts that are implemented can't be useful, especially if the "haven't implemented this yet" is more due to a lack of manpower/attention/desire/etc. than actual impossibility (e.g., libc++ and parallel algorithms/<charconv> vs. export template).

npoc 4 days ago | parent | prev [-]

I agree. A lot of new additions to C++ make coding with it simpler, not more complex. However it does mean there's more to learn, because the old style of the language still exists and is still accepted by the modern compilers as opposed to say, Rust which removes replaced language features when it releases a new edition.

pjmlp 4 days ago | parent [-]

Language, not libraries.

Editions are rather limited in what they support.

Try to design a crate that stays compatible across editions, while using libraries that have changed signatures across editions.

The crate itself keeps its own edition fixed.

lifthrasiir 4 days ago | parent | prev | next [-]

C++ historically had much more implementations. It is probably more about the availability of quality compilers that are free to use and adapt, because even in C most new compilers for niche platforms are now based on GCC or clang for the practical reason.

pjmlp 4 days ago | parent [-]

Both implementated in C++.

As someone that remembers the t-shirts with "my compiler compiles yours" that some C folks used to wear, it is kind of ironic having that turned around on them.

pjmlp 4 days ago | parent | prev | next [-]

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++.

aninteger 4 days ago | parent | next [-]

There seems to be at least 2 lcc forks (lcc-win32/win64, and pelles-c) that have their own small communities. Although maybe they are dead.

pjmlp 4 days ago | parent [-]

Very tiny small communities, what product is being shipped with them?

WalterBright 4 days ago | parent | prev | next [-]

My current C compiler is implemented in D :-)

pjmlp 4 days ago | parent [-]

Plus points for BetterC.

gustedt 4 days ago | parent | prev [-]

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++.

pjmlp 4 days ago | parent [-]

Other than legacy embedded CPUs like PICs, I doubt it.

WalterBright 4 days ago | parent | prev [-]

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

HexDecOctBin 4 days ago | parent | prev | next [-]

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# or C++, why mess with C?

xboxnolifes 4 days ago | parent | next [-]

> 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.

WalterBright 4 days ago | parent | next [-]

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

oguz-ismail 4 days ago | parent | prev [-]

Well they shouldn't have. It was much more fun to program in Python 2.7 and Java 7, I wouldn't touch those languages with a five feet pole these days

lifthrasiir 4 days ago | parent [-]

Why specifically Python 2.7 and not, like, 1.5? Python 1 and 2 are as different as 2 and 3 (that is, surprisingly not much).

pjmlp 4 days ago | parent | prev | next [-]

No, many people chose C, because they had to.

sarchertech 4 days ago | parent [-]

Yeah but those people are running it on some platform where it’s the only choice. And they are probably running a subset of C99. The likelihood of new features ever making it to those platforms is close to zero.

pjmlp 4 days ago | parent [-]

There is hardly any new C compiler that isn't C11.

sarchertech 3 days ago | parent [-]

I’ve been out of embedded for a bit but last I checked almost nothing actually implemented all of C11?

pjmlp 3 days ago | parent [-]

There is hardly any compiler worth using that isn't a fork of either GCC or clang.

So unless they are stuck on a pre-historic fork, they support C11 as much as clang and GCC do.

Exception for stuff like PIC, Z80,...

Which didn't even support proper C on their glory days.

brabel 4 days ago | parent | prev | next [-]

This is funny because Java people say the same about Kotlin and Scala.

WalterBright 4 days ago | parent | prev [-]

C added the absurd normalized Unicode identifiers.

dmitrygr 4 days ago | parent | prev [-]

Because there must be at least one refuge for the sane

flykespice 4 days ago | parent | prev | next [-]

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?

OCTAGRAM 4 days ago | parent | prev [-]

Eiffel has unsolicited tracing garbage collection. For TGC-free programming there is Ada