> 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 conventions)
- a function can return different results when called multiple times with the same arguments (again, in contrast to the standard mathematical meaning of the term)
- there is random access storage of information (with constant time access and update)
problems should be solved by describing a linear sequence of steps (as opposed to logic/declarative programming)
Linear sequences of steps processing data arrayed in some linear fashion or others is what computers do. It is certainly what a single core does.
So you would rather have someone else write a C program for you that abstracts it away and calls it a new way to program? That's k, just know that you'll still have those pesky linear steps under the hood. You know, at some point the neat source you write actually has to get converted into stuff CPU can make the slightest bit of sense out of.
Of course it's nice to try to "get the computer think like the programmer instead of the other way around" (kind of the motivation for the inventor of the compiler IIRC, in times when people really had to "speak binary" to the computer), but it also kinda sucks when people completely loose track of the machine they're programming, and think their abstraction layers du jour grow on trees or something.
a variable can have different values at different times in the execution of a program (in contrast to standard mathematical conventions)
Your problem is nomenclature? Why not simply declare constant variables where you need them and move on? And are you really trying to twist C giving you the choice into "forcing preconceived notions" on programmers? That is hilarious, I will give you that much.
a function can return different results when called multiple times with the same arguments (again, in contrast to the standard mathematical meaning of the term)
"Function" can also mean a lot of people coming together for a wedding or something. I think that's why you would call them "C function" if you wanted to be precise.
there is random access storage of information (with constant time access and update)
Again, that's just how "the world" works. But C hardly came up with that, which is why all languages have it.. yes, all of them. Some abstract it away from you, sure, but they still have it. So you pay overhead and control "tax" in return for convenience and and expressiveness; that's not a bad thing per se, often it's the sane and productive choice, but to me dissing C is just shitting where you eat. The only reasons I can imagine for it are jealousy or ignorance.
> Linear sequences of steps processing data arrayed in some linear fashion or others is what computers do
No, it's what some computers do. It's almost certainly not what the computer you are using currently does. It's quite possible it's not what any computer you've ever used does.
> So you would rather ...
I'm not expressing a preference. If you think I was, you've misunderstood my comment. I'm making observations, not judgements. I'm not anti-C, it's a fine language for many things; however I do think that the articles author is not being as even-handed as he claims when it comes to some of the short-comings of C.
> Your problem is nomenclature?
Again, I'm not making a judgement. C exists in a paradigm where writing
x = 3
x = 4
makes sense. In other paradigms it would be logically inconsistent.
>>there is random access storage of information (with constant time access and update)
>Again, that's just how "the world" works.
That's absolutely not how "the world" works. Again, you've probably never even used a computer where it was true.
> dissing C is just shitting where you eat. The only reasons I can imagine for it are jealousy or ignorance.
I don't think I've made any statement anywhere in this discussion that's "dissing C".
How does this computer right here not consist of a whole lof of linear sequenceS?(notice the plural btw? and the fact that "linear" does say nothing about "serial" vs "parallel", either?) How is data not arrayed linearly? Please elaborate, "because I said so" is not enough.
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)?
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?
C is built to run on a MASOS (multiple address space operating system) like UNIX so it wouldn't run as fast on a system like the Lisp machines that uses a single address space. Many of the things C deals with like the file system and interprocess communication would be obsolete in a system with single address space orthogonal persistence. Running C on a Lisp machine will be possible but at a performance cost.
JavaScript would run faster then it does on Von Nuemman machines because it would use the hardware support for dynamic languages and since JavaScript runs in a browser independently of the OS, the new machine architecture and OS wouldn't be a problem. Haskell, in so far as its purely functional, would probably run the same as it does now.
> C is built to run on a MASOS (multiple address space operating system)
What? You can run C on machines without a MMU, without an OS, or even to implement an OS.
> Many of the things C deals with like the file system and interprocess communication would be obsolete in a system with single address space orthogonal persistence.
What if people want a filesystem? They can't have one because the machine designer liked "single address space orthogonal persistence" better?
> JavaScript would run faster then it does on Von Nuemman machines because it would use the hardware support for dynamic languages
> Haskell, in so far as its purely functional, would probably run the same as it does now.
I highly doubt these claims. Just because a language is "dynamic" doesn't mean it can take advantage of generic "hardware support for dynamic languages" to be as fast as highly sophisticated and language-specific VMs like V8 or IonMonkey. Just because a language is "functional" doesn't mean you can implement a thin translation layer that maps one onto the other with minimal overhead. This is fuzzy thinking that ignores the true complexities of high-performance language implementations.
The principal application of C was to build the UNIX MASOS. C gained popularity on UNIX systems because they already had support for the language. The vast majority of C programs use UNIX features that will be obsolete on a SASOS, so running these C programs will come at a performance cost.
> You can run C on machines without a MMU, without an OS, or even to implement an OS.
In my previous post I was referring to C programs which include C standard library files such as stdio.h which will be obsolete because it uses the file system and signal.h which is used for IPC. If a C program uses any header files at all it is obsolete because it should be using functions rather then files as its unit of composition.
> What if people want a filesystem?
As persistent data (data that is independent of the lifetime of the program) is always mapped to a single global virtual address space in SASOS, there will be no need to have a file system. A file system interface can be provided, but it will be just another way of accessing virtual memory.
> They can't have one because the machine designer liked "single address space orthogonal persistence" better?
Although eliminating file systems will be enormously advantageous to developers, it will also be equally advantageous to users. Whenever a user of a UNIX system changes an object that user has to save those changes, usually by clicking File/Save in a drop down menubar. An orthogonally persistent system will be more accessible to ordinary users because they won't have to handle the details of saving data to the file system.
The user interface expert, Jef Raskins, set out to design a user interface based upon the needs of the user rather then from the needs of software, hardware, or marketing. The product of this search was Archy which is an orthogonally persistent system.
The hierarchical nature of modern file systems also isn't ideal from a user interface design perspective. Forcing users to fit their data into a hierarchy is problematic. Using tagging and search will arguably make for an easier to use interface then a file system.
> Just because a language is "dynamic" doesn't mean it can take advantage of generic "hardware support for dynamic languages" to be as fast as highly sophisticated and language-specific VMs like V8 or IonMonkey.
The V8 virtual machine is implemented with a high degree of sophistication so that it can run large JavaScript programs. There will be no need to waste memory storing such a sophisticated VM in a Lisp machine because all large programs will be written in Lisp instead. JavaScript will only be used for small scripts in web pages, ensuring that users won't fall into the JavaScript trap. In this sense, JavaScript may run somewhat slower without a sophisticated VM, but that performance difference will be irrelevant because the language will only be used for small scripts.
They would because Lisp Machines were not some magical functional machines but pretty much standard CPU designs of their era with additional hardware support for object memory (tagged pointers, GC...) and relatively large word size.
Modern computer operating systems are systems of bloat. The amount of duplication between programming languages like C, C++, Objective C, C#, Java, JavaScript, Perl, Python, and Ruby, user programs, and applications is immense. To have a streamlined system that uses a single language all the way down to the machine itself, and that makes full use of the sharing capabilities of a single address space, would be truly magical!
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 conventions)
- a function can return different results when called multiple times with the same arguments (again, in contrast to the standard mathematical meaning of the term)
- there is random access storage of information (with constant time access and update)