9 ms·

Simple Language != Simple to use. C is a small language. C is gussied-up assembly. It is the ballet of programming language. People who say C is simple real

Simple Language != Simple to use. C is a small language. C is gussied-up assembly. It is the ballet of programming language. People who say C is simple really mean that it doesn't do anything behind my back.

astine 13y ago
C is like the marketing slogan to Othello (reversi): A minute to learn, a lifetime to master. The language is fairly simple in terms of features and aspects you have to learn to use it, but concepts like pointers and direct memory management are difficult to master. Programming in C is like building a building out of bricks; bricks are relatively simple objects, building a building out of them is not a simple task.
- JonFish85 13y ago
  Agree with both parents. "Simple" to me means that the code does exactly what I ask: no more, no less. For better or for worse. No behind-the-scenes magic (garbage collection, etc). I know exactly how much memory I am using, where it's allocated, and how it's passed around. Again, for better or for worse. With great power comes great responsibility!
  - pjmlp 13y ago
    Do you also know all the undefined and unspecified use cases of the standard? http://de.slideshare.net/olvemaudal/deep-c http://de.slideshare.net/olvemaudal/deep-c
  - anon1385 13y ago
    >No behind-the-scenes magic I assume you never compile with optimisations turned on then?
    - zxcdw 13y ago
      Has very little to do with the language, apart from what undefined and platform dependent behavior allow the compiler to trick around. Of course, if the compiler goes nuts or is buggy, anything can happen "behind the scenes", but as far as I'm aware, this has nothing to do with the language as specified in the standard.
  - ctdonath 13y ago
    The problem is when what you ask for is incompatible with how it's done. Hence me today observing a price field in a record containing $9.500000000000000000002, knowing that making the obvious problem there "easy" will result in painful data manipulations elsewhere, and remembering that under certain conditions a Boolean can be neither true nor false. Asking a binary computer to handle non binary data just plain gets weird sometimes.
- deleted 13y ago
  [deleted]
- venomsnake 13y ago
  I think that pointers are hard is self fulfilling prophecy. We studied them in the 9th grade. Because nobody bothered to tell us they were hard almost my whole class - around 80% after the first two lessons groked pointers and linked lists. Same was with pointer arithmetic and function pointers. Right now I am struggling mightily with monads mostly because the voice in my head tells me the thing all of the internet is singing - they are hard don't bother.
  - Amadou 13y ago
    Pointers are easy when everything is working right. It's when there are bugs in code which uses pointers that the weird can kick in and really give you a headache.
  - chebert 13y ago
    Monads are easy. Do bother. =D. Just need to be the discord to the Internet's harmony.
Genmutant 13y ago
Also the standard library is really small. So after a short amount of time you have used almost all of it a few times.
- PySlice 13y ago
  However it's going to take some time to learn all the gotchas in string functions... Failing to zero-terminate strings (strncpy), potential buffer overflows (many), global internal buffer and overwriting an argument (strtok), etc etc etc etc
tel 13y ago
It "doesn't do anything behind my back" is exactly the phrase I've been searching for.
pcwalton 13y ago
But the article contains many examples of the compiler doing things behind your back. For example: > The answer depends on whether the optimizations are turned on. If they are then the answer is 3 (the first definition is inlined at all occurrences until the second definition). If the optimizations are off, then the first definition is ignore (treated like a prototype) and the answer is 4.
- dietrichepp 13y ago
  In that case, it's your fault for defining two versions of a function (inline and non-inline) that do different things.
  - anon1385 13y ago
    Even if you don't do something like that a modern C compiler will do all sorts of things behind your back. Like removing null checks[1] or pointer overflow checks[2] [1] http://www.cvedetails.com/cve/CVE-2009-1897 http://www.cvedetails.com/cve/CVE-2009-1897 [2] http://www.cvedetails.com/cve/CVE-2008-1685 http://www.cvedetails.com/cve/CVE-2008-1685
    - rapala 13y ago
      Well, to be fair, the NULL check was in a wrong place. The pointer was already dereferenced before the check. struct tun_struct *tun = __tun_get(tfile); struct sock *sk = tun->sk; unsigned int mask = 0; if (!tun) return POLLERR;
