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

Grant Johnson grant at amadensor.com
Fri Jan 17 06:17:49 MST 2020


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
>
>-- 
>
>Brian
>_______________________________________________
>NCLUG mailing list       NCLUG at lists.nclug.org
>
>To unsubscribe, subscribe, or modify
>your settings, go to:
>http://lists.nclug.org/mailman/listinfo/nclug

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


More information about the NCLUG mailing list