Live data from Hacker News

Let's Destroy C

gist.github.com

111–120 of 192 posts

Re: Let's Destroy C

#111

C has its place; every language has its quirks. I think a lot of emphasis needs to be put on testing code. Like SQLite uses Tcl to script tests. C is easy to test because the “software units” are only structures and functions.

> C has its place; every language has its quirks. I think a lot of emphasis needs to be put on testing code.

The library that this post is a subset of, actually does have a testsuite. It compiles every example, and it's own documentation. The testsuite still needs to grow, and check evaluations rather than whether something "works", but it's getting there.

Re: Let's Destroy C

#112
post #38
post #18

Earlier quoted context omitted.

To emphasise: This is about Bournegol. Nothing to do with this post. > Can you explain why? Because it isn't how most C libraries expect true/false to be defined. stdbool in C99 standardized things a bit, but before then what was generally accepted was: > true is 1 > false is !true (Often 0 in practice). Which means that any trivial: if(true) { ... } Won't work under Bournegol. Instead you _need_ to compare when doin…

Most cases I've seen accept anything as true as long as the LSB is 1, and quite strictly 0 as false. Everything else is up in the air. The value -1 is definitely true. :)

> The value -1 is definitely true

Except when being used as a comparison to any of the std utilities.

Re: Let's Destroy C

#114
post #96

This just in: you can write bad code in any language. In this case, that language is the C Preprocessor, already well documented and widely accepted as a Bad Language To Start With. The title of the article is misleading: it's not "destroying C" it's writing Bad Code using the C Preprocessor. It's not destroying C any more than a series of bad puns destroys the English language.

> This just in: you can write bad code in any language.

Pretty sure I pointed that out:

> Can we turn C into a new language? Can we do what Lisp and Forth let the over-eager programmer do, but in C?

---

> The title of the article is misleading: it's not "destroying C" it's writing Bad Code using the C Preprocessor.

To put it another way, when I look at something like this, I might moan and say, "They've ruined it."

It's an expression.

Re: Let's Destroy C

#115

> printf("%s\n", "Hello, World!"); > > That's an awful lot of symbolic syntax. Well... Because it should have been printf("Hello, World!\n"); in the first place? One can do something like printf("%s,%s%c\n", "Hello", "World", '!'); and claim that C is awful and that displayln("Hello, World!"); is so much better.

How about just puts(“Hello, World!”) which has been in C since the dawn of time?

I think this is part of the problem with the language- a fragmented set of keywords, all with slightly different behavior.

Re: Let's Destroy C

#116
post #37
post #27

You invented Ada.

Unsurprisingly, I adore Ada. However, Ada's main benefits - the incredible type system, don't exist at all here. CNoEvil is a giant shotgun pointed directly between your legs.

Ada is definitely optimized for readability (not you, Ada.Strings.Unbounded.To_Unbounded_String!)

Re: Let's Destroy C

#117
I've been a C programmer for several years now (out of necessity - C is still the best language for firmware and embedded development)

There's been a lot of noise on the internet about Rust and C++20 and "modern" languages. I recently had an opportunity to try some of these first hand.

Honestly the new language features are all terrible with few exceptions. In general, anything that was added to a language to support generics or to hide pointers and memory management from the developers on a language that isn't a lisp has only produced more harm than good.

I grew up as a programmer always thinking about the underlying CPU and the underlying memory and how my code would interact with both of them. It requires greater care as a programmer and tools like static analysers, code reviews and rigorous testing are extremely important. Improving these tools and coming up with new ones is far more useful (in my opinion) than trying to update C.

Yes C has it's flaws. Sometimes, those flaws are important and a replacement language is useful. I find that Go is a very interesting replacement for C at sufficiently higher up the stack. Something like Haskell probably will best fill in the gaps between C and Go.

I'm not convinced that fixing C with something like C++ was a good idea. Similarly, anything that's trying to fix C++'s problems is unlikely to come up with a decent way to have generics and hide memory and pointers from developers.

If I was going to create my own language, I'd keep it like C, remove some of the undefined behaviors, add support for Posits, 128 bit and arbitrarily wide signed and unsigned integers, features for explicit cache management (!!!), container classes as part of a standard library, Go-lang style interfaces and bake in something like cppcheck into the compiler.

/rant

Re: Let's Destroy C

#119

I've been a C programmer for several years now (out of necessity - C is still the best language for firmware and embedded development) There's been a lot of noise on the internet about Rust and C++20 and "modern" languages. I recently had an opportunity to try some of these first hand. Honestly the new language features are all terrible with few exceptions. In general, anything that was added to a language to support…

I feel the same way you do, but I still want to spend more time getting to know Rust.

Re: Let's Destroy C

#120

Well there is the International Obfuscated C Code Contest.... Details here.... https://www.ioccc.org/

The IOCCC was inspired by Steve Bourne using precisely this kind of tricks in the C source for the Bourne Shell to make C look like Algol-60.
Post reply on HN