[NCLUG] A brief note about C and potential successors.

Brian Sturgill bsturgill at ataman.com
Fri Jan 17 09:12:28 MST 2020


The problem with header files is two fold.
First, it requires declarations to be placed in two different files.
The original source and the header, meaning changes must be made in two
places.

Second, sizable projects have numerous nested files, so do operating
systems, sizable runtimes, etc. The result is large compile times, even for
trivial files.
If even one of these files changes, the whole mess has to be read in and
recompiled. If you don’t manage your dependencies perfectly, you can get
runtime failures, because a tiny change in one file didn’t trigger a
recompile.

Brian

On Fri, Jan 17, 2020 at 6:18 AM Grant Johnson <grant at amadensor.com> wrote:

> While I completely agree about memory handling, I'm not sure what the
> trouble with the header files is. Please elaborate.
>
> I just want to learn more about where it might bite me.
>
>
>
>
> On January 16, 2020 5:51:58 PM MST, Brian Sturgill <bsturgill at ataman.com>
> wrote:
>>
>> I asked about Go usage at the last meeting and was met with quite a number
>> of people expressing disdain that I thought C should be replaced. I've
>> programmed in C since 1980 and used very early versions of C++ from Bell
>> Labs (when it still translated to C). I was an early user of the Bliss
>> programming language but quickly saw that C was much more portable. I made
>> the switch to C from Assembly language around the time C was about twice
>> the overhead over hand-coded assembly. Having read Mythical Man-Month, I
>> was well aware that the key factor in a programming language is how quickly
>> one can express what needs done (in a maintainable manner). Many of my
>> friends at the time resisted the move to C believing that the overhead was
>> too large. However, C easily required an order of magnitude less code to
>> get a job done... it was a clear win in all but the most CPU intensive of
>> tasks.
>>
>> So, what I want to point out is that all the big places see the problem
>> with C.
>>
>> Apple has Swift.
>> Mozilla, has Rust.
>> Google has Go.
>> And now Microsoft has a Rust fork:
>> https://www.zdnet.com/article/microsoft-were-creating-a-new-rust-based-programming-language-for-secure-coding/?utm_medium=email&utm_source=topic+optin&utm_campaign=awareness&utm_content=20191207+prog+nl&mkt_tok=eyJpIjoiWkdJNU1HSTBZV0V4TkRRMyIsInQiOiI5TjloM0Zzc2R3NnZrOHJhSlV0RWx6WFMrcnFKQ1BSZ1dqbDhHY0FjTzJQY1lFTHJ5citrcklEcUJHcmFCeFljcnY5QmUrTlowVWh4NCsrblRiNHpkRWY1UHUzRmNUam9pbzNLZlBqS3puQld0K2VpZ2NRWXhKaW5mNm5qdm5mZyJ9
>>
>> The big problem C solved was increased expressiveness while still providing
>> speed.
>>
>> It however has many problems from it's legacy creation. For example header
>> files and memory handling. All those things made sense then, but they need
>> to be abandoned for more modern approaches.
>>
>> Swift, Rust, and Go all are about 2 times times the overhead of C.
>> They all solve most of C's problems, yet still provide good efficiency.
>> They also require less lines of code to express a given task.
>> They are built with maintainability in mind.
>> They all compile QUICKLY.
>>
>> You may have noticed I don't include C++ here. C++ has nearly all of C's
>> flaws.
>> C++ "solutions" for things like strings may actually be worse than the the
>> problems they were trying to solve.
>> I'll also point to Rob Pike's take on C++:
>> http://lambda-the-ultimate.org/node/4554
>>
>> I used to do a lot of stuff with Google and saw a Rob Pike talk about C++,
>> he said that recently he moved to a new office that only half the space of
>> his old one. He said moving to the smaller space was simple, he left his
>> printed copy of the C++ spec behind.
>> [I had a printed copy of the pre-11 C++ spec, it was several feet tall
>> (doubled sided, laser printed)]
>>
>> Seriously, it's time to move on from C.
>>
>> Brian
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
-- 

Brian


More information about the NCLUG mailing list