We live in a world where C and C++ are the only game in town as far as compile to platform languages. Java, C# and even scripting languages like Python and Ruby are all garbage collected VM languages that only provide a bandaid to all of C and C++'s problems. There is a solution, PL/I, a very full featured systems, scientific and enterprise language that handles all the issues that C and C++ leave the programmer to work out on his own. Read this comparison between C and PL/I and you'll see its a very serious systems programming language what was and still is ahead of its time: http://www.uni-muenster.de/ZIV.EberhardSturm/PL1andC.html
(PL/I is pronounced pee-el-one, not pee-el-eye, it stands for "Programming Language One")
We actually use PL/I where I work on our dinosaur IBM mainframe. I was offered the chance to learn it, but I figured I'd better stick to Java if I want to have a chance in the job market.
Name:
Anonymous2010-07-24 12:46
>>2
OP here
The only commercial compilers available for PL/I are for IBM mainframes, so in a sense it is a dead legacy language. You have to know Java nowadays for enterprise computing as it is the lingua franca of business infrastructure. But for anyone who is doing compile to .exe programming, I think that PL/I is a must see.
This article really sucks. If I knew nothing about PL/I my impression of it would be pretty horrible. This guy is not talking up PL/I, he's shitting on C (and doing a terrible job of it!)
I've gotten as far as some allusions about something or other being checked by the compiler (but no details of course), the rest is just complaints about cosmetics. And the next section is... more complaints about cosmetics. Does he ever get into anything meaningful?
But here is the absolute implementation overkill. [some bullshit about realloc] In PL/I every error has a number, and errors are divided into groups: anycondition, area, attention, condition, conversion, endfile, endpage, error, finish, fixedoverflow, invalidop, key, name, overflow, record, size, storage, stringrange, subscriptrange, transmit, undefinedfile, underflow, and zerodivide.
I made it to the part where typed pointers is supposed to be a bad thing. ICTBT.
Name:
Anonymous2010-07-24 13:41
>allows you to say what you intend (and let the compiler care for efficiency)!
Obviously this ancient langauge is the pinnacle of efficiency
Name:
Anonymous2010-07-24 14:13
>>Obviously this ancient langauge is the pinnacle of efficiency
pretty much all the first generation of personal computers ran a version of the CP/M operating system which was written by Gary Kildall in the PL/I language
>>8
Agreed. WHBT. I also think it's hilarious that in order to peddle alternatives to C/C++, the creators complain about the problems of C/C++ while apparently not recognizing what audiences they serve and what they're reasonably good at. "Here, my nail hammer can serve your sledgehammer needs, your wrench needs, and your jackhammer needs!" Brilliant deduction, assface. Brilliant.
>>14
It's too bad. C is showing its age, just a tad. It's held up remarkably well and the only reason I think it could use replacing owes to the technology we've developed in the mean time... things that can't be grafted on, such as verification.
I also think lightweight- and host-thread concurrency need to be bridged somehow. In C you've got library threads and time slicers. Not pretty, though surprisingly usable. Go at least does the remarkable job of muxing threads onto CPUs for you (which you can't really do at all in C), but you're left with no control over it.
>>17 C is showing its age
Like hell it is. C is excellent for some domains. What's showing age is the mental model programmers have which think that domain is vastly larger than it is.
>>18
The domain is growing, or would like to. It can, but not with C. I really think it needs to grow. Not only has our hardware changed somewhat, but what we're able to do in software has also changed--in ways C simply cannot accommodate. I'm already repeating myself so I'm going to stop here.
Name:
Anonymous2010-07-24 17:36
The idea is: OSes run on C code and use C conventions for data/functions. Until OS developers switch from C, it would the lowest level common denominator language.
>>20
Have you looked at a recent C1x draft? C is going to be able to accommodate a lot more soon.
Name:
Anonymous2010-07-24 18:12
I don't see anything useful or significant.
The November 2009 draft includes several changes to the C99 language and library specifications, such as:
* Alignment specification (_Align specifier, alignof operator, aligned_alloc function)
* Multithreading support (_Thread_local storage-class specifier, <threads.h> header including thread creation/management functions, mutex, condition variable and thread-specific storage functionality)
* Improved Unicode support (char16_t and char32_t types for storing UTF-16/UTF-32 encoded data, including the corresponding u and U string literal prefixes and conversion functions in <uchar.h>)
* Removal of the gets function
* Bounds-checking interfaces (Annex K)
* Analyzability features (Annex L)
>>22
Yes, C1x certainly helps. It's a revision (i.e. replacement) and not a departure though, so I don't see it rounding things out as well as it I'd like. Concurrency could be addressed in C to my satisfaction, and C1x is making a start. Verification could not.
This bit about concurrency and safety and so on: these are signs of C's age. People around here still like to poke at C99, and god help us when someone uses a non-ISO extension; or worse: C get's an 'x' in the name. Of course most of it is either old habits (I still have habits from ANSI C, and sometimes I still forget which habits are obsoleted by the current standard) or pure ignorance. The sign of age is that C is changing--standard library and all--out of (correctly) perceived necessity.
Name:
Anonymous2010-07-24 18:31
>>23 * Removal of the gets function
Fucking bullshit, this breaks all my code.
>>25 It's almost like you didn't even read my response.
I did read it. Did you read any of mine?
I just don't agree with your assertions, or maybe your perception just falls woefully short. You haven't given so much as an example so the argument is vacuous. Take it up with the standards committee if you think C is adequate for its domain. You could save them the trouble of future revisions.
No, C will be around in 20 years' time, like you say, but C99 will not get it there.
In terms of revision and extension C1x doesn't add much breadth, it merely facilitates existing applications. Let me rephrase that with some meat: the systems domain alone has broadened, and relevant techniques which have not been addressed in standard C (including C1x) have proven their worth, some recently, some decades ago. This won't kill C, but one hopes it will nurture something more suitable.
>>29 Take it up with the standards committee if you think C is adequate for its domain.
The point, dear fellow, is that people just like the people in the standards committee are attempting to drag C, kicking and screaming through sepples if need be, far outside its original domain, which was the fucking 70s. To the extent we still face the same problems they faced in the 70s--which we do--C is as useful as ever. We will continue to face those kinds of problems in the future for a long time to come, until every device around has a 64-bit processor with 2 gigs of RAM in it. (Which, of course, is not going to happen in the foreseeable future.)
Meanwhile, it is time to fucking move on. If that means going Google and inventing a better C (Go), or if that means going Sun and inventing a better C++ (Java), or if that means something new entirely like bitC or Haskell or god knows what, so be it.
But, you say, I should talk to the standards committee about it. Why? I don't actually care. People that realize flexibility comes not from endless language revisions but the plethora of languages available have already moved on. If the rest of you want to stay behind, lugging a 50 pound weight around your neck, feel free. I just think it's dumb. We could use you doing more productive things.
Name:
Anonymous2010-07-24 21:29
All the compiler vendors ignored C99 because all that was just C++ features thrown into C. And now you idiots think that C1x is going to save the day with platform independent concurrency and a bunch of other features that try and cover the mess that is C? That flash-in-the-pan was already tried with Go.
>>32
Did you even glance at the draft? It contradicts everything you say about the new standard.
I don't care if you think the systems domain is still what it was in the '70s. Anyone can see that it isn't. We've stopped ratcheting up clock speeds with Moore's Law and instead are making different kinds of chips--some of them highly heterogeneous. Even embedded systems are different, most of which are more robust and more powerful than the big systems of the day. Even Zilog has practically dropped off the face of the planet.
But it's bizarre that you bring up BitC, Go and friends. Back in >>18 I was getting shit on for suggesting that modern alternatives are required because revising and extending C is inappropriate to the modern domain.
>>35 I don't care if you think the systems domain is still what it was in the '70s.
I don't think that. This, essentially, is your entire problem: that you think I think that.
I don't.
Back in >>18 I was getting shit on for suggesting that modern alternatives are required because revising and extending C is inappropriate to the modern domain.
That was me doing the shitting. And my comment was that C is not showing its age. I stand by that comment. I use C all the time. It's still very, very useful for embedded systems---roughly the kind of systems they were dealing with in the 70s.
Systems programming is within C's intended domain.
C's domain has not changed.
The systems domain has changed significantly.
Which one of these do you want to eliminate?
roughly the kind of systems they were dealing with in the 70s.
Unless you're limiting yourself to working on ~30 year old hardware (in which case you don't count), that's utter nonsense. You know they run Java and all kinds of things on embedded systems these days.
Name:
Anonymous2010-07-24 22:57
OP here
decent PL/I resources are really hard to come by, but I did find these two out of print PL/I books that are available as a free download:
>>38 Systems programming is within C's intended domain.
This was true. It's still true now for the systems--and their modern equivalents--that it was true for then. Everyone knows "the systems domain has changed significantly." Yet they're still dragging C and C++ around their necks like a 50 pound weight.
You know they run Java and all kinds of things on embedded systems these days.
This discussion is over. You never understood what I was saying in the first place, and now you're being contrary for its own sake.
>>40 This was true.
Exactly. C's application has moved on. That's a sign of age. You refuse to see it. I don't care: another one to take up with the committee. Not me. It seems like you just don't like the sound of it, and frankly I don't give a shit.
This discussion is over. Did you mean:lalalalala I can't hear you?
For the record this discussion never started. You've been vague the whole time and you're still being vague. You've never once explained yourself even a little without being prompted at least twice. Hell, you can't even answer a question. If I've failed to understand what you've said it's because you never actually said anything of substance--you've just contradicted things I have said without giving any but vacuous reasons or even attempting to understand what I said (let alone what WG14 has published.)
>>44
There are Lisp OSes (see Genera as one example).
While C is never really needed, you do need assembly. The best way you can get rid of assembly is to stuff all arch-specific assembly in the compiler, but what's so scary about writting a little assembly? It's what the platform runs on, so it only makes sense that you'll need to use it when certain special, architecture-specific things are not directly supported in the compiler (it might not make much sense to add support for some types of features in the compiler, especially if they're only used a few times in the entire OS).
Name:
Anonymous2010-07-25 4:25
>but what's so scary about writting a little assembly
C compilers replace 99% of the need for asm
If your language does not do this its not meant for OS development.
>>46
No they don't. I've written a lot of inline asm in my days. It's just needed for platform dependent tasks. I could give you hundreds of examples, but let's try a few simple ones:
1) Do input/output to some port or interface with some hardware.
2) Perform some complex SIMD arith (see: MMX, SSE on x86), and have your compiler generate code which means exactly what you intended the code to do.
3) Write some exception handler setup code (you can't use non-ANSI C extensions here) or write the OS'es exception handling system.
4) Write a task or thread switcher. Alternatively, write a usermode-only fiber(similar to green threads) system.(you have to save all the registers and state and be able to restore them).
(You're not allowed to use someone else's library, or if you really want to use it, you have to prove it didn't use any form of assembly and was written in pure C. Using system calls is also not permitted, unless you can prove they were written in pure C as well.)
I could go on, but I'll leave it at that for now. You can do either of this in C or even Lisp or other languages, but you will need to have something generate the assembly for you, usually you'll have the compiler do it, but sometimes you'll need more precision or the compiler can't generate the exact code you want, so you'll want to write it directly in assembly.
>>48 1) Do input/output to some port or interface with some hardware.
Your OS should offer APIs for this. (Linux) 2) Perform some complex SIMD arith (see: MMX, SSE on x86), and have your compiler generate code which means exactly what you intended the code to do.
Your compiler should offer APIs for this. (GCC)
>>49
Oh hello there, Your OS should offer APIs for this. (Linux)
YOU ARE WRITING THE OS, DID YOU FORGET ABOUT IT? Your compiler should offer APIs for this. (GCC)
YOU'RE WRITING THAT TOO.
You can't do anything without using some assembly in one form of the other. At best you can attempt to move everything into the compiler and bloat it up.
>>38 You know they run Java and all kinds of things on embedded systems these days.
That is correct, but do all embedded systems run Java? No.
Most of them -- handheld consoles, ICs and pretty much everything else that isn't a mobile phone -- don't because it's the worst thing to possibly use on such a system.
They run code compiled by a C compiler, or at least a compiler for a language invented by the vendor that is so similar to C that there may as well be no difference.