291–300 of 394 posts
Earlier quoted context omitted.
The C11 standard added concurrency primitives to the language.
Interesting. Do you know what the tool support is like? What compilers implement it, if debuggers support it, etc.
C is the language that doesn't force any preconceived notions about how the world should work onto you. Sure, C strings are NULL-terminated by convention, but even that is something you can almost completely ignore if you want to build up your own parallel stack of software that does it differently. It is for this reason that C (and sometimes C++) are what people use when they have a new idea about higher-level progr…
> C is the language that doesn't force any preconceived notions about how the world should work onto you Some preconceived notions forced upon you by C, off the top of my head: - problems should be solved by describing a linear sequence of steps (as opposed to logic/declarative programming) - a variable can have different values at different times in the execution of a program (in contrast to standard mathematical co…
Nope, not forced on you, because plenty of systems implemented in C define models in which none of what you mentioned is true. For example, the Haskell runtime is implemented in C. That's the whole point of what I'm saying. A stack with C at the bottom allows Haskell to exist with good performance even though the hardware/OS were not designed with Haskell in mind. The reverse is not true.
Why do you suppose that no serious VMs or language runtimes are written in Haskell (or other functional languages)?
C is a fantastic high level language. Nonsense. This sudden C fad is totally baffling to me. C is a great language for low-level work and it does have an attractive minimal elegance but is in absolutely no sense of the term a high level language . A language with next to no standard containers or algorithms, manual memory management, raw pointers, a barely functional string type and minimal standard library and concu…
> C... is in absolutely no sense of the term a high level language. Of course it is. You're not worrying about how many registers your CPU has, or when you swap a register out to memory. All that has been abstracted away for you. The fact that you can access memory locations directly gives you some low-level access, but in a very real sense C is a high-level language. There are higher-level languages with more abstra…
Here's a non-obvious example. With C, the programmer must always be aware of evaluation order. In fact, this must be specified even in cases where it is not important. For example:
x = a + b;
y = c + d;
With Haskell, when you are outside I/O Monads and such, you don't specify the order of calculations like the above. Those two calculations may appear in that order in the source code, but the Haskell programmer knows that doesn't mean anything. The system may calculate x first, y first, or perhaps neither if those values aren't actually used elsewhere. Temporal ordering is not necessary (or desirable) under most circumstances.
You can never forget about temporal order in C, but there are higher level languages that allow this.
C is the language that doesn't force any preconceived notions about how the world should work onto you. Sure, C strings are NULL-terminated by convention, but even that is something you can almost completely ignore if you want to build up your own parallel stack of software that does it differently. It is for this reason that C (and sometimes C++) are what people use when they have a new idea about higher-level progr…
C is the language that doesn't force any preconceived notions about how the world should work onto you. ... except for a type system based on the memory model of a machine which strongly resembles the PDP-11, a compilation strategy built for machines with less RAM than my car fob, and optimization possibilities limited by aliasing, plus everything kscaldef mentioned.
I'm interested in hearing about alternative memory models that are an improvement; every one I hear about is specific to some higher-level language or programming paradigm. Baking high-level language concepts into hardware is basically asking for stagnation.
> a compilation strategy built for machines with less RAM than my car fob
C is adapting (see: http://www.infoq.com/news/2012/11/llvm-modules)
> optimization possibilities limited by aliasing
"restrict" exists, and while it's not perfect, I have not seen anything that is a Pareto improvement over it. In other words, every alternative that avoids aliasing problems (that I have seen) makes other trade-offs that make it a worse choice overall (including FORTRAN, which I am sure you will mention).
Earlier quoted context omitted.
No, C does not define a single contiguous block of memory with consecutive addresses. It _does_ qualify that pointers are scalar types, but that does not imply contiguity or consecutive addresses (with the exception of arrays) There is no requirement in C that you be able to execute data. You certainly could have a C implementation that bounds-checks strings and arrays. (See e.g. http://www.doc.ic.ac.uk/~phjk/BoundsC…
I would argue that C's problem is not that it's too strictly defined, but that it's too poorly defined. An in-depth look into all the cases of undefined behavior in C will show what I mean. You want to really understand C? Read this[0]. John really understands C. [0] http://blog.regehr.org/
For example, take NULL. Even on a machine with no concept of NULL, you could easily emulate it by allocating a small block of memory and having the pointer to that block be designated as "NULL". This would be perfectly compliant with the standard, but it will break all of the code out there that assumes that NULL is all zero bits (e.g. that calloc or memset(0) produce pointers whose values contain NULL). Which is a lot of code. I'm sure that many other examples can be found.
Earlier quoted context omitted.
> C is the language that doesn't force any preconceived notions about how the world should work onto you Some preconceived notions forced upon you by C, off the top of my head: - problems should be solved by describing a linear sequence of steps (as opposed to logic/declarative programming) - a variable can have different values at different times in the execution of a program (in contrast to standard mathematical co…
> Some preconceived notions forced upon you by C Nope, not forced on you, because plenty of systems implemented in C define models in which none of what you mentioned is true. For example, the Haskell runtime is implemented in C. That's the whole point of what I'm saying. A stack with C at the bottom allows Haskell to exist with good performance even though the hardware/OS were not designed with Haskell in mind. The…
You realize C is not at the bottom of the stack, right?
> Why do you suppose that no serious VMs or language runtimes are written in Haskell (or other functional languages)?
Because Lisp Machines didn't win.
> plenty of systems implemented in C define models in which none of what you mentioned is true
True, but that's the whole point of abstraction. C, in turn, gets rid of some of the "preconceived notions" of the layers under it.
Earlier quoted context omitted.
> Some preconceived notions forced upon you by C Nope, not forced on you, because plenty of systems implemented in C define models in which none of what you mentioned is true. For example, the Haskell runtime is implemented in C. That's the whole point of what I'm saying. A stack with C at the bottom allows Haskell to exist with good performance even though the hardware/OS were not designed with Haskell in mind. The…
> A stack with C at the bottom You realize C is not at the bottom of the stack, right? > Why do you suppose that no serious VMs or language runtimes are written in Haskell (or other functional languages)? Because Lisp Machines didn't win. > plenty of systems implemented in C define models in which none of what you mentioned is true True, but that's the whole point of abstraction. C, in turn, gets rid of some of the "…
And if Lisp Machines had won, do you really think they'd run JavaScript, Erlang, C, and Haskell (as a rough sample) as fast as our Von Neumann machines do today?
Earlier quoted context omitted.
And can't be _implemented_ in any language. C gives you at least the charming fact that you can implement one without any overhead of objects, classes, implicit memory management or some other concept, just having a lightweight implementation that you may use in an environment without any libraries, like std or else..
So what you're saying is that C lets you write it on your own. In fact, and this might sound crazy, but you can do that exact same thing in C++, it's just that people don't because the C++ standard library provides plenty of performant and featureful data structures for you. Besides, anything the C++ standard template library map does when implementing a red-black tree is exactly what you would need to do if you wrot…
Earlier quoted context omitted.
So what you're saying is that C lets you write it on your own. In fact, and this might sound crazy, but you can do that exact same thing in C++, it's just that people don't because the C++ standard library provides plenty of performant and featureful data structures for you. Besides, anything the C++ standard template library map does when implementing a red-black tree is exactly what you would need to do if you wrot…
I'm confused. C has libraries too. I personally like the headers used by openbsd: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/tree.h?rev...
and third party libs are also possible, yes.