anon1385 13y ago
Is it a small language? The standard takes a dense 179 pages to describe the language. I guess it's debatable if that is small or not. I certainly don't agree that it's a simple language though. There are myriad rules and exceptions to rules to remember. When and where one integer type will be converted to another. When overflow is defined and when it's undefined. Just those things alone mean that much real world C code is full of undefined behaviour[1] just related to arithmetic on numeric types, because the rules are hard to remember and reason about. John Regehr asked people to submit str2long() implementations that didn't execute undefined behaviour. Despite being well warned about avoiding overflows and other undefined behaviour only 35 of the 78 submissions passed the test suite[2]. Even a trivially small 2 line C function can result in different results on the common compilers depending on which compiler and which optimisation level you use[3]. Compiler engineers struggle to agree on and correctly implement the "simple" rules of C. To me that's an indication that they aren't so simple. I would say that C doesn't do anything behind your back as long as you don't ever use an optimising compiler or you pay very very close attention to the standard. If you forget then suddenly your check for pointer arithmetic overflow has been "helpfully optimised away" behind your back for reasons that are not immediately apparent at all[4]. I do agree that apparently simple rules can lead to complexity in use, and C is full of this too. For example you would think in a lower level language like C viewing a chunk of memory as a different type would be trivial, but the strict aliasing rule means you have to be a language lawyer to understand what is allowed and what isn't[5] as it makes the intuitive solution into undefined behaviour (which is extra pernicious since most of the time it will work as intended, until somebody compiles the code with a smarter compiler at a high optimisation setting). [1] http://blog.regehr.org/archives/963 http://blog.regehr.org/archives/963 [2] http://blog.regehr.org/archives/914 http://blog.regehr.org/archives/914 [3] http://blog.regehr.org/archives/482 http://blog.regehr.org/archives/482 [4] http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf example 1 [5] http://blog.regehr.org/archives/959 http://blog.regehr.org/archives/959
- TheCoelacanth 13y ago
  Compared to other languages, 179 pages for the full specification is pretty small. Java and C sharp have that more than three that size. C++ is roughly five times as large. If you're a fan of functional languages, Haskell is almost twice as large. Even Scheme, an extremely simple language, is only about 30 pages shorter.
Kurtz79 13y ago
"Terse" is the best adjective I can think of for C. Merriam-Webster definition of "Terse" : 1: smoothly elegant : polished 2: using few words : devoid of superfluity

astine 13y ago

C is like the marketing slogan to Othello (reversi): A minute to learn, a lifetime to master. The language is fairly simple in terms of features and aspects you have to learn to use it, but concepts like pointers and direct memory management are difficult to master. Programming in C is like building a building out of bricks; bricks are relatively simple objects, building a building out of them is not a simple task.

JonFish85 13y ago
Agree with both parents. "Simple" to me means that the code does exactly what I ask: no more, no less. For better or for worse. No behind-the-scenes magic (garbage collection, etc). I know exactly how much memory I am using, where it's allocated, and how it's passed around. Again, for better or for worse. With great power comes great responsibility!
- pjmlp 13y ago
  Do you also know all the undefined and unspecified use cases of the standard? http://de.slideshare.net/olvemaudal/deep-c http://de.slideshare.net/olvemaudal/deep-c
- anon1385 13y ago
  >No behind-the-scenes magic I assume you never compile with optimisations turned on then?
  - zxcdw 13y ago
    Has very little to do with the language, apart from what undefined and platform dependent behavior allow the compiler to trick around. Of course, if the compiler goes nuts or is buggy, anything can happen "behind the scenes", but as far as I'm aware, this has nothing to do with the language as specified in the standard.
- ctdonath 13y ago
  The problem is when what you ask for is incompatible with how it's done. Hence me today observing a price field in a record containing $9.500000000000000000002, knowing that making the obvious problem there "easy" will result in painful data manipulations elsewhere, and remembering that under certain conditions a Boolean can be neither true nor false. Asking a binary computer to handle non binary data just plain gets weird sometimes.
deleted 13y ago
[deleted]
venomsnake 13y ago
I think that pointers are hard is self fulfilling prophecy. We studied them in the 9th grade. Because nobody bothered to tell us they were hard almost my whole class - around 80% after the first two lessons groked pointers and linked lists. Same was with pointer arithmetic and function pointers. Right now I am struggling mightily with monads mostly because the voice in my head tells me the thing all of the internet is singing - they are hard don't bother.
- Amadou 13y ago
  Pointers are easy when everything is working right. It's when there are bugs in code which uses pointers that the weird can kick in and really give you a headache.
