Why is C so awesome and easy to understand vs. other languages?

**Asymptotic** · 12-22-2016

I'm finding more and more that I enjoy programming in C instead of other languages like C# and Java because it seems that you get to do more actual programming or deal with the more primitive parts of the language on a regular basis. Honestly, it's hard for me to pinpoint but it's just different. I'll give you a brief example:

Something I'm working on in C:

Code:

void update_scan(MEMBLOCK *mb_list, SEARCH_CONDITION condition, unsigned int val)
{
  MEMBLOCK *mb = mb_list;
  while(mb)
    {
      update_memblock(mb, condition, val);
      mb = mb->next;
    }
}

And something I'm dealing with in C#:

Code:

public string Protect(AuthenticationTicket data)
 public class CustomJwtFormat : ISecureDataFormat<AuthenticationTicket>
    {
    
        private readonly string _issuer = string.Empty;
 
        public CustomJwtFormat(string issuer)
        {
            _issuer = issuer;
        }
 
        public string Protect(AuthenticationTicket data)
        {
            if (data == null)
            {
                throw new ArgumentNullException("data");
            }
 
            string audienceId = ConfigurationManager.AppSettings["as:AudienceId"];
 
            string symmetricKeyAsBase64 = ConfigurationManager.AppSettings["as:AudienceSecret"];
 
            var keyByteArray = TextEncodings.Base64Url.Decode(symmetricKeyAsBase64);
 
            var signingKey = new HmacSigningCredentials(keyByteArray);
 
            var issued = data.Properties.IssuedUtc;
            
            var expires = data.Properties.ExpiresUtc;
 
            var token = new JwtSecurityToken(_issuer, audienceId,  data.Identity.Claims, issued.Value.UtcDateTime,  expires.Value.UtcDateTime, signingKey);
 
            var handler = new JwtSecurityTokenHandler();
 
            var jwt = handler.WriteToken(token);
 
            return jwt;
        }

Obviously, this isn't really a fair comparison because those two code blocks do something entirely different, but my point is that when I'm working in C#, especially in the popular web dev world right now, it seems I'm always having to fight to understand what on earth this convoluted mess like:

Code:

var token = new JwtSecurityToken(_issuer, audienceId,   data.Identity.Claims, issued.Value.UtcDateTime,   expires.Value.UtcDateTime, signingKey);
 
            var handler = new JwtSecurityTokenHandler();
 
            var jwt = handler.WriteToken(token);
 
            return jwt;

Is doing. It just seems like so much text and noise for not very much going on. There seems to be an overflow of jargon used in the .NET world as well, which doesn't seem to do anything other than make things sound more complicated than they are. For example:

Code:

 public override Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context)
        {
            context.Validated();
            return Task.FromResult<object>(null);
        }

        public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
        {

            var allowedOrigin = "*";

            context.OwinContext.Response.Headers.Add("Access-Control-Allow-Origin", new[] { allowedOrigin });

            var userManager = context.OwinContext.GetUserManager<BusinessAccountManager>();

            BusinessAccount user = await userManager.FindAsync(context.UserName, context.Password);

All this this.that.thekitchensink.dowhateverproviderservice blahblah. And the long names like this: "OAuthValidateClientAuthenticationContext" honestly it just seems like terribly convoluted code to me.
I'm self-taught so I'm sort of an outsider on this... is this just how Object-Oriented Programming is versus procedural code or is it just that I'm probably seeing a lot more messy code in the C# world because it's full of newbies? Another thing which I really dislike about other languages versus C is in C I tend to be struggling with the language/compiler itself, which I enjoy whereas when I'm trying to do C# and back-end web development, I tend to spend most of the time struggling with and trying to figure out other people's code that my application depends on. I don't enjoy this.

Anyways, has anyone else noticed this? Is this a C vs. other language thing or is it just the people/community/tools that I've specifically been involved with in the other languages?

**rcgldr** · 12-23-2016

It's probably more to do with the type of program you're trying to write than the language. I wrote a C program for file and folder backup / restore (an entire tree or partition) for Windows, and takes over 40 lines of code just to enable backup, restore, and security privileges. It also takes quite a few lines to copy security or reparse point info for a file or directory.

There are a few languages a bit more difficult to learn, such as APL (A Programming Language), which some consider to be "write only", since it's difficult to follow other peoples programs. I'm not sure it's worth learning, but it does have a lot of operators which work on scalars, vectors, matrices, ... . Example video coding Conway's game of life using a one line function:

Conway's Game Of Life in APL - YouTube

**Asymptotic** · 12-23-2016

Originally Posted by rcgldr

It's probably more to do with the type of program you're trying to write than the language.

There are a few languages a bit more difficult to learn, such as APL ...

Conway's Game Of Life in APL - YouTube

Wow! That's very interesting, I've done a Conways in C# too so its fun to see another implementation. Definitely a different language!

I agree with you. It is tough to just say "language xyz is easier to read than language abc" and I think that is also subjective.. It definitely has to do with who wrote the code though... What it may be is that I personally don't like Microsoft's coding style. It's interesting because I enjoy the C# language and I seem to be able to produce quite legible code in it as well. However, as it is Microsoft's baby, of course C# programmers often see a lot of MS C# dependencies/externals and those externals IMO often introduce unnecessary complexity. Like if that code I wrote above was simply just worded differently, it would probably be a lot easier to understand.

That said, I do feel like because C doesn't have as many built-in "constructs" as C++, C#, and so on, for that reason, it is by definition often easier to read, or at least there is not as wide of a range of crap that can be thrown in. For example, I'm new to C but I can look at Linux Kernel code and get the gist of what's going on as soon as I understand what things like void* and the multithreading functions do, but classes, generics, inheritance, and interfaces seem to add an entire other level of complexity, and on top of that you got guys writing object names like OAuthValidateClientAuthenticationContext and abusing the heck out of the "var" keyword.

Interestingly, the Win32 API was also written by MS in C but it structured entirely different from their C# code. It's also not my favorite C code, I find Linux C a lot easier to understand. And no, Linus is not holding a gun to my head right now

But I feel like Microsoft's C Win32 API code is a lot more "no frills" or down-to-earth whereas their C# code is like a dog and pony show. Man, this is getting artsy now... I guess code really is an art, it comes with feelings, expression, and interpretation!

**Elysia** · 12-25-2016

For your example, it seems easier because there's no a bit of security built-in, whereas in the C# code, security is an integral part of it, and yeah, security makes code more complex. Also, C# is part of the object-oriented world, which is very different from C. It's a different mindset. In object-orientation, you usually work with big objects which are an abstraction of some kind of data, but you don't need to know what. In C, you tend to work more with primitives, and you are apparently more used to that, which is probably why you find C# jargon to more difficult. Also, as to why you having trouble understanding what OAuthValidateClientAuthenticationContext means, it's probably because you're aren't used to web stuff, or at least, that's my guess. Because if you were, that name should be obvious.

As for "more crap thrown in makes it harder to understand"... well, to a certain extent, you're right. But it can also help in many ways. For example,

a + b (where a and b are strings)

it much easier to parse and read than It does

strcat(a, b);
// Plus checks for overflow
// Plus checks for null pointers

Because tend to abuse tools for purposes they weren't meant to be used for, but if used correctly, then you can glance simply from the tool used what the programmer is trying to achieve more easily. These tools do add extra complexity, but if used right and you understand their meanings, it can make code easier to understand and maintain.

**swgh** · 12-25-2016

> But I feel like Microsoft's C Win32 API code is a lot more "no frills" or down-to-earth whereas their C# code is like a dog and pony show.

Windows Vista's pre-alpha development went through a total code change when it was being written. Originally, Microsoft had intended the entire OS be written in .NET (probably to further push the Framework and C# as the target language). However, this was scrapped and some very tired and fatigued programmers had to restart the entire project and write in C, C++ and bits of Assembly (like it's always been). This is one reason why some things are better coded and easier to understand in on language than the other. Would you write a new OS that had to run fast and never have to pause to "free memory" - then you would never choose Java or C#. They have their place of course - as do all other languages.

