50 years of C, the good, the bad and the ugly [video] • Hacker News Board

Re: 50 years of C, the good, the bad and the ugly [video]

#111

Post by menaerus » Fri, Dec 30, 2022, 6:00 PM UTC

titzer wrote: post #108

WastingMyTime89 wrote: post #52

Earlier quoted context omitted.

It’s mostly semantically very poor to be honest. C really is a nicer assembly in a lot of way. It’s extremely limited. You have branching logic, functions call, pointer arithmetic, a way to define data structures which are really memory layouts and that’s pretty much it. I guess you can appreciate that as an aesthetic statement but what you wrote would apply equally to any language with more complex semantics.

C would be a better language if it really lived up to its old ideal of being a "portable assembly language". That stopped being true as compilers started optimizing undefined behavior (e.g. signed overflow). Instead of a "+" in the source code yielding an honest-to-goodness hardware add instruction, it could be "optimized"--i.e. constant folded, CSE'd, strength-reduced, value-range-analyzed, among others--by an optim…

In the absence of CPU instruction which does the saturated ADD, how do you solve the overflow problem in a bare-metal language without introducing the performance hit?

Re: 50 years of C, the good, the bad and the ugly [video]

#112

Post by w10-1 » Fri, Dec 30, 2022, 6:03 PM UTC

hgs3 wrote: post #28

fjfaase wrote: post #2

His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.

C is the best abstraction for many problem domains and that isn't going to change. I understand why folks coming from higher-level languages would dislike it, but for anyone coming from assembly it's a godsend. The speaker discourages C for new projects, but that says more about the problem domains they work in than C itself. C is what it is because the hardware and assembly language are what they are. Folks who want…

> Folks who want a safer C should design a new hardware architecture with a "safe" assembly language and a new low-level language that targets it

Would that be LLVM's IR or MLIR (https://mlir.llvm.org)?

Re: 50 years of C, the good, the bad and the ugly [video]

#113

Post by sph » Fri, Dec 30, 2022, 6:11 PM UTC

bakuninsbart wrote: post #73

colanderman wrote: post #59

Earlier quoted context omitted.

Art is often about constraint, and mastery of simple tools. I identify with @antirez's sentiment. I know both C and C++ very well. I find C definitely more artistic. C++ is utilitarian. Prolog is the other language I code in "artistically". It too is quite simple and constrained, though it is on the opposite end of the high/low-level spectrum as C.

What is your take on Perl and Ruby? They seem to be the two languages where the communities themselves talk the most about poetry and elegance.

Perl and Ruby are very expressive. Python on the other hand feels like a scripting language designed by a 1990s corporate Java developer.

/unpopular-hot-take

Re: 50 years of C, the good, the bad and the ugly [video]

#114

Post by KnowOneYouNo » Fri, Dec 30, 2022, 6:15 PM UTC

kovac wrote: post #30

fjfaase wrote: post #2

His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.

Can C really completely go away as long as there's embedded programming? Are there any other alternatives for that domain?

Ada is a much better and modern alternative for embedded, real-time and/or systems programming. Its mature, (although still evolving) and very scalable from very, very small to very, very large systems. It also supports interoperability with C and C++. It is a primary language in GCC. See https://ada-lang.io/ and https://learn.adacore.com/

Unfortunately Ada is held back by a genuine lack of awareness and some old misinformation baggage.

Re: 50 years of C, the good, the bad and the ugly [video]

#115

Post by Someone » Fri, Dec 30, 2022, 6:18 PM UTC

menaerus wrote: post #109

Conscat wrote: post #100

Earlier quoted context omitted.

Without it, you cannot express arithmetic wrappers or simd wrappers. So far, no language with any users has managed to provide adequate arithmetic and simd types built in, despite several attempts like Odin and CosmiC/HolyC. I'm not sure it's even possible to design such types that satisfy everyone, and they must be extensible somehow because satisfying anyone is a moving target. Note how terrible doing any amount of…

Also without operator overloading, it wouldn't be possible to implement lazy evaluation, which along with the use of expression templates happens to be one of the most crucial aspects that any linear algebra library will want to take advantage of in order to generate the most optimal code.

> without operator overloading, it wouldn't be possible to implement lazy evaluation

I don’t understand that. You can have functions that return promises that then can get passed to other functions returning promises, and leave it either to the compiler or to an expression evaluator you write (that ideally runs at compilation time as much as possible) to optimize away anything not needed. For example (pseudo-code)

  vector3D a = …
  vector3D b = …
  promise c = addLazily(a,b)
  print c.x

in the end, could do the equivalent of

  print a.x + b.x

I think you could make a modern C++ compiler do that for this simple example.

Re: 50 years of C, the good, the bad and the ugly [video]

#116

Post by Someone » Fri, Dec 30, 2022, 6:26 PM UTC

