I love C. It's what I learned after learning MASM style Intel assembly. I have a project still at the planning stage. I have many Rust crates lined up. So far I really like the bits of Rust I have learned. C plus generics? Sign me up! But damn, after coming from really awesome IDEs like Visual Studio, it just seems like it's taking me forever to make progress. Right now I'm asking myself, does Rust save me time in th…
Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
51–60 of 118 posts
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#52Earlier quoted context omitted.
I would be interested to see someone write a program in any language (other than ones specifically designed to combat this, rust…) using threading and guarantee it to be data/race safe. But, I’m not arguing with you. I honestly think that any corporate codebase after double digit years (and seven figure LoC) turns into a completely unmanageable mess. If it isn’t, it’s because of the team culture and pure rigor. Not t…
> I would be interested to see someone write a program in any language (other than ones specifically designed to combat this, rust…) using threading and guarantee it to be data/race safe. I don't limit my statement to just C. The topic was C however so I mentioned C.
I’ve worked in a lot of massive and unmaintainable codebases, and I’ve always had the most fun untangling C ones. I don’t know exactly why, but I suspect it’s because at their core they are always plain ol’ simple C.
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#53Earlier quoted context omitted.
No, the problem is not that modern CPUs want to be a PDP-11, it's that they want to be an 8086 for compatibility reasons. From the software's perspective, the ISA *is* the hardware. It doesn't matter if the CPU is internally recompiling everything to a RISC-like architecture with an arbitrary number of registers because there's nothing i can do to access that. If there's ever a radical new ISA which supplants x86 whe…
> From the software's perspective, the ISA is the hardware Precisely! And because the weirdness happens below the ISA, all the mismatches Dave Chisnall describes apply to any other language just as much including actual machine language. So raw machine language is not a low-level language? .
It'd be interesting to see what interface we'd choose today with multiple decades of hardware and software development.
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#54Yesteryear?
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#55The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at a fairly core level without too much effort. Please don’t start a C flame war either HN. I know I’m nerd sniping you all on this one
Write a multithreaded program guaranteed to have no data races in C and tell me that C is simple. C _looks_ simple, deceivingly so. As soon as you need to deal with a large project in a corporate environment on a code base aged in double digit years you don't think it's simple anymore. C is incredibly complex, unmanageably so.
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#56I hated learning/using C. Once I was introduced to C++, it was like a breath of fresh air. Sure, at lot of it stylistic in nature. But those frameworks matter. They really do.
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#57Earlier quoted context omitted.
>As soon as you need to deal with a large project in a corporate environment on a code base aged in double digit years you don't think it's simple anymore. I've done this before, never felt like C wasn't simple.
How big was the project and how many people were maintaining it? And were the people maintaining it the same people who started it? Perhaps I should have included a statement about coming in to work on a project that was already double digits old when you started working on it.
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#58Unmanageable really has a context and depending on the use case sometimes C is the best option…
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#59Unmanageable really has a context and depending on the use case sometimes C is the best option…
I lol every-time someone quotes their favorite JIT language that is essentially a meta-circular compiler for C library bindings. “It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.” ( Albert Einstein )
Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]
#60Earlier quoted context omitted.
Cases can arise where ownership of objects are not clear (which is a separate issue) but when they do occur, you can have a custom destructor that frees a lot of other objects, and then these other objects may in fact be "owned" elsewhere. Somewhere down the line these other objects are freed again, causing double free.
How would malloc/free be better in that situation?