**Elysia** · 12-26-2016

Originally Posted by swgh

...This is one reason why some things are better coded and easier to understand in on language than the other...

I don't think that's the reason they halted the use of .NET is Vista. I think it is, as you said, that the OS simply became too slow. .NET is a good high-level language, but it just can't do what C/C++ can when it comes to optimizations because it simply wasn't designed for it.

Also, in Windows 10 today, the new Modern Platform API is essentially a version of their .NET API.

**freddie** · 12-26-2016

Interesting post. I went through all this around 2002 when .NET came out. Had to face some agonizing philosophical issues and make some hard choices in my life and career because of it.

At that time I was using two really different programming languages - C and pre - .NET Visual Basic, i.e., VB 4 - 6. I could do Windows GUI programs in C using Charles Petzold's Win32 API techniques, and I loved coding that way, but I didn't know how to create as fancy of an application as I could easily do in Visual Basic. In my work I used databases a lot, and GUIs involving databases tended to use grid controls a lot, and Win32 didn't really have grid controls - closest thing being the Listview Control in the Common Controls Library (ComCtl32.lib), which a lot of enterprising folks were using as grids by adding extra code.

But anyway, along came .NET and I threw about a whole year into learning that; I purchased both Petzold's C# and VB book, as well as several others. Trouble was I hated it. I took it about like medicine; you know, its supposed to be good for you so just make a horrible face, pucker up your nose and swallow it. I was thinking about my career at that time too. If I learned .NET I'd probably have better job prospects.