- chebert 13y ago
  Monads are easy. Do bother. =D. Just need to be the discord to the Internet's harmony.

Genmutant 13y ago

Also the standard library is really small. So after a short amount of time you have used almost all of it a few times.

PySlice 13y ago
However it's going to take some time to learn all the gotchas in string functions... Failing to zero-terminate strings (strncpy), potential buffer overflows (many), global internal buffer and overwriting an argument (strtok), etc etc etc etc

tel 13y ago

It "doesn't do anything behind my back" is exactly the phrase I've been searching for.

pcwalton 13y ago

But the article contains many examples of the compiler doing things behind your back. For example: > The answer depends on whether the optimizations are turned on. If they are then the answer is 3 (the first definition is inlined at all occurrences until the second definition). If the optimizations are off, then the first definition is ignore (treated like a prototype) and the answer is 4.

dietrichepp 13y ago
In that case, it's your fault for defining two versions of a function (inline and non-inline) that do different things.
- anon1385 13y ago
  Even if you don't do something like that a modern C compiler will do all sorts of things behind your back. Like removing null checks[1] or pointer overflow checks[2] [1] http://www.cvedetails.com/cve/CVE-2009-1897 http://www.cvedetails.com/cve/CVE-2009-1897 [2] http://www.cvedetails.com/cve/CVE-2008-1685 http://www.cvedetails.com/cve/CVE-2008-1685
  - rapala 13y ago
    Well, to be fair, the NULL check was in a wrong place. The pointer was already dereferenced before the check. struct tun_struct *tun = __tun_get(tfile); struct sock *sk = tun->sk; unsigned int mask = 0; if (!tun) return POLLERR;

anon1385 13y ago

Is it a small language? The standard takes a dense 179 pages to describe the language. I guess it's debatable if that is small or not. I certainly don't agree that it's a simple language though. There are myriad rules and exceptions to rules to remember. When and where one integer type will be converted to another. When overflow is defined and when it's undefined. Just those things alone mean that much real world C code is full of undefined behaviour[1] just related to arithmetic on numeric types, because the rules are hard to remember and reason about. John Regehr asked people to submit str2long() implementations that didn't execute undefined behaviour. Despite being well warned about avoiding overflows and other undefined behaviour only 35 of the 78 submissions passed the test suite[2]. Even a trivially small 2 line C function can result in different results on the common compilers depending on which compiler and which optimisation level you use[3]. Compiler engineers struggle to agree on and correctly implement the "simple" rules of C. To me that's an indication that they aren't so simple. I would say that C doesn't do anything behind your back as long as you don't ever use an optimising compiler or you pay very very close attention to the standard. If you forget then suddenly your check for pointer arithmetic overflow has been "helpfully optimised away" behind your back for reasons that are not immediately apparent at all[4]. I do agree that apparently simple rules can lead to complexity in use, and C is full of this too. For example you would think in a lower level language like C viewing a chunk of memory as a different type would be trivial, but the strict aliasing rule means you have to be a language lawyer to understand what is allowed and what isn't[5] as it makes the intuitive solution into undefined behaviour (which is extra pernicious since most of the time it will work as intended, until somebody compiles the code with a smarter compiler at a high optimisation setting). [1] http://blog.regehr.org/archives/963 http://blog.regehr.org/archives/963 [2] http://blog.regehr.org/archives/914 http://blog.regehr.org/archives/914 [3] http://blog.regehr.org/archives/482 http://blog.regehr.org/archives/482 [4] http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf example 1 [5] http://blog.regehr.org/archives/959 http://blog.regehr.org/archives/959

TheCoelacanth 13y ago
Compared to other languages, 179 pages for the full specification is pretty small. Java and C sharp have that more than three that size. C++ is roughly five times as large. If you're a fan of functional languages, Haskell is almost twice as large. Even Scheme, an extremely simple language, is only about 30 pages shorter.

Kurtz79 13y ago

"Terse" is the best adjective I can think of for C. Merriam-Webster definition of "Terse" : 1: smoothly elegant : polished 2: using few words : devoid of superfluity