sn41 wrote: post #61

WastingMyTime89 wrote: post #52

Earlier quoted context omitted.

It’s mostly semantically very poor to be honest. C really is a nicer assembly in a lot of way. It’s extremely limited. You have branching logic, functions call, pointer arithmetic, a way to define data structures which are really memory layouts and that’s pretty much it. I guess you can appreciate that as an aesthetic statement but what you wrote would apply equally to any language with more complex semantics.

> that’s pretty much it. Only if you ignore 1. variadic arguments as in printf, 2. function pointers which are a very elementary (type-unsafe) form of closures, 3. a nice way of casting to void 4. setjmp and longjmp goodies (?) which allow you to code up co-routine libraries and exception handling mechanisms I'm sure there are more such facets I am missing. The elegance of the specification may be questionable, but t…

C is also relatively poor at providing “a way to define data structures which are really memory layouts”. Integer sizes (historically) and padding are implementation-defined, AFAIK bit fields are underspecified in that you cannot specify in what bits of a byte they end up.

Re: 50 years of C, the good, the bad and the ugly [video]

#117

Post by zozbot234 » Fri, Dec 30, 2022, 6:27 PM UTC

menaerus wrote: post #111

titzer wrote: post #108

Earlier quoted context omitted.

C would be a better language if it really lived up to its old ideal of being a "portable assembly language". That stopped being true as compilers started optimizing undefined behavior (e.g. signed overflow). Instead of a "+" in the source code yielding an honest-to-goodness hardware add instruction, it could be "optimized"--i.e. constant folded, CSE'd, strength-reduced, value-range-analyzed, among others--by an optim…

In the absence of CPU instruction which does the saturated ADD, how do you solve the overflow problem in a bare-metal language without introducing the performance hit?

The performance hit of overflow has nothing to do with lacking assembly instructions. It's all about having to preserve error states whenever overflow occurs and inhibiting optimization.

Re: 50 years of C, the good, the bad and the ugly [video]

#118

Post by asveikau » Fri, Dec 30, 2022, 6:29 PM UTC

zozbot234 wrote: post #37

Decabytes wrote: post #8

Earlier quoted context omitted.

I think it will go when we have a sufficiently popular and useful systems programming language that will replace it. It has to be a language that isn't just C with some extra bits, which is why SafeC and CheckedC aren't more popular. I actually think the closest language will be Zig. It's a much simpler language than Rust and people who like C really value that simplicity. It also removes a lot of Cs baggage that mak…

SafeC and CheckedC do nothing for temporal safety. Zig is in the same boat. There's not really a simpler alternative to Rust with the same featureset, even its direct predecessor Cyclone was in fact quite a bit harder to use. Rust itself is also improving very quickly and becoming easier to use over time.

Rust seems to have a lot of C++ influence to me, specifically later C++ where RAII and smart pointers became the norm. This makes sense that it came out of Mozilla, who have always had large C++ code bases.

Re: 50 years of C, the good, the bad and the ugly [video]

#119

Post by tialaramex » Fri, Dec 30, 2022, 6:32 PM UTC

Koshkin wrote: post #84

siftrics wrote: post #54

Earlier quoted context omitted.

This shouldn't be downvoted. C++ is a superset of C; it must be capable of being at least as "brutal and honest" and "abstract and deceiving" as C. I would argue that C++ can be dramatically more deceiving than C --- see inheritance and operator overloading, just to name two.

Operator overloading is the one thing that makes C++ strictly better than any language that does not allow it.

Overloading is miserable. C++ has to provide this as an overload because it still, decades after standardisation and half a lifetime after it was created, doesn't have a way to just extend types.

If you can just extend the types then you can provide operators that way and there's less opportunity for ambiguity. See Rust.

Also so many of the C++ operator overloads are broken instead of just not existing, which tempts you to overload things instead of saying "Nope, that's a bad idea" and just walking away altogether.

Example, boolean short-circuiting AND and OR. If we write

    if (this() || that()) foo();

in C++ then that OR is short-circuiting, so that() won't get called if this() is true.

But if the return type used overloads the boolean OR operator, short-circuiting is disabled, and now both this() and that() are always called...

Re: 50 years of C, the good, the bad and the ugly [video]

#120

Post by MrLeap » Fri, Dec 30, 2022, 6:37 PM UTC

sph wrote: post #113

bakuninsbart wrote: post #73

Earlier quoted context omitted.

What is your take on Perl and Ruby? They seem to be the two languages where the communities themselves talk the most about poetry and elegance.

Perl and Ruby are very expressive. Python on the other hand feels like a scripting language designed by a 1990s corporate Java developer. /unpopular-hot-take

I mostly agree with this. I'll come to python's defense though. Python is a gorgeous language wearing an ugly hat. The hat has __multiple out of place brims__, all of which are about two underscores wide.