I remember well the day a final reckoning had to be done and a hard decision had to be made. After spending like a year doing nothing but studying .NET I was finally going to tackle a big job at work using it. Like I said, I do databases and grid controls a lot. So what I was trying to figure out was how to set the column widths on the grid control I was using. Well, in .NET (and OOP in general) you have objects. And objects have sub-objects. And some sub-objects have sub-sub-objects. And finally at some point you drill down to the properties of these sub-sub-objects of the main object which is the grid control. So maybe you have...

grid.header.columns_collection.column(1).width

...or something even weirder. I wasn't able to figure that all out by myself. I poured over the gigabytes of documentation but my documentation searching skills weren't up to the task. In desperation I searched the internet for an answer and naturally I found one. Piles of folks were having the same difficulties I was encountering. So I finally found some code illustrating the deeply nested object hierarchy necessary to adjust the column widths of the grid control. Maybe a day of time got ate up through that whole ordeal.

But it was the 'straw that broke the camel's back' for me. At that point I saw the future. I now knew what it looked like. Whatever coding skills or knowledge of algorithms I had at that point I didn't need to improve them. In fact, I didn't need to write anymore code at all. It was all already written. All I needed to do was learn how to find it, copy and paste it into my application, and occasionally glue it together.

That's where the breaking point came for me and why I said I had to make some really hard choices. Also during that time I had been experimenting with other programming languages (I'm something of a programming language junkie), and I had worked really hard at teaching myself C++. But I eventually abandoned that because it didn't turn out to be what I expected at all. Because of my extensive background in pre-.NET Visual Basic, whose foundational principals were based on a completely different object model from the one C++ used, i.e., OLE/COM (Object Linking and Embedding / Component Object Model), I simply didn't like the way C++ went about things. It seemed to be the worst of all possible worlds. Old Visual Basic was super powerful and easy to use, although bloated. What with all the runtime dependencies you had to lug around several megabytes of code as well as run an install program that made changes to the Windows Registry just to get a "Hello, World!" program to work. With C++ you had most of the above in terms of drawbacks but it was hard to learn and use. But the worst problem I found with C++ was that it wasn't 'intellectually honest'.

With old VB 4-6 everything was magic and you recognized it as such. You didn't have to know how anything worked under the hood. It was totally encapsulated within the VB runtime. You were reusing code at the binary level - not source code level. You could honestly say that you understood every line of source code in your app and what it did. You wouldn't know how it did it because that was in the runtime. But you would know how each line of code you wrote in your application advanced the purpose of your application.

With C++ not so. While you could use fancy objects in your apps such as grid and charting controls, you had to use a lot of auto-generated wizard code produced by Microsoft's development environments, or included in source code form in sub-directories of your build chain, i.e., MFC, ATL, etc. And while there are a lot of folks in the Microsoft C++ world who use that stuff, very, very few of them understand it at its deepest level, i.e., if they did not have it to use, they wouldn't know how to use C++ to generate the same functionality as they had using it. So in that sense they are in no way superior to the folks who just use Visual Basic and are done with it and accept the fact that they don’t understand how it does what it does and are OK with that.

So I abandoned .NET at that point and never looked back. I did have an important application to develop at that time though, but I backed up to using old Visual Basic 6 (which wasn’t all that old around 2002), at which I was quite expert. But also around that time I discovered another Programming language and programming community known as PowerBASIC. That language could best be described as a high level implementation of MASM or Microsoft’s Macro Assembler. It uses the exact same variable types as MASM and the compiler itself is written in MASM. It was a niche or specialty language which a lot of professional Visual Basic developers used to create high performance dlls to speed up performance critical parts of their code. But you could write whole applications with it and compile to exes too.

The important application I had to write which I started in Visual Basic 6 was a mission critical application that was originally coded in Algol (an important language in the history of programming languages) which ran on a mainframe, but was later redone by a whole team of professional programmers in an OOP based language known as SAS (Statistical Analysis Software, I guess). We had spent millions on that application and it worked like crap. It fouled up its data files, lost data, just about everything bad. Barely usable. And to make it work and keep it running we were spending about a quarter of a million dollars per year in maintenance and upkeep fees by a third party contractor. I was writing the Visual Basic 6 app to see if the application could be done ‘in-house’, and to see if I and Visual Basic were up to the task There was pressure in my organization to re-contract another system to be part of an ‘Enterprise Information Management System’ our IT folks were interested in. But I wanted to ‘head that off’ and see if we could produce the app internally, so that’s why I did the VB6 thing. But upon my discovery of PowerBASIC I knew that would be the ultimate language in which to do the coding – if I was up to it. To make a long story short I did manage it and that has been the system we have been using for the past fifteen years. It is a Win32 Api SDK style app a la Petzold but coded in PowerBASIC. It functions perfectly and is completely bug free. Because of that I am able to spend my time exploring programming concepts and languages.

However, recently I recoded the system in C++. A major tragedy occurred that pointed me in the direction of thinking C++ would have to be the way to go. The creator and lone coder of PowerBASIC passed away in 2013 I think it was. He was working on an x64 version of his compiler, but never finished it. PowerBASIC is a proprietary language that isn’t standardized as C++ is. The good or the best doesn’t always win. I’m near retirement, and didn’t want to leave a code base for my organization based on a programming language that has no future. When that unfortunate day comes when Bjarne Stroustrup is no longer with us, C++ will live on, as C has done since Dennis Ritchie’s passing.

I had always kept my hand in the C world too as I also do the handheld data recorder coding for our handheld data recorders, which originally used DOS, then embedded C++. But I used just C for the longest time – as did most others coding for that embedded OS (Windows CE).

But while I had originally abandoned C++ many years ago, I eventually picked it up again for another look. I was wondering if I had thrown the baby out with the bathwater. While there seemed to be a lot of usages in C++ that I had serious philosophical issues with, there were other aspects of the language I liked a lot. Classes, operator overloading, templates, reference parameters, improved syntax pretty much made up for a lot for C’s deficiencies. So I decided to run with that. When I picked it up again I decided to go about it differently. On my first go around I was trying to teach myself C++ as its supposed to be taught by all the stars in the profession. I had bought all the books, etc. But on this 2nd time around I decided to take nothing whatsoever on faith, and examine every language element critically in terms of needs for the applications I write. If I found some feature useful to me – I’d use it. If I could see no personal use for something – I’d drop it like a hot rock. And so that is what has worked for me. I had to create all my own C++ Library Code because I could find nothing in the C++ Standard Library that met my standards. Everything was either awkward, ugly, bloated or all of the above. While I liked the C Standard Library a lot I had to write my own version of that because I couldn’t link against Microsoft’s versions (LIBCMT.LIB) and end up with binaries as small and efficient as the PowerBASIC binaries I had become accustomed to. So its been a lot of work but at least now I have code I like to work with. I’m telling you all this because you raised the question about C style procedural coding compared to more modern OOP style coding, and you stated your preference for the former. And there are a lot of ancillary issues involved such as C compared to C++, and OOP in general. In closing I’d have to say that using .NET is work in the sense of ‘something unpleasant to do for which one must be paid to do it otherwise nobody would do it, such as cleaning sewers or sweeping streets’. Its pretty much the opposite of creativity in the sense real coders understand it. So yea, its work in the sense I described above. And Microsoft had to create it. They realized that most coders are poor, with no chance whatsoever of writing Win32 Api apps without leaking memory, gdi and kernel objects, and every kind of resource all over the place. So OOP and Class Frameworks were seen as the answer to mediocre programmers not screwing stuff up too bad. It creates bloated executables, but hardware manufacturers will be glad to sell you a bigger hard drive. It runs slow but they'll be glad to sell you a faster computer too. And these aren't the only advantages either. OOP Class Frameworks aren't nearly as stable as the underlying procedural Api code, and they change and come into and fall out of fashion more rapidly. This all creates more jobs for programmers who must continually keep re-writing the very same application (even though the present one works) and keep it updated. Keeps programmers off the streets and out of trouble. Microsoft will get you to buy the next version of Visual Studio too - the one that generates all the wizard code that you need but don't understand.

If you think I'm lying about any of this I'm not. Try these links, which are just a sampling…

Lispian >> Archive >> Lasagna Code

Lispian >> Archive >> Lasagna Code: Redux

Object Oriented Programming is an expensive disaster which must end | Smash Company

**King Mir** · 12-26-2016

It sounds to me like you're just not familiar with object oriented code and style. And I would suggest becoming familiar, because it is a powerful and useful tool. Not that there's anything wrong with procedural code, rather as a programmer it's useful to have a diverse tool belt to solve your problems.

**Elysia** · 12-27-2016

Originally Posted by freddie

Its pretty much the opposite of creativity in the sense real coders understand it.

That "real coder" being you. It's fine to someone to not understand or like something, but it doesn't mean there's a fundamental problem with it. It may just be you. I find it to be much productive than C.

It seems like you don't "like" OOP, and that's fine. But if you're going to convince everyone that it's bad, you need to provide a clear link with a trusted author who lists all bad points and why they're bad, not some rant article.

**swgh** · 12-27-2016

BASIC is exactly that. It was designed to be more of teaching tool for novice programmers to teach the fundamental principles of computer programming. Everything was hidden within the run time because there was no point in exposing newbies to that level of complexity in a first language. The lower you delve the more of the components of the language are exposed to you. C and C++ are both "high level" languages but only in the case they are above bare-bones assembly which is just instruction sets direct to the hardware.

OOP was/is designed to offer a level above the procedural norm of C and the original versions of BASIC. It's a great design choice, and is one that the video game industry in particular has invested years of code base into. It's not too difficult to learn either, you can easily learn the procedural parts of C++ before touching any aspect of the OOP features. C# and Java are entirely OOP anyway, so being exposed to C# should make C++ quite a smooth transition.

**MutantJohn** · 12-27-2016

C is easy and awesome because the language is like 8 keywords. It's pretty great. It's a very simple language from that kind of perspective. Doing anything "real" in it can get pretty intense pretty quickly but overall, you can learn most of the C language in like a day.

**laserlight** · 12-27-2016

Originally Posted by MutantJohn

C is easy and awesome because the language is like 8 keywords.

*starts counting*

Nah, it's more like 44 in C11

**MutantJohn** · 12-27-2016

Originally Posted by laserlight

*starts counting*

Nah, it's more like 44 in C11

Ha! Thank you for actually getting the official count!

Okay, so 8 is too simplistic. But overall, C is much easier to digest in its entirety than other languages. When I first started getting into other languages, I really began to miss C's simplicity even though the other languages did allow me to do things.

**swgh** · 12-28-2016

Hmmm... if we could dissect the language into just eight keywords mine would be:

Code:

int double char struct sizeof void switch and for

**King Mir** · 12-28-2016

switch made it before if?

Thread: Why is C so awesome and easy to understand vs. other languages?

Thread Tools

Search Thread

Display

Why is C so awesome and easy to understand vs. other languages?

C Is Better?

Similar Threads

Deck of cards - Easy to understand program

Easy Languages to Learn While Getting Paid?

Easy but do not understand XD.

easy to understand tut

Looking for an easy to understand C/C++ Programming book.

Tags for this Thread