Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Low level alternative to C?

By hardburn in Op-Ed
Sun May 12, 2002 at 06:52:42 PM EST
Tags: Software (all tags)
Software

"I hate C. I use Python for everything."
"What about low-level programming?"
"Oh, I use C then."

. . .

"I hate C. I use O'Cmal for everything."
"What about systems programming?"
"Oh, I use C then."

How many times have you seen this conversation repeated? And why do we keep having it?


Over the years, a multitude of higher-level programming languages have developed. Most of them have in some way been based on C, and with good reason: nearly every programmer knows C, and can pick up a syntactically similar language more quickly then one that is unique. Such languages take away some of C's complexity while adding new things into the mix.

As the conversations in the intro illustrate, some people swear by their favorite high-level language. However, whenever you do something that is low level, or needs to be as speedy as possible, C is often the first choice. The only real alternative is assembly, but this has problems of its own. You are generally stuck with whatever assembly your platform uses. Theoretically, you can always stick another language in place of C, but you don't have much choice with assembly.

Right now, there is massive development of high level languages. Sun just standardized Java 2 version 1.4. Perl is nearing version 6. Languages based on old-but-trustworthy ideas of computer science (like O'Cmal) are starting to reemerge.

Yet in 30 years, no language has been created that has usurped C's position of the best "cross-platform assembly language". C++ and Objective C are merely extensions of C and not really replacements. In any case, the overhead that is always involved in object-oriented languages means that such languages are often rejected for low level use. Additionally, the inadequacies of C++ have been a matter of much debate that I won't go into here.

(This is not to say that writing low-level C code should not be object-oriented. It is often be desirable to write C in an object-oriented way while maintaining low resource counts. However, it is often undesirable to use a fully OOP language due to the extra overhead involved in simply being a fully OOP language.)

What is it about C that makes it remain King of Systems Programming? I find it hard to believe that C is the end all, be all of low level programming. The apparent reason is that no good alternative has been made.

Even more annoying is that new languages often smell like C. They all use '()' to enclose statements, '{}' to enclose code blocks, and they all use '!' for "not". A book about language "foo" often has a section titled "moving from C to foo"; sometimes the book itself has that title. All these languages seem to say "yeah, we could make something better, but we already know this".

It's not that I think C is a horrible language. It may have its problems, but it's not horrible. I just wonder why nothing better has come along to replace it.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Why hasn't C disappeared?
o No good alternative 55%
o It's the best language there will ever be 30%
o C sux, I wr1t3 VB 14%

Votes: 155
Results | Other Polls

Related Links
o Also by hardburn


Display: Sort:
Low level alternative to C? | 261 comments (244 topical, 17 editorial, 0 hidden)
C++ (4.55 / 9) (#2)
by ucblockhead on Sat May 11, 2002 at 11:29:48 PM EST

One thing to keep in mind is that it is only a few OO features in C++ that have significant overhead. Probably 80% of C++ language features have no overhead at all.

Though you are right in that C++ still is not real replacements...I fear the language you want does not exist. At least, I've never seen it.
-----------------------
This is k5. We're all tools - duxup

Have you ever noticed (1.33 / 3) (#7)
by medham on Sat May 11, 2002 at 11:55:44 PM EST

How much better VS6 works when you give it source files with a *.c extension?

The real 'medham' has userid 6831.
[ Parent ]

It's not only overhead (4.75 / 4) (#36)
by JanneM on Sun May 12, 2002 at 05:08:55 AM EST

It's not only the overhead. Another aspect is the opacity of the language. If you are writing something like a driver, for example, you do not want anything to happen behind your back. You also do most definitely not want to have to link to a large standard library to do your work. And if you're working with embedded applications, you need a language that is easy to port to the architecture. C++ is just too big a language to be suiteable in many cases. Sure, you can define a subset of C++ that eliminates those problems, but that subset will pretty much be C with one-line comments...

---
Trust the Computer. The Computer is your friend.
[ Parent ]
standard libraries (5.00 / 2) (#47)
by ucblockhead on Sun May 12, 2002 at 10:04:55 AM EST

The bulk of the C++ standard library is the C standard library. The only thing that I can think of that C++ adds at link time is the iostream stuff and the stream stuff. Most compilers will let you keep that out of the exe if you don't use it.

The bulk of the C++ standard library is the STL, but that's all templates, all headers, so there's no link-time cost and no cost at all if you don't use it.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Yes, but (5.00 / 2) (#49)
by JanneM on Sun May 12, 2002 at 10:30:59 AM EST

In embedded apps you usually don't even use the C standard lib. You usually have a vastly pared down lib, or one written especially for the application you are to make.

Point is, since you don't want to use anything but the simplest of classes (to avoid anything happening behind your back), and you don't want any of the standard classes (including iostream), then what's the point of using C++? You're really just programming in C anyway.
---
Trust the Computer. The Computer is your friend.
[ Parent ]

umm... (none / 0) (#51)
by ucblockhead on Sun May 12, 2002 at 11:40:14 AM EST

But C++ doesn't make you use the standard libraries any more than C does.

C++ can give you features C lacks, like nonpolymorphic classes and exceptions, neither of which has overhead.

Templates also have no runtime speed cost (and, in fact, can produce faster code than C function calls) and can be used as typesafe macros.

There are also a bunch of other nifty features like function inlining, though I believe that C99 stole some of them.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

C99 (5.00 / 1) (#134)
by FredBloggs on Mon May 13, 2002 at 06:44:29 AM EST

"There are also a bunch of other nifty features like function inlining, though I believe that C99 stole some of them"

Shame there isnt a single C99 compliant compiler  though!

[ Parent ]

95% C99 conformance may be enough (4.00 / 2) (#149)
by pin0cchio on Mon May 13, 2002 at 10:35:04 AM EST

Shame there isnt a single C99 compliant compiler though!

There wasn't a single C++ compliant compiler until less than a month ago, but that hasn't stopped people from using the parts of C++ that their compilers support. (The primary omission in GCC's C++ support is the export keyword.)

Look at all the C99 featurs GCC does support, and if you really need one of the missing features, donate to FSF to get it added.


lj65
[ Parent ]
What about the extra compile time typechecks? (5.00 / 1) (#91)
by leviramsey on Sun May 12, 2002 at 06:34:09 PM EST

I know a few C programmers who do test compiles as C++, mainly because of the compile-time type checking.



[ Parent ]
gcc -Wall (3.00 / 1) (#112)
by pin0cchio on Sun May 12, 2002 at 08:26:10 PM EST

I know a few C programmers who do test compiles as C++, mainly because of the compile-time type checking.

gcc -Wall -W -pedantic does the same type checking as g++, if not more. In addition, some newer C language features don't exist in C++.


lj65
[ Parent ]
what id like to see 'fixed' in C... (4.25 / 8) (#5)
by rebelcool on Sat May 11, 2002 at 11:52:35 PM EST

is pointers. They're too damn easy to fuck up with. An improved syntax would go a long way to preventing pointer problems.

Const's can also be ambiguous at times. It'd be nice to have a clear, concise and immediately 'oh thats what that is' thing for both those without having to look too deep.

It could use an improved malloc too.

COG. Build your own community. Free, easy, powerful. Demo site

Well... (3.75 / 4) (#13)
by carbon on Sun May 12, 2002 at 12:46:13 AM EST

If you're willing to take a step up and use C++, you can still use it as though it were C without hardly any speed loss. However, now you have the additional benefit of using (auto/local/shared/smart)_ptr, which does automagical garbage collection.


Wasn't Dr. Claus the bad guy on Inspector Gadget? - dirvish
[ Parent ]
no! (4.25 / 4) (#14)
by ucblockhead on Sun May 12, 2002 at 12:57:31 AM EST

Smart pointers are not the same as garbage collection!

You can have memory leaks even with smart pointers.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Of course you can (4.00 / 3) (#31)
by carbon on Sun May 12, 2002 at 03:41:40 AM EST

You can have memory links with any types of reference, all you have to do is keep a reference around that you don't need. The nice thing about smart pointers is that they do reference counting, which takes care of the most difficult to design for kind of memory leak : when you delete all references to a given memory space.


Wasn't Dr. Claus the bad guy on Inspector Gadget? - dirvish
[ Parent ]
yes (4.66 / 3) (#44)
by ucblockhead on Sun May 12, 2002 at 09:53:15 AM EST

No I agree, smart pointers are very useful. It's just dangerous to consider them identical to garbage collection because there's leaks that they will allow that a good garbage collector won't.

In particular, circular references will screw you up. If object Foo has a smart pointer to object Bar, and object Bar has a smart pointer to object Foo, you've got a leak because neither reference count will go to zero. OTOH, a garbage collector will catch stuff like that.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Well, gc can also give memory leaks... (4.00 / 3) (#57)
by joto on Sun May 12, 2002 at 12:26:32 PM EST

In at least the following situations:
  1. Programmer error. A pointer is unnecessarily pointing to unneded data.
  2. GC error. A modern gc is hard to implement. Almost all of them has yet-to-be-discovered bugs.
  3. Reachability error. A gc will need to be conservative, it can only collect statically unreachable memory, not dynamically.
  4. External and internal fragmentation (as with all systems using heap-based allocation).
  5. Waste of memory due to copying or compaction of memory.

...and so on. If you want safety, don't use heap-allocation. In fact, better avoid stack-allocation as well, unless you can predict stack-depth with absolute certainty. Oh, you better avoid compilers as well, they are unthrustworthy beings, and so are libraries! Hey, I don't even know why we should trust computers!

Oops, I forgot the point of this post. I guess I really agree with you... A smart ptr is a bad excuse for real gc!

[ Parent ]

Modern GC (none / 0) (#228)
by codemonkey_uk on Tue May 14, 2002 at 05:56:07 AM EST

Garbage collection is a well understood area. While programs written in GC languages can still "leak" due to programmer error (ie adding items to a list and never removing them), but for the garbage collection itself to leak would be very unusual.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
too bad... (2.80 / 5) (#15)
by rebelcool on Sun May 12, 2002 at 12:59:09 AM EST

that c++ is a syntactical nightmare. Ugh.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

The C mindset (3.00 / 2) (#23)
by xriso on Sun May 12, 2002 at 01:50:45 AM EST

Once you think in a C way, pointers and the "backwards" declarations make perfect sense. As for the malloc, you could probably make a macro or wrapper function that does what you want. eg. #define allocate(x) (x=malloc(sizeof *x))

[One thing that pisses me off just slightly is the following situation: you have a char ** (an array of strings, say) variable and you want to just cast it to const char * const * (an array of const strings with const data). At first this seems perfectly fine, but C is so strongly typed that const pointers are not necessarily the same in memory as pointers.]
--
*** Quits: xriso:#kuro5hin (Forever)
[ Parent ]

What kind of crack are you smoking? (3.75 / 4) (#56)
by joto on Sun May 12, 2002 at 12:14:32 PM EST

Paragraph 1: That is usually not what I want.

Paragraph 2: Whatever language you are talking about here, it is not C. It might be C++ (in fact, that is why I interpret it as). I also fail to see what the problem is.

[ Parent ]

const is in ISO C (4.00 / 3) (#125)
by pin0cchio on Sun May 12, 2002 at 10:52:06 PM EST

Whatever language you are talking about here, it is not C. It might be C++

No, it's C. Plain old ISO C. Unlike old-skool K&R C, ISO C has the same 'const' rules for variables as C++.


lj65
[ Parent ]
thanks... (none / 0) (#234)
by joto on Tue May 14, 2002 at 10:43:04 AM EST

I didn't know that. Guess I've got to read up on some of the new "features" of ISO C.

Makes one wonder who is on the standardization committe. Considering "features" such as this, it doesn't seem there are many people interested in using C as a compiler-target, or automatically generating C code from other kinds of programs. But at least to me, that's only application I can find for it, except for writing OS'es, device drivers, and of course, inner loops.

[ Parent ]

RE: the C mindset (3.00 / 1) (#193)
by unknownlamer on Mon May 13, 2002 at 04:47:24 PM EST

...At first this seems perfectly fine, but C is so strongly typed that const pointers are not necessarily the same in memory as pointers.]

What! C is a weak statically typed language. You can very easily coerce any type into another type. A strongly typed language wouldn't allow you to perform a type conversion that didn't make sense (e.g. storing an integer as a void* [void* foo = 5; if ((int) foo)) ...]) You are probably just doing something wrong.


--
<vladl> I am reading the making of the atomic bong - modern science
[ Parent ]
You are Wrong (none / 0) (#227)
by codemonkey_uk on Tue May 14, 2002 at 05:46:56 AM EST

Put this in your compiler and smoke it:
void typetest( char ** a )
{
  char const * const * b = a;
}

---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
There's already a fix (3.75 / 4) (#30)
by Betcour on Sun May 12, 2002 at 03:11:30 AM EST

It's called Pascal ;)

Same concepts and very close syntax, but the pointers have disappeared (well you can use them if you want, but you don't have to) and it has strong type checking. Also it is case insensitive (I've always thought case sensitivity is a total stupidity, since human language is also case insensitive)

[ Parent ]
Pascal (4.33 / 6) (#32)
by Bad Harmony on Sun May 12, 2002 at 04:03:43 AM EST

The problem with Pascal, and many other high-level languages, is that the I/O is wired into the compiler. You end up with language support run-time packages that only run on a specific operating system. One of the big advantages of C was that the language support for I/O and other features was implemented in standard object libraries. This made it easy to target bare iron or non-standard run-time environments.

54º40' or Fight!
[ Parent ]

Yes and no (4.00 / 2) (#61)
by Betcour on Sun May 12, 2002 at 12:48:44 PM EST

Pascal comes indeed with hardwired IO, but then there's nothing to stop you from using the system IO calls instead. I find it more an advantage over C : you can write portable code using the built in IO routines, or aim for performance using the system routines. In C you are stuck with the system IO and if you want portability you have to write a IO wrapper for every possible OS you want to port to... (I'm not very familiar with C++ but I think there's also some IO streams that are abstracted above the system IO calls, so it ends up being the same as Pascal)

[ Parent ]
C++ I/O (5.00 / 3) (#77)
by fluffy grue on Sun May 12, 2002 at 02:52:13 PM EST

Yeah, C++'s iostream class abstracts I/O to the point that everything looks identical (interface-wise) to the programmer, whether it's identical or not on the OS, and then there's various specifications of it (such as fstream) which are the (internally) platform-specific wrappers which still use the singular iostream interface. So, with that setup, Windows programmers can enjoy the same "everything's a stream with the same API" mentality that UNIX has had for years. :)
--
"#kuro5hin [is like] a daycare center [where] the babysitter had been viciously murdered." -- CaptainObvious (we
[ Parent ]
What brand of crack are you smoking? (4.50 / 2) (#38)
by fluffy grue on Sun May 12, 2002 at 05:58:19 AM EST

Pointers are just as important in Pascal as in C. You just can't do pointer arithmetic on them, and they're strongly-typed.

I mean, come on, implement a linked list in Pascal without using pointers. I dare you.
--
"#kuro5hin [is like] a daycare center [where] the babysitter had been viciously murdered." -- CaptainObvious (we
[ Parent ]

True but (4.00 / 3) (#59)
by Betcour on Sun May 12, 2002 at 12:44:11 PM EST

Pointers are here only when strictly necessary. My biggest gripes about C is using pointers for everything : strings, arrays, writable variables passed to functions, etc...

Pascal/Delphi has pointers as well but only when strictly needed (linked list or trees, or when dealing with low level APIs). And you can do pointer arithmetic on them if you want (at least with Borlands version of Pascal) For everything else you can forget about it, since the pointer work is done by the compiler. A string is really a string, an array really an array (and not a stupid pointer to a reserved memory space). As a programmer I don't want to bother with pointers if I don't have to, they are just bugs waiting to happen (pointers leading to nowhere, memory leaks, pointers wrongly used as ints or the opposite, etc.)

[ Parent ]

True... (4.00 / 3) (#75)
by fluffy grue on Sun May 12, 2002 at 02:45:10 PM EST

But the number of cases where that makes pointers "strictly necessary" is a lot higher than you were implying.

But yes, I do like how Pascal/Delphi actually make a distinction between pointer and array. That near-isomorphism in C has always been very annoying (especially since there's some rare cases in C where an array is not analogous to a pointer!).
--
"#kuro5hin [is like] a daycare center [where] the babysitter had been viciously murdered." -- CaptainObvious (we
[ Parent ]

array based lists... (3.50 / 2) (#64)
by rebelcool on Sun May 12, 2002 at 01:08:48 PM EST

...are faster than pointer linked lists in practice (at least if your processor has a cache, it is) But I digress.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Not necessarily (5.00 / 2) (#72)
by fluffy grue on Sun May 12, 2002 at 02:42:57 PM EST

Try inserting an element into the middle of an array-based list.
--
"#kuro5hin [is like] a daycare center [where] the babysitter had been viciously murdered." -- CaptainObvious (we
[ Parent ]
That's a very simple array list. (4.50 / 2) (#85)
by rebelcool on Sun May 12, 2002 at 05:35:31 PM EST

This also depends on how you do your list. For example, do a cursor type list using arrays. Inserting in the 'middle' merely tacks the item on the end of the array, then updates another array containing values which point to the next item. It is roughly the same speed when you do it that way.

What makes array-based lists faster than node-based ones is the presence of a cache. The system will load the entire contiguous array into the cache, making future accesses to the list only hitting the cache.

With a cell-based one, an access to each node in the list requires going to main memory, then pulling it into the cache, then returning it.

Of course, this falls apart if you're using a very large dataset which is bigger than the cache. (This is why many scientific computers dont even have caches..its slower to try and cache something too big and fill it, than to just hop to main memory).

There are some other instances as well where you'll take a performance hit, but in general usage, array based linked lists are faster than node-pointer type.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Cursor-type list (4.00 / 2) (#95)
by fluffy grue on Sun May 12, 2002 at 06:45:30 PM EST

A cursor-type list still needs pointers to function, though.
--
"#kuro5hin [is like] a daycare center [where] the babysitter had been viciously murdered." -- CaptainObvious (we
[ Parent ]
Yes... (4.50 / 2) (#114)
by rebelcool on Sun May 12, 2002 at 09:04:38 PM EST

but the entire list is loaded into the cache because its stored in contiguous memory, unlike a node-based list which has its nodes spread out everywhere. This makes list access faster.

As far as insertion and deletion go, both are O(N), however in practice due to the cache, the array based one will be faster.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Cache block size (4.50 / 2) (#124)
by pin0cchio on Sun May 12, 2002 at 10:46:41 PM EST

but the entire list is loaded into the cache because its stored in contiguous memory

Contiguous memory allocation helps caching only when the items are smaller than the cache's block size. CPU caches typically run in units of 128 bits.

Virtual memory, on the other hand...


lj65
[ Parent ]
Correct. (4.50 / 2) (#126)
by rebelcool on Sun May 12, 2002 at 11:08:11 PM EST

In another post I mentioned how this is not true for very large datasets, and is precisely why many scientific computers do not have caches at all.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

correction (4.50 / 2) (#117)
by rebelcool on Sun May 12, 2002 at 09:10:43 PM EST

A cursor type list does NOT need pointers (in fact, if you're using a non-pointer language, such as Lisp, it is how you properly implement a linked list)

All you need is 2 arrays. One holding the data, the other holding the locations of the data in that array.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Pinters are needed (3.50 / 6) (#35)
by JanneM on Sun May 12, 2002 at 05:05:21 AM EST

One aspect of C that makes it so useful for _low_-level programming is the flexibility of pointers. Another aspect is the direct interface to low-level system routines. 'malloc' looks the way it does, because it directly mirrors the actual system call for allocating memory.

Remove those features from C, and you need to define another low-level language that has them; it's not clear how that would be an improvement.

 
---
Trust the Computer. The Computer is your friend.
[ Parent ]

I didnt say they werent needed (4.00 / 3) (#65)
by rebelcool on Sun May 12, 2002 at 01:12:01 PM EST

I said the syntax for them needs improving.

It would also be helpful to have more bounds-checking on them.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Runtime bounds checking... (4.50 / 2) (#106)
by vectro on Sun May 12, 2002 at 08:14:21 PM EST

... would shoot performance to hell.

How would you change the syntax?

“The problem with that definition is just that it's bullshit.” -- localroger
[ Parent ]

pointer syntax nit (3.50 / 2) (#107)
by Cal Bunny on Sun May 12, 2002 at 08:15:17 PM EST

Why can't they just ditch the arrow and always use dot as the membership operator?  The compiler knows the difference, this isn't saving you from any programming error, and there is no overhead.

^cb^
"tombuck.... [...], he's [...] *that* gay you know." - mrgoat
[ Reply to This ]
[ Parent ]
No overhead!? (1.00 / 1) (#152)
by kzin on Mon May 13, 2002 at 10:46:30 AM EST

The difference is huge. a.*b* means "uou know where a is. Now fetch me a part of it." a*->*b means "you don't know where a is, but you know where a pointer to a is. Please dereference it first so that you know where a is, then fetch me a part of it". a*->*b has dereferencing involved, while a.*b* does not. And dereferencing is probably one of the most expensive operations you can do on data in C, except for perhaps assignment of large structs. This is because dereferencing means one extra slow trip out of the cozy CPU and onto the slow bus.

I don't think it's only a question of performance, it's also a question of integrity; one of the design principles of C (and UNIX) is that the interface represents the implementation directly, without pretentions or pretentions. Having the same syntax for "find a member" and "dereference and find a member" would be to go against this principle.

What you probably want is a postfix dereferencing operator, like Pacal's (C has a*[0], but this sucks). If you could say that a * at the end of an rvalue means "dereference" just like a *\ in front of it does, you'd be able to say *a**.*b and be happy. The problem is that this means complicating the parser quite a bit, because it will have to run ahead of the point where it's at to see if there's no additional rvalue after the *, which would mean multiplication. All the other common characters are likewise taken.


[ Parent ]

No overhead!? (4.50 / 2) (#153)
by kzin on Mon May 13, 2002 at 10:51:58 AM EST

The difference is huge. a.b means "uou know where a is. Now fetch me a part of it." a->b means "you don't know where a is, but you know where a pointer to a is. Please dereference it first so that you know where a is, then fetch me a part of it". a->b has dereferencing involved, while a.b does not. And dereferencing is probably one of the most expensive operations you can do on data in C, except for perhaps assignment of large structs. This is because dereferencing means one extra slow trip out of the cozy CPU and onto the slow bus.

I don't think it's only a question of performance, it's also a question of integrity; one of the design principles of C (and UNIX) is that the interface represents the implementation directly, without pretentions or translations. Having the same syntax for "find a member" and "dereference and find a member" would be going against this principle.

What you probably want is a postfix dereferencing operator, like Pacal's (C has a[0], but this sucks). If you could say that a * at the end of an rvalue means "dereference" just like a * in front of it does, you'd be able to say a*.b and be happy. The problem is that this means complicating the parser quite a bit, because it will have to run ahead of the point where it's at to see if there's no additional rvalue after the *, which would mean multiplication. All the other common characters are likewise taken.

[ Parent ]

No extra overhead (5.00 / 1) (#231)
by zakalwe on Tue May 14, 2002 at 09:07:10 AM EST

By no overhead, I think he means that the compiler can always tell at compile time whether to dereference or not.  There is no runtime overhead in determining this.

ie. if you unify "->" and ".", then the compiler can always tell what you mean in the following code:

mystruct *pStruct;
mystruct struct;

pStruct.foo;  // Invalid in normal C - but could interpret at compile time.
struct.foo

ie. "." is now a "Get the member" operator, rather than redundantly telling the compiler how to get the member (it already knows if it is a pointer.)  

I don't really think it would be that confusing either.  After all, the same [] indexing is used for both arrays and pointers.  It'll never happen though, for one thing because the distinction is important in C++, due to operator overloading.


[ Parent ]

In the contect of the article... (3.00 / 2) (#54)
by joto on Sun May 12, 2002 at 12:09:32 PM EST

It would make much more sense to advocate the removal of typechecking on pointers.

We are after all talking about portable assembly here, not high-level languages.

[ Parent ]

What's wrong with the current syntax? (4.66 / 3) (#102)
by DJBongHit on Sun May 12, 2002 at 08:06:02 PM EST

An improved syntax would go a long way to preventing pointer problems.
Why? What's wrong with *foo to dereference and &bar to get a pointer to an object? That's really all it boils down to, and it seems pretty straightforward to me.

~DJBongHit

--
GNU GPL: Free as in herpes.

[ Parent ]
minor change (3.00 / 3) (#113)
by Cal Bunny on Sun May 12, 2002 at 08:31:47 PM EST

Get rid of -> and always use . would be by suggestions.

Maybe something silly like no overloading the meaning of * and use ` or ^ or % or $ or @ or something.

^cb^
"tombuck.... [...], he's [...] *that* gay you know." - mrgoat
[ Reply to This ]
[ Parent ]

Oh right (4.33 / 3) (#116)
by DJBongHit on Sun May 12, 2002 at 09:09:34 PM EST

Get rid of -> and always use . would be by suggestions.

Oh yeah, forgot about ->. But anyway, I'd keep -> as well as . since they serve different purposes (-> is like * and . combined).

~DJBongHit

--
GNU GPL: Free as in herpes.

[ Parent ]
Nothing... except (4.33 / 3) (#174)
by bored on Mon May 13, 2002 at 01:20:39 PM EST

The problem comes when people use pointers for everything. Combine that with the stupid auto pointer sizing on arithmatic gee-wiz and the code can quickly become a nightmare. I NEVER use the pointer++ syntax, instead if I need to refrence by the size I always use the array syntax. I do a _LOT_ of system level programming and other than byte scanning I never need to bump a real pointer (rather than one created because i've been reading to much K&R) by anything other than a single byte.

Its a massive debug boost to know that somevalue=someinterativedata[dataoffset].field is 'dataoffset' from the start of the structure and be able to instantly check the whole structure as well as the boundary condition. If dataoffset=10 and there should only be 10 elements in someinerativedata then you instantly know why somevalue is wrong. Flip the optimized on and its just as fast as somevalue=*fieldpointer. Which doesn't tell you if the loop that generated *fieldpointer worked, the data is wrong, or the base pointer was wrong.

The K&R book was a wonderful boot in the 70's but now its outdated. Many of the 'tricks' used to demostrate the language should _NEVER_ be used for a production product. Understand pointer syntax and functionality but use them as little as possible and watch your maintainablity and debug ability go way up.



[ Parent ]
const (4.66 / 3) (#105)
by Cal Bunny on Sun May 12, 2002 at 08:09:29 PM EST

const is fine in C, if you use it correctly.  From my perspective, nobody should ever say const int; you should always say int const.  This keeps everything consistent.

You read a variable declaration from right to left, so:

int const*const*

is a pointer to a constant pointer to a constant int.  If you place const before the int you cannot do this anymore.

This should be absolutely basic to anybody who learned C.  I don't know why dumbfucks put const before int and confuse everybody.

^cb^
"tombuck.... [...], he's [...] *that* gay you know." - mrgoat
[ Reply to This ]
[ Parent ]

FORTH and so on (4.33 / 6) (#9)
by k31 on Sun May 12, 2002 at 12:06:59 AM EST

Alternatives to C for low-level programming include "bigger" languages like C++, and "smaller" lanaguages like FORTH.

FORTH and REBOL are a bit alike to me, due to the ability to redefine keywords so easily. Also, both facilitate easy refactoring of code.

For a particulat platform, though, is a dialect of FORTH good enough? Probally... then the problem becomes interfacing with other code.

What is probally more important is an easy way of connecting heterogenous languages (like COBRA, COM, IPC, pipes, sockets... anything really). Since these things exist, perhaps it is more a question of making their usage more common. Process-level modularity rather than monolithic programs.

Something with tighter intregration with ASM and builting gfx routines would got a long way to making me happy with love level programming. At least, happier than I am with C.

Your dollar is you only Word, the wrath of it your only fear. He who has an EAR to hear....

One problem with Forth... (4.50 / 2) (#19)
by Alfie on Sun May 12, 2002 at 01:23:31 AM EST

Is that it tends to be a `write-only' language. Even with good comments one can have difficulty reading complex Forth code.



[ Parent ]
I don't think KNOWING it is a big requirement... (3.50 / 2) (#58)
by Robert Minichino on Sun May 12, 2002 at 12:29:11 PM EST

... to be able to read it. :) I've seen good and bad FORTH code, just as I'm sure you've seen good C code, and the output of IOCCC entrants. I do slightly prefer C to FORTH, unless I'm working on a really small system.

[ Parent ]
Forth, (4.00 / 2) (#165)
by bored on Mon May 13, 2002 at 12:34:41 PM EST

Yah, there is definitly that RO aspect but the 1:1 code:token is nice when you don't have the 'source'. Believe me, its easier to understand decompiled forth than disassembled C. The other issue is that forth is not very good at bit manipulation, event driven (read interrupt) programming, or threaded enviroments.

[ Parent ]
Documentation saves the day (none / 0) (#211)
by k31 on Mon May 13, 2002 at 11:14:17 PM EST

FORTH is, as far as I can tell, designed to be a very machine-level language, with documentation in parallel to the code rather than embedded in it.

I think this makes sense... it is similar to having a microchip and a seperate but related data book.

The C/C++/JAVA methods of embedding comments really serve to distract from the purpose of getting the machine to do the job you want it to. Moreover, having to dive into the implementation details of a class/struct/object thingy in order to find out how it works is besides the point of OOP/encapsulation, anyhow.

What is needed, perhaps, is a step beyond FORTH that puts an iconic side to modular programming.  


Your dollar is you only Word, the wrath of it your only fear. He who has an EAR to hear....
[ Parent ]

FreeBSD bootloader (4.50 / 2) (#108)
by Cal Bunny on Sun May 12, 2002 at 08:16:38 PM EST

The FreeBSD bootloader is written in FORTH.  If you look under the /boot you will see FORTH scripts.  This is an absolutely ruling way to do it, too.

^cb^
"tombuck.... [...], he's [...] *that* gay you know." - mrgoat
[ Reply to This ]
[ Parent ]
Alternative? (3.42 / 7) (#16)
by antizeus on Sun May 12, 2002 at 01:07:43 AM EST

I love C. I use it for everything.

You don't really make much of a case for why there needs to be an alternative. You've got some hyopthetical people who say "I hate C", but they're obviously horrible, horrible people and should be ignored. You also state that you find it hard to believe that C is the "end all, be all of low level programming", but don't provide specific issues which fuel your doubts -- you just say that "it may have it's problems".

By the way, that should be "its problems". Fortunately the article is still in edit mode. Remember that possessive pronouns don't have apostrophes.
-- $SIGNATURE

Specific issues (none / 0) (#69)
by hardburn on Sun May 12, 2002 at 02:15:18 PM EST

I purpasly avoided specific issues. The reason being that I didn't want this to turn into a language debate.

You also state that you find it hard to believe that C is the "end all, be all of low level programming", but don't provide specific issues which fuel your doubts -- you just say that "it may have it's problems".

It's just a simple matter of progress. Computers get smaller and faster, but I'm still using the same language Ritche used to write the first Unix? It's not so much a specific feeling that C sucks--I just wonder why it seems no progress has been made in the last 30 years.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
C has progressed (none / 0) (#110)
by pin0cchio on Sun May 12, 2002 at 08:20:44 PM EST

Computers get smaller and faster, but I'm still using the same language Ritche used to write the first Unix? It's not so much a specific feeling that C sucks--I just wonder why it seems no progress has been made in the last 30 years.

C has progressed. Important new additions to C since the first release of the UNIX system include longer external symbol names (31, up from 6) initialization of any member of the union (not just the first; useful in s), constructing new variables anywhere (rather than only at the beginning of the block, which sometimes forced deeply nested {} blocks that felt more like Scheme let* blocks than C), long long int, inline, variable-argument macros, pointer aliasing control with restrict, variable-length and zero-length arrays, complex arithmetic, and more. Discussion of this issue continues in this story.

Even without C99, we now have function prototypes, const, and good optimizations.


lj65
[ Parent ]
Alternatives (none / 0) (#81)
by PresJPolk on Sun May 12, 2002 at 04:15:04 PM EST

Programmers wanting a functional language have many languages to choose from.  Those wanting OO have many languages to choose from.  Systems programmers get to use C.

Why isn't there an alternative to C for the things C is good at?

[ Parent ]

My, how eloquent (none / 0) (#210)
by notafurry on Mon May 13, 2002 at 11:08:29 PM EST

And that modstorming attack... <sigh> It moved me, it did. Sheer astonishing brilliance.

Fuckwit.

[ Parent ]

"storming?" (none / 0) (#214)
by PresJPolk on Mon May 13, 2002 at 11:40:44 PM EST

I gave 1s to a thread full of namecalling and nothing else.  So what?

[ Parent ]
Bullshit. (none / 0) (#220)
by notafurry on Tue May 14, 2002 at 01:42:47 AM EST

Looking back through the thread, I see one comment that is a reply to an attack which could maybe justify a 1. I don't think so, but sure, maybe. The rest are at most sarcastic.

But you didn't look, you just swept through modding everything regardless of comment. There are even a couple of comments in there that aren't on the same topic, even though they're in the same thread.

Modstorming.

[ Parent ]

Sarcasm is of value? (none / 0) (#221)
by PresJPolk on Tue May 14, 2002 at 01:53:35 AM EST

Come on.  You were dragging out a thread that served no purpose.  The comments weren't informative, they weren't thoughtful, they weren't relevant to the discussion at hand, they had no value to anyone at this site.  So being below average, the highest rating they could get was a 2.  I gave them 1s.

If you don't like the way comment value and user trust are combined as they are, bug Rusty, not me.

[ Parent ]

the reason for C's popularity (5.00 / 1) (#137)
by eLuddite on Mon May 13, 2002 at 07:11:26 AM EST

I love C. I use it for everything.

Many people prefer C for the same reason many people prefer solving crossword puzzles instead of writing novels. That is to say, C is popular because (re)solving pointless puzzles is stereotypical geek behavior. That's fine. I repeat, that's fine. Or at least it would be fine if the software industry didnt absurdly reward and propagate such hobbyist behavior to the detriment of users who expect to take delivery of correct, robust software on time.

Rigorously speaking, since modern compilers for more or less every HLL generate code as fast as C, languages like C are only *necessary* when you need control over the way data is structured in memory. That is to say, languages like C are rarely necessary.

---
God hates human rights.
[ Parent ]

Really? (none / 0) (#138)
by Hong Kong Phooey on Mon May 13, 2002 at 08:04:54 AM EST

since modern compilers for more or less every HLL generate code as fast as C

Care to back that up with some evidence?

[ Parent ]

yes, really (none / 0) (#188)
by eLuddite on Mon May 13, 2002 at 04:07:14 PM EST

For example?

Let me ask you something. Unless you are writing system software where you obviously need too impose a specific structure on physical memory, do you really think your app will run compellingly faster coded in C than in, for example, VB, Delphi or Franz Lisp? I use a variety of HLL compilers including C and speed is not even remotely an issue.

Let me ask you a related question: do you think you can write faster assembler code than that churned out by a good C compiler? In theory, yes. In practice, you cannot. There's a point where the complexity of software systems and modern h/w architectures make a pessimization of "tinkering." As you raise complexity, the benefits of a HLL over C approach those of C over assembler. If I have a need to programmatically manipulate patterns in text, I'm not going to waste my time waiting for you to write slow Perl scripts in C, as it were. This is an important point to understand: 5 lines of Perl written by a webmaster will often run faster than 500 written by a C veteran.

---
God hates human rights.
[ Parent ]

C's popularity (none / 0) (#160)
by ucblockhead on Mon May 13, 2002 at 12:17:22 PM EST

C and C++ are popular because people find it easier to code in, and because companies that use C or C++ get products to market faster.

Gurus always through up lots of studies and crap to deny it, but what they never seem to do is put together competing products.

If C or C++ where really so godawful as you'd make us think, then you and your cohorts could make a mint making competing products.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

1st, C is not godawful, C++ is (none / 0) (#183)
by eLuddite on Mon May 13, 2002 at 03:15:09 PM EST

Second, HLL have been proven to be more productive of programmer time. The reason C is popular in PC software today is historical: PCs were once slow and C did once generate compellingly faster code than HLL compilers. The rest is a matter of market and institutional inertia.

Gurus always through up lots of studies and crap to deny it, but what they never seem to do is put together competing products.

This is point blank wrong. Your comment doesnt surprise me; the cult of C/C++ is a cult of myopia. I'm not saying anything controversial, here. I'm saying that unless you need control over the way data is structured in memory -- so called systems programming -- low-level languages are counterproductive.

---
God hates human rights.
[ Parent ]

Yes... (none / 0) (#187)
by ucblockhead on Mon May 13, 2002 at 03:46:44 PM EST

Yes...I know there are a few Lisp apps out there. How many are market leaders?

But clearly, if C++ was so horrible unproductive, you'd think at least one company would be using some other product to run rings around the id guys.

If you really, really believe this, then why not put your money where your mouth is, start a consulting company, and out compete all those C++ coders out there?
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Language dominance (5.00 / 2) (#191)
by jacob on Mon May 13, 2002 at 04:41:05 PM EST

First of all, I agree with you: a very real part of how good a language is, and the only thing that ought to matter to working programmers, is how easy it is to write the programs you need to write in it.

However, you should realize that there are a lot of factors that make a programming language easier for a particular program, and many of them amount more to a popularity contest than a fundamental superiority of the language. For instance, even though I'm a nut for Scheme in general and PLT Scheme in particular, I don't usually use it for CGI programming; instead I use PHP or perl. Why? Because PLT Scheme doesn't have the right libraries, and the other languages mentioned do. Yeah, I think Scheme rocks, but it doesn't do me much good if I can't connect to a damn database with it on Unix, now does it?

But I don't seriously think that lack of (say) mySQL support comes from some deficiency of PLT Scheme as a language; it's because PLT Scheme has had a few years of development by a handful of talented grad students with other things to do, while PHP and perl both have huge development efforts and substantial cash behind them, and both have been developed as 'web languages' for a long time. Do I believe that if Scheme became popular and Microsoft or Sun or somebody threw their pocketbooks at it, it would be able to take over the world? Yes. Do I think it's ready for commercial production as-is? For most purposes, no.

In short, I think market forces are good at telling you what package has overall the best support right now, but they aren't good at all at telling you what deserves your support for the future.

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]

yes! (none / 0) (#194)
by eLuddite on Mon May 13, 2002 at 05:00:03 PM EST

How many are market leaders?

Why would that matter on technical grounds? MacDonald's is also a market leader.

you'd think at least one company would be using some other product to run rings around the id guys.

Why should one have to wonder about the contingent facts of C++'s history and market position? Why shouldnt you be forced to ponder why, for example, Naughty Dog's Crash Bandicoot Game system and Nichimen Graphics' N-World Game System were written in Lisp?

You are also resisting the point: if you need a low level systems language, nothing else will do. If you dont need a low level systems language, everything else is a better use of your time, your company's time and that of your customers. NVidia needs a low level language to talk to their hardware; portions of DirectX obviously need to be written in a low level systems language; *I* dont need a low level language to call DirectX. If my game sinks or swims according to its AI, C is a suboptimal choice. If my game sinks or swims because it calls a foreign API, the year is 1980.

---
God hates human rights.
[ Parent ]

resisting points... (none / 0) (#196)
by ucblockhead on Mon May 13, 2002 at 05:51:51 PM EST

I'm not sure how I'm resisting a point...you keep telling me that I'm wildly unproductive. I see no evidence of that.

Presumably if me or my company was wildly unproductive, we'd be driven out of business by wildly productive Lisp coders.

And McDonald's is a damn good example. Because clearly if someone else could produce the same product they do at a cheaper price, McDonald's would be in a real bind, business wise.

In any case, one or two examples is not what I am talking about. Clearly Naugty Dog hasn't put all its competitors out of business using the massive productivity boost they gained by using Lisp.

You keep saying that I'm resisting the "point" that I'm somehow hosing my productivity using C++. I'm not resisting it. I am flat out saying that you are wrong. I personally think that you vastly overrate the importance of the programming language in a programmer's job.

But I tell you what...the minute I start seeing other people outproducing me, or I start missing deadlines, I will look into switching languages.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

i could be wrong (none / 0) (#199)
by eLuddite on Mon May 13, 2002 at 06:44:43 PM EST

You keep saying that I'm resisting the "point" that I'm somehow hosing my productivity using C++. I'm not resisting it.

You're not? If you arent resisting the "point", let's force you to clarify your position. Do you think C (please stick to the subject which isnt C++) is a productive use of time when (a) your software doesnt care about the way data is arranged in physical memory; (b) saving 2 or 3 seconds per minute of running time isnt cause for anyone's concern?

If you think C is a productive use of time under those conditions then it must be easier to write software in C than in a HLL. If you think C is a productive use of time under those conditions then presumably my comment to Hong Kong Phooey is the object of your wholesale disagreement.

So what's it going to be? Either the thread is dead and I've made my point re: systems programming languages, or you can write that game AI in C sooner, cheaper and better (performance wise) than could a Lisp programmer. If I havent made my point then programming languages cannot be compared objectively. If I havent made my point then software engineering has to demure on matters of "taste" and "like"; since you like C, where you takes on values of C prima donnas, C is a productive use of time.

?

Because clearly if someone else could produce the same product they do at a cheaper price, McDonald's would be in a real bind, business wise.

McDonald's isnt cheap; but yes, I suppose if someone could market and deliver something so rare as bad tasting food as well as McDonald's, McDonald's would be nervous.

In any case, one or two examples is not what I am talking about. Clearly Naugty Dog hasn't put all its competitors out of business using the massive productivity boost they gained by using Lisp.

For the last time, I'm not arguing C's penetration in the market. I've already said that C enjoys great market and institutional inertia. I do not dispute the contingent facts of C and C++'s history, I dispute the merit of their uncritical (ab)use.

---
God hates human rights.
[ Parent ]

C? (none / 0) (#203)
by ucblockhead on Mon May 13, 2002 at 07:19:38 PM EST

Who said anything about C?

You seem not to realize how much software out there is C++.

Like almost all non-server Windows programs, for one.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

ok (none / 0) (#204)
by eLuddite on Mon May 13, 2002 at 08:12:43 PM EST

Who said anything about C?

I think you should review the thread from the top.

You seem not to realize how much software out there is C++.

Yes, but the unless the codebase is new, much of that "C++" software is C with class instead of struct. In any case, I have a low opinion of C++ for entirely different reasons.

As a matter of little but related interest, when I wrote:

The reason C is popular in PC software today is historical: PCs were once slow and C did once generate compellingly faster code than HLL compilers. The rest is a matter of market and institutional inertia.
I meant the following: the point about market and institutional inertia is to recognize that C and PCs are inextricably linked in history and tradition. I remember well when microcomputer magazines such as BYTE, PC Magazine and Dr. Dobbs began to litter their pages with C benchmarks and ads for lattice, microsoft and borland C. For years C benchmarking was almost indisinguishable from popular computer "science".

(1) PCs were slow enough that only universal assemblers such as C seemed to matter; (2) since no alternative language vendor was able to compete with the aforementioned big three's advertising budgets, alternative languages didnt get press.

Although the historical accumulation of effort and technology has resulted in excellent contemporary C/C++ *compilers*, the result of that market competition should not be confused with any intrinsic *language* superiority for C or C++ at the higher level. C is as much a culture as it is a computer language; and as everyone knows, "my culture is better than yours" is a constant cultural refrain.

---
God hates human rights.
[ Parent ]

"my culture is better than yours" (none / 0) (#208)
by ucblockhead on Mon May 13, 2002 at 10:44:56 PM EST

You know, that's not something I've been saying here, and frankly, most of us C++ types just want to talk programming. It's always you guys that come in, guns blazing. And frankly, the biggest difference I see in the computing cultures is that most C++ guys are just interested in coding. But then, C++ is a pragmatic language, not an academic guru language. Funny how it is the pragmatic languages, like Perl, C/C, etc. that gain market share despite the constant bashing from the academics.

I've been working in the industry for a long time. What you say doesn't match what I've seen. I think I'll trust my own experience rather than assertions by random internet users. Suffice to say that my experience with the C++ software out there does not match your assertions. What you say was true about ten years ago, when C++ was not well understood. It is not the case now.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

I like C, I like Perl, C++ is RATFOR for C (none / 0) (#213)
by eLuddite on Mon May 13, 2002 at 11:25:19 PM EST

except RATFOR never went out of control.

C++ is a pragmatic language

Yeah, yeah, not as pragmatic as ADA. Look, "pragmatism" is less a feature than an *excuse* for perpetuating C++. Apropos that, one of the reasons I tolerate Common Lisp's biblically thick language definition is that definition's testament to pragmatism.

I've been working in the industry for a long time. What you say doesn't match what I've seen. I think I'll trust my own experience rather than assertions by random internet users.

Right back at you. What do you mean you've been "working in the industry a long time?" Do you mean you've been writing C++ a long time? Good for you. Like I said before, "your comment doesnt surprise me; the cult of C/C++ is a cult of myopia."

Finally, this thread was about the place of low level languages such as C. C++ is not a low level language unless it is used to compile more or less vanilla C. Since I did not once slag C++ in this entire thread, I have to wonder if your testiness isnt a symptom of something deeper. Why are C++ programmers so sensitive and possessive of their language's warts? I mean, it does have great big ugly warts. It indisputably sucks at the fundamental level where its design meets its HLL pretensions.

most C++ guys are just interested in coding

Aw, that's so sweet.

---
God hates human rights.
[ Parent ]

whatever (5.00 / 1) (#215)
by ucblockhead on Mon May 13, 2002 at 11:41:31 PM EST

Since I did not once slag C++ in this entire thread...
You have a short memory.

Anyway, I've used1 many, many languages over the last twenty years, including C, Assembly, Perl, Javascript, BASIC, Rexx, Bash, Forth, Pascal and Fortran. So no, I'm not just some schmuck who knows nothing but C++.

I think C++ guys are testy because every time there's an article on C++ posted, a bunch of clueless idiots post uninformed nonsense like "The STL is slow".

I mean, Jesus fucking Christ, I'm not even saying that anything is wrong with any other language. You don't want testy C++ guys? Well, maybe you shouldn't be posting "C++ sucks" comments in every article about C++.

1By "used", I mean "used professionally", as in "was paid money to write in". (I did a bit of AI work in Lisp while at college, long ago, and a bit of Modula II work that I was unfortunately not paid for. So at one point I knew those languages, but can't really say I used them "professionally".)
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

my memory is fine (none / 0) (#216)
by eLuddite on Tue May 14, 2002 at 12:10:44 AM EST

What does a passing reference to "the cult of C/C++" have to do with C++, the language? The cult of C/C++ refers to the programming community's acceptance of "widely used" to justify their arguments without making similiar distinctions between, for example, Bill Gates' beloved basic. How can you argue X is widely used and Y is not if you don't even consider "widely used" relative to specific markets? Sure, C++ does games, but Basic does better -- much better -- than C++ in many other lucrative markets. Why does the cult also ignore academic software which hasnt migrated to market? Eventually it will. Finally there's the small matter of the cult's imposition of ancient PDP architecture as a prevailing, unquestioned metaphor for "low level." Modern h/w is complex and what made C a good idea 25 years ago makes it less predictably so today.

You don't want testy C++ guys? Well, maybe you shouldn't be posting "C++ sucks" comments in every article about C++.

Maybe I shouldnt but the design flaws of C++ remains unaffected whether I do or do not. Eh, I'll have my fun.

We all program in C++ for money if not for love.

---
God hates human rights.
[ Parent ]

yes, your memory sucks. (none / 0) (#217)
by ucblockhead on Tue May 14, 2002 at 12:26:23 AM EST

The title of the linked comment calls C++ "godawful", so yes, you did slag on it in this thread.

Yes, C++ has flaws. But all in all, it is a productive language, which is why people use it. Not because some sort of "cult", because many people find it useful to do so.

And yes, I am quite aware that Visual Basic, Java, Perl, and many other languages have their markets. Hell, I even, myself, personally prefer Perl in many areas. And I'd probably use Java if I were to do server work. (I'd quit before using VB again, but I'm sure some people find it useful.)

That doesn't make your C++ bashing any less ignorant. The trouble with most C++ bashing is that it is done by people who are clueless as to the real flaws, and who regurgitate mythical crap that is just, flat out, not true.

As to why people often ignore academic software, it is because a lot of academic software frankly sucks, and is useless for real work.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

my memory isnt as bad as your style of argument (none / 0) (#218)
by eLuddite on Tue May 14, 2002 at 12:32:51 AM EST

The title of the linked comment calls C++ "godawful", so yes, you did slag on it in this thread.

This meta bickering is pointless. The subject wasnt part of any argument as much as it was meant to insult your attempts to stray off topic.

That doesn't make your C++ bashing any less ignorant. The trouble with most C++ bashing is that it is done by people who are clueless as to the real flaws, and who regurgitate mythical crap that is just, flat out, not true.

I'm sure you arent referring to me; my knowledge of C++ is exemplarary.

As to why people often ignore academic software, it is because a lot of academic software frankly sucks, and is useless for real work.

Computer graphics was once academic software. As was Java and compilers. I find your anti-intellectualism disturbing.

---
God hates human rights.
[ Parent ]

to summarize (none / 0) (#219)
by eLuddite on Tue May 14, 2002 at 01:00:47 AM EST

The substantive history of point of this thread began:

I like C.

To which I replied:

Rigorously speaking, since modern compilers for more or less every HLL generate code as fast as C, languages like C are only *necessary* when you need control over the way data is structured in memory. That is to say, languages like C are rarely necessary.

To which you replied as follows.

  • C and C++ are popular because people find it easier to code in,
    • FALSE! Patently so.
  • and because companies that use C or C++ get products to market faster.
    • FALSE! Unless you count buggy software.
  • Gurus always through up lots of studies and crap to deny it, but what they never seem to do is put together competing products.
    • FALSE! I gave you the example of 2 products in the games industry, an industry where your assertion would be expected to hold.
  • If C or C++ where really so godawful as you'd make us think
    • Please infer less and reread what I wrote in italics in reply to a sentiment about C.
As the thread began to veer off-topic, I pressed my original point:

You are also resisting the point: if you need a low level systems language, nothing else will do. If you dont need a low level systems language, everything else is a better use of your time, your company's time and that of your customers. NVidia needs a low level language to talk to their hardware; portions of DirectX obviously need to be written in a low level systems language; *I* dont need a low level language to call DirectX. If my game sinks or swims according to its AI, C is a suboptimal choice. If my game sinks or swims because it calls a foreign API, the year is 1980.

As the thread began to veer off topic, I asked you to clarify your position re: the place of systems languages here. I should have let the thread end with your non-reply.

---
God hates human rights.
[ Parent ]

Um, C++... (3.66 / 3) (#20)
by delmoi on Sun May 12, 2002 at 01:29:49 AM EST

Why not just use C++ for that low level stuff?
--
"'argumentation' is not a word, idiot." -- thelizman
No, C++ is too complex (5.00 / 1) (#39)
by jtra on Sun May 12, 2002 at 07:01:45 AM EST

Well, C++ is too complex, in sense of language, syntax, language semantic and compiler complexity.

C++ is hard to parse. There is no such a thing like standard C++ compiler; complexity of language hurts portability of source code then.

There are many things that work behind the scenes (i.e. copy constructor calls). These make source code opaque. Low level stuff needs to be clear.

There is no usable standard of calling convetions that would cause interoperability between two C++ compilers on method calling level. This is often needed with low level stuff.

--

--Get textmode user interface for Ruby, http://klokan.sh.cvut.cz/~jtra/
[ Parent ]

Clarity? (none / 0) (#42)
by Matrix on Sun May 12, 2002 at 08:43:48 AM EST

These make source code opaque. Low level stuff needs to be clear.

And yet you advocate using C for low level stuff. Interesting definition of clarity you got there. ;)


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

Clarity (4.00 / 3) (#50)
by tjb on Sun May 12, 2002 at 11:01:50 AM EST

He isn't talking about clarity from a high-level standpoint, as in "What does this do?" but rather clarity from a compiled standpoint.

One of the things that's nice about C in small embedded environments is that it has a simple relationship to the underlying assembly language.  Back when I did embedded development in C, I could look at the C code and tell with relative certainty how many assembly instructions and in what form a given line of the C would compile to.  When you have 12MHz, 8K of RAM and hard-realtime requirements, these are nice things to know as it makes easier to avoid doing something stupid that will bloat your code.

Tim

[ Parent ]

There is such a thing as a standard c++ compiler (none / 0) (#67)
by felixrayman on Sun May 12, 2002 at 01:37:10 PM EST

The announcement of a standard C++ compiler is here. It "fully implements the 1998 ISO/ANSI C++ standard". There was a post on "that other site" about it a day or two ago.

Call Donald Rumsfeld and tell him our sorry asses are ready to go home. Tell him to come spend a night in our building. - Pfc. Matthew C. O'Dell

[ Parent ]
Too slow [nt] (1.00 / 1) (#84)
by Hong Kong Phooey on Sun May 12, 2002 at 05:27:23 PM EST



[ Parent ]
no, it is not too slow (none / 0) (#159)
by ucblockhead on Mon May 13, 2002 at 12:13:32 PM EST

This comment betrays a lot of ignorance, because 80% of C++ features have no overhead. Some C++ features (like templates, inlining) can produce faster code than C.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Maybe (none / 0) (#206)
by Hong Kong Phooey on Mon May 13, 2002 at 09:34:14 PM EST

If you stay away from the STL.

[ Parent ]
the STL (none / 0) (#209)
by ucblockhead on Mon May 13, 2002 at 10:50:18 PM EST

The STL boosts performance.

A test: benchmark the C qsort with the STL sort. You might be surprised to discover that the STL sort is faster.

If you think that the STL produces slow code, then you don't understand what the STL is. To put it in C speak, it is a supercharged macro library. The STL does produce large code. It is a very good example of trading memory for speed. But if you think it is slow, you are very woefully misinformed.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

blows out cache (none / 0) (#223)
by Cal Bunny on Tue May 14, 2002 at 03:42:47 AM EST

The STL often generate so much code that it blows the cache.  Nice example of qsort() which is probably the sweet spot of the STL when compared to the C way of doing it.  The datastructure segment of STL I consider performance poor.

^cb^

[ Reply to This ]
[ Parent ]
Well (none / 0) (#233)
by Hong Kong Phooey on Tue May 14, 2002 at 09:58:06 AM EST

Every benchmark I've seen comparing STL/Non-STL programs have shown a considerable speed advantage for the non-STL implementation.

[ Parent ]
Sometimes you don't have a choice (none / 0) (#238)
by Salamander on Tue May 14, 2002 at 11:11:19 AM EST

If you're writing drivers, filesystems, or kernel code on just about any general-purpose OS, you're stuck with C. Interestingly, the one major exception is NT, which fully supports C++ in the kernel and even requires it in some cases (e.g. filesystems must catch exceptions). Every flavor of UNIX with which you might be familiar lacks runtime and tool support for C++ in the kernel.

It's really nice that embedded-system folks get to use C++. Unfortunately they're not the only ones doing low-level work, and they should count their blessings.



[ Parent ]
The Reason: (3.00 / 4) (#22)
by Canthros on Sun May 12, 2002 at 01:38:31 AM EST

A good alternative to C would have to have some pretty significant advantages (readability would be the big one, probably) to make it worth bothering with, yet it would have to retain the things that make C useful for low-level and systems programming. Such a language either does not exist, or does not have enough advantage to recommend it over C. So, C, despite its questionable-to-atrocious naming conventions and cryptic syntax continues to be.

--
It's now obvious you are either A) Gay or B) Female, or possibly both.
RyoCokey
examples? (2.33 / 3) (#24)
by markb on Sun May 12, 2002 at 01:59:35 AM EST

Would you care to provide some examples of "questionable-to-atrocious naming conventions and cryptic syntax?" I'm not saying that C does not have these problems, but when you make a claim, you should back it up.

[ Parent ]
strcpy() (4.00 / 1) (#55)
by John Milton on Sun May 12, 2002 at 12:10:53 PM EST

It's not atrocious, but did someone really think they were saving time by taking the "o" out of copy? Do programmers not use vowels?


"When we consider that woman are treated as property, it is degrading to women that we should Treat our children as property to be disposed of as we see fit." -Elizabeth Cady Stanton


[ Parent ]
Symbol Names (4.00 / 1) (#90)
by Bad Harmony on Sun May 12, 2002 at 06:31:53 PM EST

When your linker and object file format only support 6..8 significant characters in symbol names, it's important to keep names short. Early C compilers often had to coexist with the OS vendor's development tools on operating systems that were designed when every bit was precious. Even on UNIX, early versions of the operating system only supported 8 character global symbols, with one used for the leading underscore, leaving 7 characters.

54º40' or Fight!
[ Parent ]

Good Point (none / 0) (#96)
by John Milton on Sun May 12, 2002 at 06:49:24 PM EST

I suspected that, but I wasn't sure if it was the reason. I still think the point about cryptic naming conventions is valid in some cases, Even if it was necessary, today it's dated. I know it's not hard to memorize stuff like strcpy(), but even today I see people using condensed symbols like that. Don't even get me started on the horror that is Hungarian Notation. I recently decided that I should learn the win32 api, and I felt like my eyes were bleeding.


"When we consider that woman are treated as property, it is degrading to women that we should Treat our children as property to be disposed of as we see fit." -Elizabeth Cady Stanton


[ Parent ]
Uniqueness in three letters and more! (none / 0) (#60)
by Canthros on Sun May 12, 2002 at 12:47:21 PM EST

Naming conventions: should be real obvious within the standard C libraries, particularly the string library (string.h). Things like tmpnam(), strtoull(). Names should not be that information dense. Also the inconsistency that we have strtoull() and atoi() (why atoull() or strtoi()?)By having that sort of thing going on in the standard library, it encourages future programmers to follow similar conventions. As a point of purely personal taste, I also find the use of underscores_to_separate_words to be ugly, but that's a personal thing.

As for cryptic syntax, how about:

while (1) { (char c = *(s++)) == 0 ? putc(c) : goto next; } next:

That's not even a really good example: cryptic one-liners are not something I make a practice of in any language. There are some real doozies, though, that you can do in C. Frankly, I assumed that everyone was familiar enough with C to recognise these problems.



--
It's now obvious you are either A) Gay or B) Female, or possibly both.
RyoCokey
[ Parent ]
Whoops. Uniqueness in *six* letters. [nt] (none / 0) (#62)
by Canthros on Sun May 12, 2002 at 12:54:14 PM EST



--
It's now obvious you are either A) Gay or B) Female, or possibly both.
RyoCokey
[ Parent ]
bad style (none / 0) (#70)
by ucblockhead on Sun May 12, 2002 at 02:31:08 PM EST

That snippet is just plain bad style. You are breaking at least three different common style rules in one line1. You can't blame a language for that. You can create crappy, confusing code in any language. (You also appear to have the if reversed, unless you really intend to display only nulls, ending on the first non-null.)

Here's what I think you intended:

for( ; *s != 0; s++)
  putc(*s);

Not that hard to understand when done right, is it?

It is true that C allows obfuscated code. But it does not, by any means, require it.

1You are using a goto. you are using the ternary "?:" operator unnessasarily. You are using an infinite loop for non-infinite looping.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Fair enough. (3.00 / 1) (#74)
by Canthros on Sun May 12, 2002 at 02:44:55 PM EST

What I was shooting for was some sort of ridiculous one-liner. And you're right: I reversed the results on the ternary operator. Were I not trying to make it ugly, I probably would have done something different. Which is to say that my usual programming style is much clearer (if somewhat too straightforward: your solution is probably more efficient than what I'd have written).

I still feel that C tends to slightly more cryptic syntax than some other languages. I don't think that's necessarily a problem, but I have trouble keeping track of the difference between the postfix and prefix operators, and the ternary operator. Pointer arithmetic bothers me most of the time, too.



--
It's now obvious you are either A) Gay or B) Female, or possibly both.
RyoCokey
[ Parent ]
Increment and Ternery (none / 0) (#111)
by vectro on Sun May 12, 2002 at 08:25:05 PM EST

Postincrement and Preincrement are easy: If the ++ goes in front, then it's done before the value is used. If it goes behind, then it's done after the value is used.

You should only use the ternary operator when it's absolutely necessary, and operator precedence is made clear.

“The problem with that definition is just that it's bullshit.” -- localroger
[ Parent ]

Rules are made to be broken (none / 0) (#101)
by pin0cchio on Sun May 12, 2002 at 08:00:44 PM EST

You are breaking at least three different common style rules in one line

Rules are made to be followed most of the time but broken when the benefits clearly outweigh the costs.

You are using a goto.

Sometimes, in a language without exception handling, a goto is the most efficient way to break out of several nested blocks.

you are using the ternary "?:" operator unnessasarily.

The definition of "unnecessarily" invites controversy. People with a LISP or Scheme background tend to use ?: often and use it well. Which of the following do you find clearer?

if(x < 0)
  set_status_bar(screen, 6, "Negative");
else   set_status_bar(screen, 6, "Positive");

set_status_bar(screen, 6,
  (x < 0)
  ? "Negative"
  : "Positive");

To me, the latter example more closely ties the result to the decision. But maybe that's because I took a class where I spent a couple months coding in nothing but Scheme.

You are using an infinite loop for non-infinite looping.

Again, it lets you break out of the loop easily if you need to short-circuit the rest of the block without having to indent if() { } blocks halfway across the screen. Plus it gets rid of those pesky state variables that eat up stack space in a recursive function.


lj65
[ Parent ]
Yes... (none / 0) (#103)
by ucblockhead on Sun May 12, 2002 at 08:07:25 PM EST

Rules are made to be broken...if there's an advantage to do so. In the provided example, there was no such advantage.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Ugh (5.00 / 1) (#76)
by fluffy grue on Sun May 12, 2002 at 02:48:43 PM EST

If you're going to use goto-type constructs, you could at least use the right ones! (namely break)
--
"#kuro5hin [is like] a daycare center [where] the babysitter had been viciously murdered." -- CaptainObvious (we
[ Parent ]
Ada? (4.50 / 2) (#121)
by aidan on Sun May 12, 2002 at 09:44:05 PM EST

Ada has much more readable syntax, pretty reminiscint of Pascal.

It's also strongly typed by default,but still allows you the ability to cast between types (but you have to Really Mean It).

It allows you to get down and nasty with bits through the use of representation clauses (which let you say "for this type, use this much memory", or "this variable is to be located here"), and do pretty much any bit twiddling you want.

It's also standardised, portable, and has bindings to Posix, GTK, GNOME, ORBit, and some fine object oriented features.

- Aidan



[ Parent ]
Hmm... great question. Let's make one up! (3.00 / 5) (#25)
by xriso on Sun May 12, 2002 at 02:09:11 AM EST

Here's what I want to see, for starters:
  • I don't have to #include <library.h> and then link with -lrary. I want something like Pascal's units.
  • Let the code ask the compiler about system-varying things, such as comparing types -- Ask the compiler if int == long int or if all pointers are the same internal representation. This means that the code can decide whether it needs to convert each and every element of an array from int to long int before calling void foo(long int *a). On many systems there is no difference so it would just be inefficient.
  • Put some other cool stuff in.
  • Make a better standard library.
I dunno. Get rid of the stuff that is never used anymore and put in stuff that will be used.
--
*** Quits: xriso:#kuro5hin (Forever)
types (3.50 / 2) (#46)
by ucblockhead on Sun May 12, 2002 at 10:00:35 AM EST

In regards to the second bullet:

Just do if(sizeof(int) == sizeof(long))
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

That could bring runtime performance problems (5.00 / 1) (#104)
by pin0cchio on Sun May 12, 2002 at 08:07:26 PM EST

if(sizeof(int) == sizeof(long))

On most compilers, a block preceded by such an if statement is kept or deleted at compile time. However, some broken compilers for some oddball architectures (to which GCC has not yet been targeted) don't optimize very well and leave the non-taken branch in the code.

In addition, sometimes you want your code to even compile if you're not on a conforming platform. The user won't discover that your software doesn't work on her platform until she runs make test or (worse) actually tries to install the program.

Best approach is to #include <limits.h> and catch word-size and endianness incompatibilities at preprocess time.


lj65
[ Parent ]
Pl/I (3.50 / 2) (#26)
by kjb on Sun May 12, 2002 at 02:16:19 AM EST

PL/I was a "systems programming" language for years, before it was displaced by C. I'm not really sure why.

The main reason I can think of is that it looks "primitive".

Oddly, PL/I is still used in a few places on the project I work on, for specific purposes (legacy batch processes manipulating stuff in a database).

Then there's PL/X, which is a bizarre combination of PL/I and C. Very strange-looking.

--
Now watch this drive.

Compiler Complexity (4.33 / 3) (#27)
by Bad Harmony on Sun May 12, 2002 at 02:51:47 AM EST

PL/I was crippled by the complexity of the language. Most compilers implemented subsets of the full language. I still have a PL/I book stashed away somewhere that spends a lot of space on telling you which features are implemented on which compiler.

54º40' or Fight!
[ Parent ]

Ah (none / 0) (#29)
by kjb on Sun May 12, 2002 at 03:08:52 AM EST

Interesting, I didn't know that.

It sounds a bit like a foreshadowing of what happened with Ada.

--
Now watch this drive.
[ Parent ]

Ada (3.00 / 2) (#33)
by Bad Harmony on Sun May 12, 2002 at 04:09:54 AM EST

That's one of the reasons that the Defense Department put so much emphasis on compiler validation for Ada. They held the trademark on Ada and you couldn't call it an Ada compiler unless it implemented the full language and had been validated.

54º40' or Fight!
[ Parent ]

Ada (5.00 / 1) (#120)
by aidan on Sun May 12, 2002 at 09:35:30 PM EST

Yes, but we do have a number of validated Ada compilers, both Ada '83 (the first version) and Ada '95 (the new one).

Both are suitable for real time and systems programming, and Ada '95 adds some very nice object oriented features to the mix.

There is also GNAT, a high quality Ada '95 implementation available as part of gcc 3.1 and seperately (straight from ACT, or for packaged for GNU/Linux at GNUAda, or as part of FreeBSD (ports/lang/gnat)

- Aidan



[ Parent ]
Ah, yes (none / 0) (#53)
by joto on Sun May 12, 2002 at 12:03:55 PM EST

It was the C++ of our time then?

[ Parent ]
Pascal (3.92 / 13) (#28)
by Betcour on Sun May 12, 2002 at 03:07:16 AM EST

Pascal has the same structures as C, let you do everything you can do in C but without being such a pain : strings are real strings (and not a dumb pointer on a 0 terminated array of byte), types are checked, syntax is human readable, etc. And the best of all : compilation is several order of magnitude faster than any C compiler can do.

I used Delphi (the only modern version of Pascal) to make lowel level coding for Windows (DirectX, sockets etc.) and it's a breeze. Your project is built in the same time it takes to press the F9 key ("run"), you can insert seamlessly ASM code inside your Pascal source, interfacing to all Win32 API or other third party libs is very easy, etc.

Now that Delphi has been ported to Linux (Kylix) this might be a worthwhile option... or you can use FreePascal, an open source Pascal compiler, but you'll miss some of the neat features of Delphi (including full OO and other nifty enhancements)

If you like Delphi... (4.50 / 2) (#37)
by fluffy grue on Sun May 12, 2002 at 05:53:58 AM EST

You might like C#, which was developed by the same guy. It's basically Delphi with a C-ish syntax. (FWIW, I loved Delphi; it's what I learned OOP on, and previously I was a huge fan of Turbo Pascal.)

I'm looking forward to a Linux-based compiler... I actually want to play with it! (I don't care if MS paid for the development of it.)
--
"#kuro5hin [is like] a daycare center [where] the babysitter had been viciously murdered." -- CaptainObvious (we
[ Parent ]

C# (4.50 / 2) (#45)
by ucblockhead on Sun May 12, 2002 at 09:58:41 AM EST

C# is not what I'd call "low level", though.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Which part? (none / 0) (#73)
by fluffy grue on Sun May 12, 2002 at 02:43:44 PM EST

The language itself could easily be compiled directly to native assembly code, just like Java can (with gcj). Just because it's intended to be run in a VM doesn't mean it must be.
--
"#kuro5hin [is like] a daycare center [where] the babysitter had been viciously murdered." -- CaptainObvious (we
[ Parent ]
not the VM (none / 0) (#78)
by ucblockhead on Sun May 12, 2002 at 03:08:07 PM EST

For one, I find the weird way that structures are on the heap, and classes not, except when using "boxing", to be very confusing. I suspect it leads to errors.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Hm (none / 0) (#79)
by fluffy grue on Sun May 12, 2002 at 03:49:19 PM EST

That's where I have to admit that I haven't read up that much on C#, and only have a cursory knowledge of it.
--
"#kuro5hin [is like] a daycare center [where] the babysitter had been viciously murdered." -- CaptainObvious (we
[ Parent ]
C is good enough (4.28 / 7) (#34)
by swr on Sun May 12, 2002 at 04:32:02 AM EST

Yet in 30 years, no language has been created that has usurped C's position of the best "cross-platform assembly language".

How many "cross-platform assembly languages" do we really need? Answer: One, and C fills that role just fine.

Why invent another language, and expect people to write compilers for it, and expect people to learn it, and expect people to use it instead of C? For low-level programming, C gets the job done. Just how much improvement can you really expect to get in a low-level language? Sure there's plenty of room to develop nicer languages that high-level programmers will love enough to not care about the additional RAM and CPU requirements. But for low-level programming, where what you really want is just a cross-platform and human-readable version of assembly, C is great. Certainly it could be better, but then it wouldn't be C anymore, and you'd have to convert developers to it.



C isn't a good assembler (3.00 / 1) (#119)
by Pseudonym on Sun May 12, 2002 at 09:26:50 PM EST

How many "cross-platform assembly languages" do we really need? Answer: One, and C fills that role just fine.

No it doesn't, as anyone who has actually tried to use C as a cross-platform assembly language for a modern language will tell you.

Some of the things which C does not do well include:

  • Tail calls
  • Computed gotos
  • Exceptions
  • Multiple return values
  • Accurate garbage collection
  • Non-local return/backtracking
Some of these are available as extensions (e.g. in gcc), but that's not the same as "C fills this role just fine".

This is part of the motivation behind C--, which is a project started by high-level language implementors mostly because they were sick of banging their heads against C's limitations.



sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
[ Parent ]
Low-level? (3.80 / 5) (#41)
by kaemaril on Sun May 12, 2002 at 08:12:34 AM EST

How low do you want to go? Doesn't anybody use assembler anymore? :)


Why, yes, I am being sarcastic. Why do you ask?


well, not exactly (4.40 / 5) (#43)
by oliv on Sun May 12, 2002 at 09:31:34 AM EST

"I hate C. I use OCaml for everything."
"What about systems programming?"
"Oh, I use C then."


I use OCaml for everything, and for system programming I first write a wrapper in C (using the OCaml-C FFI) and then I'm still writing my program in OCaml.

OCaml (3.00 / 1) (#151)
by mattwb2 on Mon May 13, 2002 at 10:45:13 AM EST

As far as I'm concerned, OCaml+C (maybe Cyclone someday) is all I need. Now, we just need to get more people using it ...

[ Parent ]
Missing poll option (3.00 / 1) (#48)
by vadim on Sun May 12, 2002 at 10:29:55 AM EST

I don't know. I'm sure there is a language that is really nice for low level programming that just didn't get very popular for some reason. I can't even choose anything from the poll, because I don't know enough languages to say I think C is the best. Saying there will never be anything better is foolish, languages are still evolving. And I write VB code (for money fortunately) but would never use it for anything besides a GUI.
--
<@chani> I *cannot* remember names. but I did memorize 214 digits of pi once.
The main thing (4.00 / 1) (#136)
by FredBloggs on Mon May 13, 2002 at 06:47:19 AM EST

is that there is not, and will never be, a `better` language than C, because the question doesnt make sense. You use the best language for the job. Sometimes that will be C, sometimes it will be something else - yes, even VB.

[ Parent ]
C bashing (4.50 / 4) (#52)
by ry2me on Sun May 12, 2002 at 11:44:40 AM EST

Going through the comments and the story, it seems like everyone is in consensus about C being a language that needs replacing.  It makes me wonder how long many of you have actually been using it.

C has obvious inadequacies.  No auto pointer checking/garbage collection and several other, small things.  But any good C programmer knows the pitfalls of his language and can code around them.  In the case of pointers, one can even do some pretty neat tricks (pointer arithmetic can't be done in Java).

Honestly, it seems like many of you are simply bashing C because it's been around longer than most of you have.  I think you ought to take a step back, actually learn the language, and then come back and debate.

I'm not asking for an enumeration of C's pitfalls: I know them well enough.  Furthermore, this isn't directed at anyone in particular.

You've been using it too long. (4.00 / 2) (#66)
by rebelcool on Sun May 12, 2002 at 01:15:07 PM EST

Curmudgeon. heh

Really though, I've been using C long enough to know it well, and other higher languages enough to know that C is lacking in alot of ways.

Yes, its far more readable than assembler. But its still less readable and maintainable than higher languages.

I believe its possible to do better than what it does, and still maintain its low-level performance.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Balance (5.00 / 2) (#132)
by LQ on Mon May 13, 2002 at 04:30:34 AM EST

I coded C for 15 years. I've written code for systems when the choice was only one of C or Fortran. For the last 5 years, I've been pushing C++ for the number crunching, high throughput stuff and Java for all the rest.

Higher level is good for teams. OO is good for big designs, metaphor and reuse. C is just not good enough any more. It's so last century.

[ Parent ]

Whats wrong with C? (4.00 / 3) (#80)
by X3nocide on Sun May 12, 2002 at 04:12:40 PM EST

What is it about C that you find lacking? You're right in that OOP languages really suffer from the object creation and function return costs, but what should you be able to do in C that you can't? Compared to ASM, C is nicely portable, and perhaps a bit more readable.

It seems the only complaint is how C looks. The way I see it, C mirrors whats going on in mathematics much better than asm. Functions look like functions. with names and ()'s and variables. The reason why so many things look so much like C is because a) C looks so much like math and b) C is almost perfect. Everyone has their own complaints about it, be it operator overloading, quirky not signs, single pass compliers, etc. But nobody wants to reinvent the wheel, especially when theres a good chance yours will be less round.

pwnguin.net

Operator Overloading (3.00 / 1) (#97)
by John Milton on Sun May 12, 2002 at 07:02:07 PM EST

Couldn't operator overloading be added on as macros instead of function calls. Same thing without the overhead.


"When we consider that woman are treated as property, it is degrading to women that we should Treat our children as property to be disposed of as we see fit." -Elizabeth Cady Stanton


[ Parent ]
C++ has 'inline' (3.00 / 1) (#99)
by pin0cchio on Sun May 12, 2002 at 07:39:40 PM EST

Couldn't operator overloading be added on as macros instead of function calls. Same thing without the overhead.

If you declare a C++ operator function as inline, you won't suffer much if any function call overhead.


lj65
[ Parent ]
Ahh (4.00 / 1) (#118)
by Hong Kong Phooey on Sun May 12, 2002 at 09:13:56 PM EST

You're looking for job-security?

[ Parent ]
Hmm? (3.00 / 1) (#130)
by John Milton on Mon May 13, 2002 at 12:45:22 AM EST

I don't know what you're saying. If you're saying that it would be kind of pointless to add operator overloading without classes, then I agree with you. I just thought I'd mention the easiest way it could be implemented with no overhead. I changed to CS late in the game so I'm sophmore level. If something I say doesn't make sense just correct me.


"When we consider that woman are treated as property, it is degrading to women that we should Treat our children as property to be disposed of as we see fit." -Elizabeth Cady Stanton


[ Parent ]
Actually (3.00 / 1) (#139)
by Hong Kong Phooey on Mon May 13, 2002 at 08:07:09 AM EST

What I'm saying is that operator overloading leads to hard to understand and maintain code.  IMO it should be avoided.

[ Parent ]
Avoid operator+ even in math library? (4.00 / 1) (#148)
by pin0cchio on Mon May 13, 2002 at 10:30:50 AM EST

What I'm saying is that operator overloading leads to hard to understand and maintain code. IMO it should be avoided.

Unless, of course, you're writing a library to perform specialized arithmetic (such as fixed-point arithmetic, arbitrary precision arithmetic, etc.) where you want + to add, * to multiply, etc.


lj65
[ Parent ]
Operator overloading (4.00 / 1) (#163)
by bored on Mon May 13, 2002 at 12:30:11 PM EST

Its good for non math libs as well. Just don't take over '+' to do strange things. The assigment, comparison etc operators are very useful for normal classes.

[ Parent ]
C doesn't give you carry flag or 32*32=64 muls (5.00 / 2) (#123)
by pin0cchio on Sun May 12, 2002 at 10:36:23 PM EST

but what should you be able to do in C that you can't?

Automatic promotion of additive results. In assembly language, the sum of two 32-bit numbers is automatically promoted to a 33-bit number, with the extra bit in the carry flag available for branching to an overflow handler. C does not have a type-with-one-more-bit-than-int and cannot easily test whether the sum of two numbers will overflow without having to go up to the slow long long int type.

Automatic promotion of multiplicative results. In assembly language, the product of two 32-bit integers is 64-bit, which allows for fixed-point arithmetic. Fixed-point arithmetic is useful especially on low-power-drain architectures that typically don't have dedicated hardware for floating-point arithmetic. In C, on the other hand, the product of two 32-bit integers equals the lowest 32 bits of their product. Yecch.


lj65
[ Parent ]
Portability (4.00 / 2) (#146)
by X3nocide on Mon May 13, 2002 at 10:23:57 AM EST

When writing C we are not guarenteed a carry flag in the computer's architecture. What you are essentially promoting is asm coding. I'm cool with it, I think we should do more work with it in my degree, but basically ASM is not portable.

In addition, you'll have to clarify which architecture you've used that allowed a 64bit multiply from two 32bit operands. Cuz I don't recall mul and imul on x64 doing that. In fact, the should store the result in the accumulator, which is only 32bit. Of course, this could change with newer processers like the itanium and hammer etc, however this merely illustrates my point that ASM is not portable.

pwnguin.net
[ Parent ]

We need something between asm and C (5.00 / 1) (#150)
by pin0cchio on Mon May 13, 2002 at 10:44:20 AM EST

When writing C we are not guarenteed a carry flag in the computer's architecture. What you are essentially promoting is asm coding. I'm cool with it, I think we should do more work with it in my degree, but basically ASM is not portable.

So you're claiming that it's a good thing that a C program has no clean way to detect integer addition overflow? If a language can leverage the asm features common to several architectures (such as a carry flag), it may become more portable than asm. I'm also promoting an asm syntax that looks more like C, where the coder doesn't have to worry about allocating registers.

In addition, you'll have to clarify which architecture you've used that allowed a 64bit multiply from two 32bit operands. Cuz I don't recall mul and imul on x64 doing that.

imull on 386 does that, and an analogous instruction on ARM7TDMI does the same.


lj65
[ Parent ]
So... (none / 0) (#205)
by X3nocide on Mon May 13, 2002 at 08:23:02 PM EST

you want to code in java byte code?

pwnguin.net
[ Parent ]
Java assembly language; 32x32=64 (none / 0) (#261)
by pin0cchio on Fri May 31, 2002 at 02:24:41 AM EST

you want to code in java byte code?

Yes, I know a JVM bytecode assembler exists, but I was thinking more along the lines of a C-like language designed to access features common to common architectures, namely the carry bit and the 32x32=64 multiply.

Actually, now that i think about it, lack of a 32x32=64 multiply is a bug in the compiler, not the language. A good compiler should be able to optimize {int x = foo; int y = bar; return (long long int)x * y;} into a 32x32=64 multiply, but GCC doesn't do that on i386 or ARM7TDMI.


lj65
[ Parent ]
design decisions (4.00 / 1) (#166)
by codemonkey_uk on Mon May 13, 2002 at 12:38:31 PM EST

That is a very good point, for very low level work, but in general from a design point of view you should be avoiding cases where overflow might happen, rather than checking for them, usually by selecting more appropriate data type.

Cases where an overflow might occur, and neads to be checked for are probably hardware specific, and better handled in ASM anyway.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Faster to check for overflow than avoid it (none / 0) (#260)
by pin0cchio on Fri May 31, 2002 at 02:19:20 AM EST

in general from a design point of view you should be avoiding cases where overflow might happen, rather than checking for them

Performance considerations often dictate the opposite.

usually by selecting more appropriate data type.

On a 32-bit architecture, using C99's long long int instead of long int will reduce the performance of compiled code by a factor of four. This is why Info-ZIP's tools only work on archives up to 2 GB rather than 4 GB, because they use the sign bit to detect overflow.


lj65
[ Parent ]
C is good - that is why (4.33 / 3) (#82)
by Nickus on Sun May 12, 2002 at 04:49:30 PM EST

The reason why C is still around is that it works. It doesn't force a lot of assumptions on the programmers and it is quite close to the bare-metal of the computer. It is well tested, works well and a lot of people know. Why do we still have the combustion engine?



Due to budget cuts, light at end of tunnel will be out. --Unknown
what do you want it for? (3.00 / 1) (#83)
by mikpos on Sun May 12, 2002 at 04:52:36 PM EST

If it's just for HLL compiler targeting, what about C--, as developed by Microsoft Research?

If it's for human programming, what's wrong with C? You spend a lot of time talking about how other languages are different from C, but spend no time talking about what's bad about C and how you would fix it.

*gasp* (4.00 / 6) (#86)
by valeko on Sun May 12, 2002 at 05:38:49 PM EST

Maybe, just maybe ... it's because C is a good language. Despite all the abuse its taken for failing to have the sheer goddamn elegance of object-oriented constructs, and the need to stick to crude casts and encapsulation of data in 'primitive' structures, it seems to be one of the most enduring traditions in the entire computing world. In part because it's so ubiquitous, yes, but also because it's just good. Imagine that.

I'm not a "C zealot" or anything, but I despise object-oriented programming (I know C++ can be very nice for GUIs, but I don't do GUIs categorically), and happen to think C is the optimal language for almost anything I do. Web/CGI/parsing/formatting can be done with Perl or PHP to some extent, but for any of the other things I write (i.e. no GUI apps) ... C is king. I don't identify with all these calls for its abolition.


"Hey, what's sanity got going for it anyways?" -- infinitera, on matters of the heart

check out cyclone (4.50 / 4) (#87)
by sesquiped on Sun May 12, 2002 at 06:02:30 PM EST

If you're looking for a cross-platform assembly language, then, as someone else mentioned, you want to be looking at things like C-- or maybe GNU Lightning.

But if you want a language for systems programming and also don't want to give up some of the features of higher level languages, try cyclone. It's based on C, but with stuff added and removed to make it safe, plus a lot of nice high-level-ish features.

To mangle a well-known quote... (4.66 / 6) (#88)
by Erbo on Sun May 12, 2002 at 06:22:45 PM EST

"C is the worst possible systems programming language, except for all the others."

I've heard C described in the past as "the PDP-11 assembler that thinks it's a language." (By that same token, C++ is "the PDP-11 assembler that thinks it's an object system.") Yet that's one of the qualities that keeps people using it; when you write in C, it's relatively easy to "think like the compiler" and figure out how your code is going to be translated into assembly language, and from there spot potential bogosities. You can do that to some extent with C++, but its object system introduces complexities that make that break down after awhile.

When you look at the family of "C-ish" languages out there, you can see just how widespread the C influence has been. Besides C itself, C++, and Objective-C, there's Java (which in many respects is like "C++ done better"), JavaScript (a Java derivative, and hence a C derivative as well), and C# ("Java by any other name..."). In addition, you could make a case for Perl as a C derivative, because it borrows so many things from C; of course, it borrows from a few other sources as well, and is considered sui generis by most observers. And several other languages either translate into C as a "high-level assembly language" and then compile the resulting C, or did so at one time. C++ started this way, as did Eiffel; there's also C-Intercal (for laughs). I'm sure I've left a few languages out here and there, and ridiculously simplified the whole picture, but you get the idea. The list of C-influenced languages is probably only equalled or surpassed by the list of BASIC-influenced languages (from the myriad of early microcomputer BASICs right on up through modern dialects like RealBASIC, Visual Basic, and VBScript).

Anyhow, I do most of my coding in Java these days, but I haven't forgotten my C...you never know when you're going to have to get down and dirty on a first-name basis with the operating system, or even lower. Don't forget, though, languages are like tools; you need to use the right one for the job. For a little one-off job (such as translating a list of user names in comma-separated value format into XML for importing somewhere else), Perl does the job without expending tons of effort.

Eric
--
Electric Minds - virtual community since 1996. http://www.electricminds.org

Perhaps it's the other way 'round (4.55 / 9) (#89)
by Ubiq on Sun May 12, 2002 at 06:23:11 PM EST

Looking at UNIX, I see basically a "C Virtual Machine". It's no wonder that the preferred language for the JVM is Java, or that most people programming Microsoft's CLI will use C# - even though frontends exist to compile other languages to that target. UNIX was written in and for C. As was AmigaOS (except dos.library, which was BCPL). I'm not sure about Windows, but it'll probably be C, too.

What is the preferred language for BeOS? Probably C++, since that's what BeOS itself was written in.



Another example (4.00 / 3) (#98)
by hading on Sun May 12, 2002 at 07:20:40 PM EST

On the Symbolics Lisp Machine all the system software was in Lisp (see this
technical summary
.  Some still believe it to be the best Lisp development environment ever.

[ Parent ]
bring back the lisp machine (4.00 / 3) (#142)
by PigleT on Mon May 13, 2002 at 08:41:30 AM EST

I've already thought of this one - the base layer of most current machines is a C "VM" - OS written in C, existence of libc, all system-provided apps using said libc.

I'm wondering if we can't have something based on one of the Lisps instead...

http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/symbolics.html
~Tim -- We stood in the moonlight and the river flowed
[ Parent ]

C# and CLR (4.50 / 2) (#158)
by ucblockhead on Mon May 13, 2002 at 12:04:10 PM EST

I'm convinced that at least part of the reason most people use C# to code for the CLR is that most of the coders have no clue that you can code for the CLR in any other language.

Windows was written in a mishmash of C and C++. The older stuff was all C, and their old API is C, but they moved to (noncomformant) C++ a ways back.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

-1 because the author is incompetent (2.66 / 12) (#92)
by VZ on Sun May 12, 2002 at 06:35:52 PM EST

> C++ and Objective C are merely extensions of C and not really replacements.

This statement shows that you have absolutely no idea about modern C++ (I won't speak of Obj C which I don't know well enough). Nothing wrong with this, of course, except that you are surely not qualified to discuss evolution of C in this case.

Why? (4.88 / 9) (#100)
by DJBongHit on Sun May 12, 2002 at 08:00:28 PM EST

You go on and on about how there's no alternative to C, and yet you never mention what exactly is wrong with C. It's simple, it's portable, and it's clear. What more do you want out of a low-level systems programming language?

Anyway, like many of the other posters here, I use C for a hell of a lot more than low-level systems programming - when I start to write a program, I make a decision: is it text-processing or CGI? If so, then I use Perl. Otherwise, is it a GUI application? If so, then I use C++ with Qt, or Objective C with Cocoa if targetting MacOS X. If it doesn't fit into either of these 2 categories, I use C.

Why? Because C just doesn't fuck around. When you declare an array, you know that what you just got is an array. No wonky objects hiding behind the array waiting to do garbage collection, no overloaded operators which don't do what they intuitively should do, and so on. You can look at a piece of code and immediately understand what it does (well, usually :) It also gives you complete freedom over what you want your code to be doing. There are no restrictions - however, this also means that if you don't know what you're doing, you can easily do something stupid or dangerous.

If there's a complaint about C that I would consider valid, it would be about its standard library. It really could use a more modern standard library with more functionality which is useful today (perhaps a bit more string processing, networking functionality, and so on). But the language itself can hardly be blamed for that, and god knows there's a nearly infinite supply of C libraries floating around out there that will do damn near anything you want.

~DJBongHit

--
GNU GPL: Free as in herpes.

The Top 10 Ways to get screwed by C (2.50 / 2) (#144)
by Shren on Mon May 13, 2002 at 09:51:01 AM EST

The Top 10 Ways to get screwed by the "C" programming language

C has some issues...

[ Parent ]

gcc -Wall solves many of these problems (5.00 / 3) (#147)
by pin0cchio on Mon May 13, 2002 at 10:24:47 AM EST

gcc -Wall fixes most of the problems your article mentions:
  1. GCC warns about /* in comments.
  2. GCC warns about both assignments in if statements (you can suppress this by wrapping them in another set of parentheses) and always-true conditions.
  3. GCC does not warn about macro problems in general but can warn about a shift bigger than the entire data type.
  4. C99 has the _Bool data type, and so does GCC 3.
  5. GCC warns about hitting the } of a function before returning anything.
  6. Who uses C bitfields? Besides, you won't run into this problem if you're not fread()ing structs. A warning against fread()ing structs is in the manual of almost every modern C compiler.
  7. As long as you're not both writing and reading a value in one line of code, you should be safe. GCC doesn't warn about this, but it could.
  8. GNU Emacs's autoindent feature stops you from making this and similar errors.
  9. GCC warns if a part of a line of code has no effect. (Yes, I know this doesn't handle all of this example's cases, such as side-effects in the arguments.)
  10. It would probably be possible to modify a compiler to warn the user when returning a pointer to something that will immediately fall out of scope. I'm not sure if GCC already does this or not.
  11. Again, this is the read/write in one statement error.
  12. GCC warns about using a local variable before it is initialized.
  13. BUFSIZ? What kind of buffer? I'd name it DMA_BUFFSIZE or something. Even then, you can exclude non-ANSI symbols with gcc -ansi.
  14. C99 has inttypes.h.
  15. Granted. There are bounds-checked C runtime environments, but they should be used for debugging because they involve a performance hit.
  16. Line up numbers with spaces, and you'll have no problems unless you're editing code in a proportional font.

lj65
[ Parent ]
all valid points... (4.00 / 2) (#156)
by Shren on Mon May 13, 2002 at 11:09:21 AM EST

I do quite a bit of C programming myself, and, yes, unless you personally enjoy suffering you should compile with -Wall on. But an utterly paranoid compilier is no substution for good language design. C is often good enough but better is quite possible.

[ Parent ]
C is for.. (4.69 / 13) (#109)
by seeS on Sun May 12, 2002 at 08:18:50 PM EST

... cookies and that's good enough for me.

Sorry couldn't resist..

Now what can be coded with the language C?
Anything can be coded in C!
Let's think of other languages we can use instead of C.
Oh, who cares about the other languages?

C is for coding, that's good enough for me
C is for coding, that's good enough for me
C is for coding, that's good enough for me
Oh, coding, coding, coding is done with C

C is for coding, that's good enough for me
C is for coding, that's good enough for me
C is for coding, that's good enough for me
Oh, coding, coding, coding is done with C

Hey you know what?
Pascal with squiggle brackets in it
Looks like C
C++ with the OO crap out of it
Also looks like C
But they're not developed by K & R
Oh and PHP sometimes looks like C
But you can't compile that, so

C is for coding, that's good enough for me, yeah!
C is for coding, that's good enough for me
C is for coding, that's good enough for me, yeah
Oh, coding, coding, coding is done with C, oh boy!
Oh, coding, coding, coding is done with C!

Or something like that, I'm an engineer not a poet.
--
Where's a policeman when you need one to blame the World Wide Web?

If you can't do it in assembly... (1.00 / 2) (#115)
by gordonjcp on Sun May 12, 2002 at 09:08:07 PM EST

... you don't understand the problem.

Give a man a fish, and he'll eat for a day. Teach a man to fish, and he'll bore you rigid with fishing stories for the rest of your life.


Or... (5.00 / 1) (#128)
by Pseudonym on Sun May 12, 2002 at 11:43:18 PM EST

...you don't understand the machine-specific weirdnesses of your system.

This is not necessarily a bad thing.



sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
[ Parent ]
better (5.00 / 1) (#230)
by kubalaa on Tue May 14, 2002 at 09:01:35 AM EST

If you can't do it in 5 lines of Haskell...

[ Parent ]
What is considered good time?? (2.00 / 1) (#122)
by xtremex on Sun May 12, 2002 at 09:44:49 PM EST

I've been programming for years, and do most of my programming freelance. The main reason is that I feel I am too slow. Let's say you have to program an Instant messaging System for a company. How much time during the day is figuring out how to do it, looking up APIs, and reading thru others code? Or are we supposed to just know htis stuff and code away?? I have to look SOOO much crap up, I feel that if I were working as a code monkey in a corporation, I'd be fired. Do the programmers here bring books with them to work? Have a browser open w/ documentation? or do you just "know" the stuff and type away? Off the top of my head, I couldn't program an P2P file sharing system. I have to read hours of documentatio, network protocols, etc. How many companies expect you to just KNOW this stuff? The reason I'm asking is I'm deciding whether or not I should do this project. I don't know the first thing about it. Does it matter? As long as I read up on it and figure out how to code what they want, is that enough? Or am I expected to know P2P file sharing and just "figure" it out in my own head? thanks.

Look at documentation (4.50 / 2) (#127)
by hardburn on Sun May 12, 2002 at 11:33:34 PM EST

Why memorize stuff when you can look it up? I have a hard time remembering the exact arguments a lot of basic stuff takes, but that's OK, because I can always look it up. My desk is mess with books, and I have 6 virtual desktops in X because I have many, many browsers up with documentation (though thanks to Galeon, I use tab browsing these days). All this so I can grab whatever I need very quickly.

I wouldn't worry about not doing P2P stuff in your head; any P2P network worth using is going to be non-trivial.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
Tabbed Browsing in Mozilla (none / 0) (#175)
by mercutio on Mon May 13, 2002 at 01:30:39 PM EST

You don't need to use Galeon anymore to get tabbed browsing... Mozilla has it now :) Just thought I'd add that...

[ Parent ]
learning curve (4.00 / 2) (#129)
by f00b4r on Mon May 13, 2002 at 12:09:25 AM EST

There is a learning curve involved when starting any new project (and especially for projects that involve technologies that you havent worked with before). Dont let that get you down. Remember if you spend the first week just reading documentation and getting familiar with the concepts, the next week you can spend coding (with the aid of documentation)... Eventually you will find you are getting more effecient at working with the new technology and wont need to look up documentation and examples all the time.

This is normal. Most programmers dont have incredible memories, just the ability to find what they need when they need it.

[ Parent ]
I'm not sure how this is relevent... (none / 0) (#168)
by codemonkey_uk on Mon May 13, 2002 at 12:53:04 PM EST

But to answer your question: Both.

Learn what you can, commit core issues in your chosen domain to memory (ie your language of choices common idioms, your platform of choices core API), and look the rest up as you nead it. You'll be surprised by what google can do.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Not relevant :) (none / 0) (#185)
by xtremex on Mon May 13, 2002 at 03:32:01 PM EST

Actually, my comment had no paring on the parent. The C discussion just got me thinking ;)

[ Parent ]
OT: your sig has a bug (none / 0) (#186)
by jacob on Mon May 13, 2002 at 03:35:00 PM EST

you typed thad/notagoth.org rather than thad.notagoth.org.

Just thought you'd like to know.

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]

OT: Thanks... (none / 0) (#189)
by codemonkey_uk on Mon May 13, 2002 at 04:18:35 PM EST

Fixed now. So when are the PFC4 results going to be done. I'm dying here. ;)
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
OT: tuesday night (5.00 / 1) (#192)
by jacob on Mon May 13, 2002 at 04:43:53 PM EST

I've been asked this three times now since lunch. I guess I'm flattered.

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
Mass response (4.33 / 3) (#131)
by hardburn on Mon May 13, 2002 at 01:12:50 AM EST

There seems to be two kinds of people posting to this article. The first group is pointing out their little gripes about C. The second group is bashing me for not including my little gripes about C.

Both groups miss my point (which might be my fault for not explaining it clearly in the story). I resisted the urge to post specific problems with the language because nothing I could say would be a solid argument for completly replacing the lang. Every problem posted below could be worked around the current language. Some may require lots of rewriting of compilers or standard libs. Others are minor tweaks. But in either case, C would stay pretty much the same from a coding point of view.

Small gripes aside, do you really think C is the very best language the human race will ever create? I can't believe that we hit the paragon of programming within the first 100 years of serious Computer Science.

"C works, so why change it?" This is not a reason; it is an excuse. Completely new ways of abstracting the underlieing assembly could be collecting dust in some university library right now. Such ideas might be ignored simply because "C works, so why change it?"

I don't want to try to improve C--I want go back to the drawing board. The first few attempts will probably fail. After all, K&R went through the "A" and "B" languages before they hit on "C". I don't have any specific ideas on where to go with it. I only have a feeling that a massive area of research is being ignored.

</RANT>


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


BCPL (4.00 / 1) (#133)
by smallstepforman on Mon May 13, 2002 at 04:33:12 AM EST

Before C there was this thing called BCPL. An insider joke is that C++ should have been called P, which I think would have been a better name than C++.

[ Parent ]
P is for Plus (5.00 / 1) (#145)
by pin0cchio on Mon May 13, 2002 at 09:56:12 AM EST

Before C there was this thing called BCPL. An insider joke is that C++ should have been called P

What is the first letter of the second and third words in C++'s name? P. As in "Plus". And what's the first letter in "Java" backwards? L.


lj65
[ Parent ]
Ineffable dissatisfaction? (5.00 / 1) (#176)
by X3nocide on Mon May 13, 2002 at 01:43:50 PM EST

I think we're both a little confused here. First you state that all gripes with C are minor. Then you state that there's no way we could have found the "perfect language" in less than 100 years of computing (which is a asinine error).

If you can't think of any major problems with C, then just maybe there isn't a good reason to go back to the drawing board. If you can't specify a need or "itch" to solve or "scratch," then the end result won't be terribly sound. While I'm not a psychic, or even inuitive, it seems as though you're biting more than you can chew. I think maybe taking a class like "Programming Language Design" to learn a bit of the working body of literature allready out there on the subject. An day of reading can be worth a year of effort. However, its nice to find people that have initiative; you just need to augment that initiative with understanding. Plus, C looked like B for the most part, with a lot more datatypes essentially, which makes an argument for iterative design.

Furthermore, C is not the paragon of computing. C is the near-paragon of portable low level programming. But I think you know that. There is a marked distinction between high level and low level programming. Its an entirely different question to ask about the creation of a pancea of programming languages that resolves both the issues of large scale design and low level quality.

pwnguin.net
[ Parent ]

Thanks (none / 0) (#212)
by hardburn on Mon May 13, 2002 at 11:17:42 PM EST

Thanks for not being a flaming moron like so many other posters around here.

Yes, I think I have bitten off more than I can chew. It isn't the first time :)


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
Old chestnut (3.60 / 5) (#135)
by Herring on Mon May 13, 2002 at 06:46:11 AM EST

I'm surprised nobody has posted this old chestnut:

In an announcement that has stunned the computer industry, Ken Thompson, Dennis Ritchie and Brian Kernighan admitted that the Unix operating system and C programming language created by them is an elaborate prank kept alive for over 20 years.

Speaking at the recent UnixWorld Software Development Forum, Thompson revealed the following:

"In 1969, AT&T had just terminated their work with the GE/Honeywell/AT&T Multics project. Brian and I had started work with an early release of Pascal from Professor Niklaus Wirth's ETH labs in Switzerland and we were impressed with its elegant simplicity and power. Dennis had just finished reading 'Bored of the Rings', a National Lampoon parody of the Tolkien's 'Lord of the Rings' trilogy.

As a lark, we decided to do parodies of the Multics environment and Pascal. Dennis and I were responsible for the operating environment. We looked at Multics and designed the new OS to be as complex and cryptic as possible to maximize casual users' frustration levels, calling it Unix as a parody of Multics, as well as other more risque allusions. We sold the terse command language to novitiates by telling them that it saved them typing.

Then Dennis and Brian worked on a warped version of Pascal, called 'A'. 'A' looked a lot like Pascal, but elevated the notion of the direct memory address (which Wirth had banished) to the central concept of the language. This was Dennis's contribution, and he in fact coined the term "pointer" as an innocuous sounding name for a truly malevolent construct.

Brian must be credited with the idea of having absolutely no standard I/O specification: this ensured that at least 50% of the typical commercial program would have to be re-coded when changing hardware platforms. Brian was also responsible for pitching this lack of I/O as a feature: it allowed us to describe the language as "truly portable".

When we found others were actually creating real programs with A, we removed compulsory type-checking on function arguments. Later, we added a notion we called "casting": this allowed the programmer to treat an integer as though it were a 50kb user-defined structure.

When we found that some programmers were simply not using pointers, we eliminated the ability to pass structures to functions, enforcing their use in even the Simplest applications. We sold this, and many other features, as enhancements to the efficiency of the language. In this way, our prank evolved into B, BCPL, and finally C.

We stopped when we got a clean compile on the following syntax:
for(;P("\n"),R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

At one time, we joked about selling this to the Soviets to set their computer science progress back 20 or more years.

Unfortunately, AT&T and other US corporations actually began using Unix and C. We decided we'd better keep mum, assuming it was just a passing phase.

In fact, it's taken US companies over 20 years to develop enough expertise to generate useful applications using this 1960's technological parody. We are impressed with the tenacity of the general Unix and C programmer. In fact, Brian, Dennis and I have never ourselves attempted to write a commercial application in this environment.

We feel really guilty about the chaos, confusion and truly awesome programming projects that have resulted from our silly prank so long ago."

Dennis Ritchie said: "What really tore it (just when AIDA was catching on), was that Bjarne Stroustrup caught onto our joke. He extended it to further parody, Smalltalk. Like us, he was caught by surprise when nobody laughed.

So he added multiple inheritance, virtual base classes, and later ... templates. All to no avail. So we now have compilers that can compile 100,000 lines per second, but need to process header files for 25 minutes before they get to the meat of "Hello, World".

Major Unix and C vendors and customers, including AT&T, Microsoft, Hewlett-Packard, GTE, NCR, and DEC have refused comment at this time.

Borland International, a leading vendor of object-oriented tools, including the popular Turbo Pascal and Borland C++, stated they had suspected this for a couple of years. In fact, the notoriously late Quattro Pro for Windows was originally written in C++. Philippe Kahn said: "After two and a half years programming, and massive programmer burn-outs, we re-coded the whole thing in Turbo Pascal in three months. I think it's fair to say that Turbo Pascal saved our bacon". Another Borland spokesman said that they would continue to enhance their Pascal products and halt further efforts to develop C/C++.

Professor Wirth of the ETH institute and father of the Pascal, Modula 2 and Oberon structured languages, cryptically said "P.T. Barnum was right." He had no further comments.



Say lol what again motherfucker, say lol what again, I dare you, no I double dare you
dead language (3.50 / 2) (#140)
by tps12 on Mon May 13, 2002 at 08:14:36 AM EST

Okay, since we are reposting, how about this classic Egg Troll piece:

Gentlemen, the time has come for a serious discussion on whether or
not to continue using C for serious programming projects. As I will
explain, I feel that C needs to be retired, much the same way that
Fortran, Cobol and Perl have been. Furthermore, allow me to be so bold
as to suggest a superior replacement to this outdated language.

To give you a little background on this subject, I was recently asked
to develop a client/server project on a Unix platform for a Fortune
500 company. While I've never coded in C before I have coded in VB for
fifteen years, and in Java for over ten, I was stunned to see how
poorly C fared compared to these two, more low-level languages.

C's biggest difficulty, as we all know, is the fact that it is by far
one of the slowest languages in existance, especially when compared to
more modern languages such as Java and C#. Although the reasons for
this are varied, the main reasons seems to be the way C requires a
programmer to laboriously work with chunks of memory.

Requiring a programmer to manipulate blocks of memory is a tedious way
to program. This was satisfactory back in the early days of coding,
but then again, so were punchcards. By using what are called
"pointers" a C programmer is basically requiring the computer to do
three sets of work rather than one. The first time requires the
computer to duplicate whatever is stored in the memory space "pointed
to" by the pointer. The second time requires it to perform the needed
operation on this space. Finally the computer must delete the
duplicate set and set the values of the original accordingly.

Clearly this is a horrendous use of resources and the chief reason why
C is so slow. When one looks at a more modern (and a more serious)
programming language like Java, C# or - even better - Visual Basic
that lacks such archaic coding styles, one will also note a serious
speed increase over C.

So what does this mean for the programming community? I think clearly
that C needs to be abandonded. There are two candidates that would be
a suitable replacement for it. Those are Java and Visual Basic.

Having programmed in both for many years, I believe that VB has the
edge. Not only is it slightly faster than Java its also much easier to
code in. I found C to be confusing, frightening and intimidating with
its non-GUI-based coding style. Furthermore, I like to see the source
code of the projects I work with. Java's source seems to be under the
monopolistic thumb of Sun much the way that GCC is obscured from us by
the marketing people at the FSF. Microsoft's "shared source" under
which Visual Basic is released definately seems to be the most fair
and reasonable of all the licenses in existance, with none of the
harsh restrictions of the BSD license. It also lacks the GPLs
requirement that anything coded with its tools becomes property of the
FSF.

I hope to see a switch from C to VB very soon. I've already spoken
with various luminaries in the C coding world and most are eager to
begin to transition. Having just gotten off the phone with Mr. Alan
Cox, I can say that he is quite thrilled with the speed increases that
will occur when the Linux kernel is completely rewritten in Visual
Basic. Richard Stallman plans to support this, and hopes that the
great Swede himself, Linux Torvaldis, won't object to renaming Linux
to VB/Linux. Although not a C coder himself, I'm told that Slashdot's
very own Admiral Taco will support this on his web site. Finally,
Dennis Ritchie is excited about the switch!

Thank you for your time. Happy coding.

Egg Troll

[ Parent ]

Oh come on... (4.85 / 7) (#141)
by boris on Mon May 13, 2002 at 08:34:18 AM EST

Even more annoying is that new languages often smell like C. They all use '()' to enclose statements, '{}' to enclose code blocks, and they all use '!' for "not".

And why exactly is this annoying? For a programmer with C/C++ background (which includes anyone with some sort of CS education), it eases the transition to these new languages. On the contrary, it would be annoying if the designers of new procedural languages introduced new syntax just for the heck of it. "Curly brackets? It's so passe, they've been around for 30 years!". A different syntax would burden the programmer with unnecessary mental effort (in addition to the effort of learning a new language).

BLISS (3.00 / 1) (#143)
by Bad Harmony on Mon May 13, 2002 at 09:37:28 AM EST

BLISS was widely used for systems programming on DEC's large systems. It never seemed to have escaped to the outside world.

Before the introduction of Ada, there were quite a few obscure systems programming languages used to program embedded systems for defense applications.

54º40' or Fight!

"Because it's there" [nt] (2.00 / 1) (#154)
by panck on Mon May 13, 2002 at 10:54:40 AM EST



earlier conversation on this (4.00 / 2) (#155)
by pb on Mon May 13, 2002 at 10:56:49 AM EST

I talked about C as being suited for systems programming here; basically, you can test to see if a language is a good systems programming language by doing some systems programming in it.  If it's easy to do, then you're ok.  :)
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
It's called C++ (4.12 / 8) (#157)
by avdi on Mon May 13, 2002 at 11:29:28 AM EST

C++ and Objective C are merely extensions of C and not really replacements. In any case, the overhead that is always involved in object-oriented languages means that such languages are often rejected for low level use. Additionally, the inadequacies of C++ have been a matter of much debate that I won't go into here.

That's just FUD. Time and time again it has been proven that C++ forces no overhead over C that the programmer doesn't explicitly ask for. C++ was made to replace C, and it succeeds in that role. You can do everything you can do in C, in the same or fewer lines of code in C++, without sacrificing any efficiency - and then you can judiciously add higher-level C++-only constructs when and if you deem the overhead to be acceptable. Even using C++ as "C only more so", leaving out any use of exceptions, polymorphism, or RTTI, you still get better type safety, better support for generic programming, and shorter SLOC counts than in equivalent C code. And if you think that no one is choosing C++ over C for low level system programming, you should get yourt head out of the sand and take along hard look at the embedded systems field.

Templates in C++, while cumbersome, make truly generic coding possible without sacrificing any runtime efficiency or type-safety - something that is simply impossible in C. C++'s virtual functions enable the coder to incur the overhead of polymorphism only when it is explicitly needed - and even then the overhead is less than that of hand-coded OO approximations in C. C++ gives you compiler-enforced encapsulation, a boon to anyone who has to write code with a large team. C++ gives you simple, reliable namespace separation without the verbosity of having package prefixes on every name. C++ gives you function overloading, enabling you to seperate "what is being done" from "what it's being done to". C++ gives you garaunteed-performance, typesafe data structures - eliminating the need for reinventing the linked-list or B-tree in the name of efficiency. C++ gives you the ability to apply a rich set of algorithms, far beyond anything C offers, to arbitrary data strutures without losing typesafety. All of these things are unavailable in C - and all of them come at no extra cost in overhead compared to C. In short, even working in a restricted subset of C++, it is possible to work at a higher level of abstraction, in language that is closer to that of the problem domain, than C - all without sacrificing an ounce of efficiency.

I do find it depressing that the only two languages deemed useful for system coding are C and C++ - two very similar languages. It would be nice to see languages from a distinctly non-C background with C's resource efficiency and low-level memory-twiddling ability. In particular it would be nice to see a functional language in this role. In the meantime however, we have C++ - and things like the Lambda Library and FC++ give us the ability to do functional programming with all the efficiency and safety of C/C++. Such a thing would not be possible in C.

C++ is bloated, ugly, and takes years to really learn. But that's no excuse for writing it off as a system programming language. It was written expressly to be a "better C than C" - and in both ability and real-world use it has substantially succeeded. Please, do a little more research before dismissing the language as flippantly as you do.

--
Now leave us, and take your fish with you. - Faramir

Systems programming (4.00 / 2) (#161)
by hardburn on Mon May 13, 2002 at 12:19:40 PM EST

While it is true that C++ isn't entirely rejected for low level stuff, I do belive pure C is prefered, except when you absolutely must have ASM. Sometimes this is due to older software that was orginally based on C (*BSD), and sometimes it's just an effort on the part of the developers to keep C++ out (Linux).

As for embedded systems, other comments have talked about C vs. C++ in this field. As one poster noted, it's not just the language itself, but the libraries. Most embedded systems don't even implement the full C library, much less the C++ lib.

Many of the efficencies you gain in C++ were put into C99 anyway. Though I don't belive there is a compiler which completely supports C99, GCC comes close enough.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
What is, and what should be. (none / 0) (#164)
by codemonkey_uk on Mon May 13, 2002 at 12:31:01 PM EST

Pure C may be prefered, but that's more out of ignorance than intelegent choice.

C++ has so much more than C, even without the libraries.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Do you work at an embedded software house? (5.00 / 2) (#170)
by avdi on Mon May 13, 2002 at 01:07:13 PM EST

I do. Nobody talks about C anymore, except in maintaining legacy code.   If a C module needs to be rewritten, it's rewritten in C++. Industry literature doesn't talk about C anymore.  VxWorks, which has a huge share of the embedded OS market, supports C++ as it's primary language.  The impression I get from the rest of the company (one of the largest defense contractors on earth) is that nobody else in the company is using C for anything new and signifigant anymore.  It's either C++ or, increasingly rarely, Ada.  For non-realtime stuff Java is gaining steam.


--
Now leave us, and take your fish with you. - Faramir
[ Parent ]
C99? (none / 0) (#171)
by avdi on Mon May 13, 2002 at 01:09:29 PM EST

"Many of the efficencies you gain in C++ were put into C99 anyway."

Name one.

--
Now leave us, and take your fish with you. - Faramir
[ Parent ]

inline functions (nt) (3.00 / 1) (#172)
by hardburn on Mon May 13, 2002 at 01:10:14 PM EST


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
wrong, try again (none / 0) (#177)
by avdi on Mon May 13, 2002 at 01:54:04 PM EST

I said nothing about inline functions. In fact, I said nothing about efficiencies that C++ adds to C - all I mentioned were areas where C++ adds safety, generality, abstration, or organization without sacrificing C's efficiency. C99 doesn't add anything signifigant in any of these categories, AFAIK.

--
Now leave us, and take your fish with you. - Faramir
[ Parent ]
I said efficenicies (4.00 / 1) (#178)
by hardburn on Mon May 13, 2002 at 02:14:40 PM EST

"Many of the efficencies you gain in C++ were put into C99 anyway."

Name one.

I said efficencies. You asked for one. I gave you one. Now you're going off about safety, generality, abstration, and organization, none of which (directly) effect efficiancy.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
My mistake; who were you responding to? (none / 0) (#181)
by avdi on Mon May 13, 2002 at 02:27:35 PM EST

I assumed, since the comment of mine you were responding to made no mention of efficiencies that C++ adds to C, that you were using "efficiencies" to refer to one of the gains I had been talking about.

I apologize for mistaking the thrust of your statement.  I am now lead to believe that you didn't even read my original comment, and were merely responding to a strawman.

Let me reiterate then:  I make no statement that C++ is more efficient than C.  Merely equivalent, while adding other advantages.  If you were arguing with someone who thought that C++ was more efficient than C, that person was not me.

--
Now leave us, and take your fish with you. - Faramir
[ Parent ]

You're so clueless (1.14 / 7) (#179)
by The Eradicator on Mon May 13, 2002 at 02:15:37 PM EST



[ Parent ]
Are you so sure? (none / 0) (#241)
by kostya on Tue May 14, 2002 at 11:42:35 AM EST

Back in 1998, I did a quick consult for as huge electronics and embedded chip maker in MA, US and they used C++ exclusively--across the entire organization (including their European units). I mentioned that I thought most embedded houses used C because it was smaller, but they told me that actually most people use C++ these days.

That was in 1998. It is now 4 years later, and I bet even more people use C++ now for embedded work. Hell, my CUJ is just chock full of embedded C++ tool chains. There are tons of products--there must be some market to support them.

The fact is that most Linux/Free UNIX hackers use C because that is what their OS is mostly in. But most commercial software houses use C++ (a significant majority). Add to that most Windows software being in C++ and you get even more developers using C++. Free UNIX OSes may be the last bastion of C preference left.



----
Veritas otium parit. --Terence
[ Parent ]
Et tu Compiler? (5.00 / 4) (#162)
by kostya on Mon May 13, 2002 at 12:20:33 PM EST

I agree wholeheartedly. Most people who bad mouth C++ say things like this:
    Well I was forced to use C++ back [insert amount of years, usually five] years ago and I hated every minute of it. C++ was bloated, buggy, etc., etc., etc.
I would give these people some points while also telling them that they are working on horrible wrong information. Yes, C++ used to have all sorts of problems--but it had more to do with the compiler and horrible implementations than the language. But that was then, and this is now. C++ is finally mature, and the latest standard has helped tremendously. More people are using C++ for systems and embedded work, and as a result better compilers and implementations have come to market.

I would say to many C++ and OOP naysayers that you may have been right in 1995, but I think 90% of your reasons no longer hold true. Of course, if you are still using VC++ 6.0, yes, you have problems. Go get the new standard and get yourself a new compiler. It really is better. It is not like you remembered.

But let's face it: Geeks love to bitch and refuse to change. Until an idea or technique is their own, it's crap. When it is, then it is the best thing ever thought up.



----
Veritas otium parit. --Terence
[ Parent ]
Than what the hell am I? (none / 0) (#169)
by avdi on Mon May 13, 2002 at 12:55:23 PM EST

But let's face it: Geeks love to bitch and refuse to change. Until an idea or technique is their own, it's crap. When it is, then it is the best thing ever thought up.
Odd, I love discovering new ways of doing things, learning new languages, and generally standing on the shoulders of the talles giants I can find. And all this time I thought I was a geek... I wonder what I really am?

Sadly, you seem to be right... geeks (or at least the sort of folk that hang around K5 and /. calling themselves geeks) have a higher incidence of willful ignorance and NIH syndrome than you'd expect to find in a room full of PHBs. Sad, really... they'd all rather bellow about their favorite language/paradigm/technology than practice that voracious curiousity that made them geeks in the first place.

That's right, "hacker" is what I am! ... oh wait, no, that term's bee co-opted too. Damn it! ...what the hell am I?

--
Now leave us, and take your fish with you. - Faramir
[ Parent ]

How does implementation fix desgin? (4.66 / 3) (#173)
by hardburn on Mon May 13, 2002 at 01:12:36 PM EST

. . . it had more to do with the compiler and horrible implementations than the language.

How does having a better compiler fix language bloat? Having a better implementation of a bloated design won't help as much as having a clean design in the first place.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
One man's bloat (none / 0) (#240)
by kostya on Tue May 14, 2002 at 11:34:53 AM EST

We'd have to first be specific about what you mean by bloat. To put it simply, if you mean the OOP stuff, then we can stop talking.

I'm not going to get into an argument with someone who is convinced that OOP is unnecessary bloat. If that is your position, then you are welcome to it, but I'm not going to argue any further about it.

If that's not what you mean (i.e. you feel something else is bloated or broken), we could discuss that. Could you be specific? And to be clear--have you used C++ recently? On what kind of project? Of what size and for how lone?

As for how implementation can solve bloat or how the improved compiler designs can solve bloat, surely you know what I am referring to. We can clean up memory usage, make code more efficient, have the compiler generate better object code, etc. All of these have tremendous impact on performance and bloat. Hell, that's why we have jobs--to take designs and implement them in the most efficient way. My current project is a crtap design, but the worst part is the implementation. Sure they didn't know how to design the system, but they knew less about implementing it properly. If I just scrapped their *.cc files and rewrote them, I could get a performance increase of at least 3x.

But in large projects (this one has over 30 library packages and over 260 scripts), it isn't really performance that you are worried about. It is design and maintainability. Good design that allows easy maintenance is a must. C++ provides many great features to make this easy to implement, OOP being one of the key ones. Yes, it is just a paradigm, but it is an extremely useful one to those who grok it.



----
Veritas otium parit. --Terence
[ Parent ]
No quarles with OOP (none / 0) (#257)
by hardburn on Wed May 15, 2002 at 02:02:38 PM EST

I use Java a lot, so I have no buissness saying OOP is bloat. OTOH, OOP is bloat when you need absolute speed, in which case you are probably using hand-optimized ASM anyway.

My main problem with bloat in C++ is that its standard library reimplements things that were done just fine in pure C (like cout/cin), albeit without OOP purity. Not content to stop there, many programmers have reimplemented whatever the standard libs forgot. Is not code reuse a big idea in OOP?

I started using Java over C++ about three years ago because I think it is a much cleaner design.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
Of course, there's always Pascal. (nt) (none / 0) (#195)
by beergut on Mon May 13, 2002 at 05:50:48 PM EST


i don't see any nanorobots or jet engines or laser holography or orbiting death satellites.
i just see some orangutan throwing code-feces at a computer screen.

-- indubitable
[ Parent ]

VectorC (4.00 / 3) (#167)
by codemonkey_uk on Mon May 13, 2002 at 12:44:08 PM EST

Its probably not what your looking for, but its probably still worth mentioning that CodePlay started developing a low level C-like lanaguge called VectorC, which has been making an impression in the games development industry for its ability to generate very tight code for difficult architectures (ie PS2 VU).

Interestingly they have now moved their focus, and are now pushing VectorC as more of a shit-hot standard compliant C/C++ compiler (with extentions), than as a new language intself.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell

Codemonkeys is still around? (3.00 / 1) (#190)
by X3nocide on Mon May 13, 2002 at 04:37:11 PM EST

Maybe I'm wrong, but aren't they the people who did like Univesal soldier for gbc? And all it really was was Turrican with a Universal soldier liscence slapped on it? Or maybe that was some other group...

pwnguin.net
[ Parent ]
Nothing to do with me... (none / 0) (#225)
by codemonkey_uk on Tue May 14, 2002 at 04:51:50 AM EST


---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
The truth about VectorC (5.00 / 2) (#226)
by Lurkah on Tue May 14, 2002 at 05:08:25 AM EST

CodePlay started developing a low level C-like lanaguge called VectorC

Actually that's not true. Our compiler is called VectorC, it was always a standard C compiler. It does have some additional language features such as the C99 restrict keywords for aiding vectorization. Eg. The compiler tells you why it couldn't do something and suggests that if you add the appropriate statement it will be able to vectorize.

very tight code for difficult architectures (ie PS2 VU)

That's actually a VLIW/SIMD co-processor so much more than straight C isn't appropriate. We do some relevant bits of C++ though, such as operator overloading on vector classes which makes very neat readable code while retaining performance.

Interestingly they have now moved their focus, and are now pushing VectorC as more of a shit-hot standard compliant C/C++ compiler (with extentions)

That was always the long-term goal. VectorC was originally concieved when C was the dominent language in game development for performance reasons. We've spent the last year working on C++ because game development has adopted it wholesale.

Mat Bettinson - Codeplay Ltd.

[ Parent ]

Standards are goood. (4.66 / 3) (#180)
by joshjs on Mon May 13, 2002 at 02:17:56 PM EST

Even more annoying is that new languages often smell like C. They all use '()' to enclose statements, '{}' to enclose code blocks, and they all use '!' for "not".

There is nothing wrong with this, really. I think it is a good idea. If these things were completely different for each and every language out there, people would be less likely to want to learn new languages, and it would be harder for them to do so.

About {} (none / 0) (#235)
by Betcour on Tue May 14, 2002 at 10:55:15 AM EST

I think {} for code blocks are an horrible things. When you get 15 } at the end of a function, not knowing which one close what, it's a mess to read. A good language should have real words for block quotes and preferably different ones depending if the structure (begin...endif or for..endfor or something like that)

[ Parent ]
ick! (none / 0) (#237)
by jacob on Tue May 14, 2002 at 11:03:27 AM EST

Just aesthetically, I have to disagree. Editors do a fine job of indicating which delimiter closes which block, and "endfor, endif, endwhile" gets really wordy and annoying to type.

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
Editors... (none / 0) (#242)
by Betcour on Tue May 14, 2002 at 12:00:30 PM EST

Well when you have several level of nested blocks that span over 2 or 3 screens, the indentation at the end doesn't add anything to clear things up : all you see is a bunch of } at different alignements. You just have to scroll up and try to figure out which } close what (I personnaly add some comments to help here). And since } is not a very big letter either it's not very readable (compared to a full word like "end")

[ Parent ]
Bad code... (none / 0) (#246)
by kentm on Tue May 14, 2002 at 02:20:10 PM EST

But if you have several levels of nested blocks spanning 2 or more screens, it sounds like you have bad code, rather than a problem with C.

[ Parent ]
I expected that remark (none / 0) (#256)
by Betcour on Wed May 15, 2002 at 03:52:23 AM EST

The problem is that sometimes it doesn't make sense to cut everything into functions - the code I'm talking about is parsing XML and passing sub-divisions of the XML to sub-function would makes things even messier (lots of oddly named function that are never reused and that need to do useless argument jogling)

[ Parent ]
Re: About {} (none / 0) (#243)
by Ruidh on Tue May 14, 2002 at 01:03:51 PM EST

I think {} for code blocks are an horrible things. When you get 15 } at the end of a function, not knowing which one close what, it's a mess to read.

There is where strict adherence to an indentation convention is a Good Thing (TM). It dosn't matter much *which* standard, as long as it's used consistantly. Additionally, one can add, <gasp!>, *comments* if the bottom of all of these nested blocks come together. Even if you are reading someone else's code, you can add comments to document what you've discovered.

C remains popular because it works. Like any good tool, it can create beautiful things in the hands of a master and can be a danger to yourself and to others in the hands of the inexperienced. So that they can't be misused is a poor excuse for having poor tools.


"Laissez-faire is a French term commonly interpreted by Conservatives to mean 'lazy fairy,' which is the belief that if governments are lazy enough, the Good Fairy will come down from heaven and do all their work for them."
[ Parent ]
The law of migration to middleware (3.80 / 5) (#182)
by Alan Crowe on Mon May 13, 2002 at 03:01:39 PM EST

Here is the traditional paradigm of computer use:

A person, called a programmer, prepares a file, called a
program, using a text editor.

A pre-existing program, called a compiler, converts the
programmer's new program into an executable file.

The user, often a different person from the programmer,
thinks of the exectuable as being the program he uses.  The
user prepares a file, called data, using a text editor.
Then he uses the program that the programmer has provided
for him, to process his data.

In the traditional paradigm the input files to computer
programs are prepared by humans using text editors. This
applies both to the data, which is processed by programs
written specially to process them, and to the source files
from which those programs have been compiled.

Scratch beneath the surface and you find middle-ware. The
compile does not actually produce an executable, it writes
assembler code, which is converted to an executable by an
assembler. The word processing program does not know about
all the printers on the market. It writes out its data in a
page description language such as PostScript. The PostScript
interpreter generates the file of commands for the
printer. The browser reads HTML files. Some persons type
HTML using a text editor, but others use a web authoring
package. In the latter case HTML is the output language of
the authoring package in addition to being the input
language of the browser. Assembler, PostScript, and HTML are
examples of middleware.

Once upon a time programmers actually wrote assembler code
themselves. The syntax of the assembler has various
elaborations intended to help the human preparing input to
the program himself. It might have been better to design the
syntax to suit the human preparing the source files for the
program that generates the assembler code. The emphasis
would have been rather different. Working at one remove,
writing a program that generates files in a particular
format, one wants the format to be simple and consistant,
and one cares very little if it is tedious and repetitive to
write, because it is the computer than will be writing it.

The law of migration to middleware is that most programs
intended to process files prepared by humans using text
editors end up processing files written by other programs
earlier in the processing chain. This has four implications
for file syntax.

1)The files need to be readable by humans. When things go
  wrong, someone has to look inside the intermediate files
  to determine if things went wrong earlier or later in the
  processing chain

2)There is little benefit from syntactic complications aimed
  at letting humans abbreviate the input. One will only be
  typing short test cases in manually.

3)There is a cost from syntactic complications. Since humans
  only look at the files occassionally they cannot be
  expected to remember the subtleties of the syntax. Any
  cleverness means that the person trying to track down a
  problem has to spend hours relearning a syntax he only
  uses when things go wrong.

4)There is another cost from syntactic complications. The
  program that reads the input is much more complicated, but
  all for nothing. The program that writes the input
  produces `plain vanilla' files, that make no use of the
  features included for human convenience.

When the C programming language was designed, it was natural
to want a high level assembler, with a view to using it
directly as a programming language, sitting at a keyboard,
typing it in.

Starting with a blank sheet today, designing an alternative
high level assembler to replace C, the biggest change is
that one is designing middle-ware. I would look to LISP for
inspiration. Programmers writing in Common Lisp today
usually write part of their code indirectly, as
macro-expansions that expand into the Lisp code that gets
compiled. Thus Common Lisp has partly migrated to being
middle-ware, with source that has been written mechanically,
that is, it is the output of other programs. This is an
important point, but one that is easy to overlook. The
peculiar feature of Common Lisp that makes one overlook this,
is that, having learnt the base language, one does not
have to learn a macro-language layered on top of it. Lisp
program source is a textual representation of Lisp data
structures, which helps greatly when it comes to writing one
Lisp program to automatically write another less
sophisticated program. Consequently a Lisp source file looks
like it is just Lisp, even when an important part of it is
code that writes Lisp, and might thus be thought of as
meta-lisp, and be expected to appear different in the source file.

My radical suggestion is that New-C should have a Lisp-like
syntax, and have Lisp or Scheme as its macro-language. The
most important goal of New-C should be an active acceptance
of its place as middle-ware. Programs such as YACC and Lex,
which emit C code, are the inspiration here. They point
a way higher programmer productivity, but they point to a
path little trodden. Writing C code that writes C code is
hard. It could be very much easier if New-C was designed to
make it so.

Two reasons (3.66 / 6) (#184)
by trhurler on Mon May 13, 2002 at 03:30:40 PM EST

First of all, C serves the same purpose as undergrad weedout courses in college: it helps to prevent utter fucking morons from messing with things they don't begin to comprehend. By the time you're good enough to write a replacement for C, you don't want to do so, because C is a perfectly servicable tool once you know how it works. (Sort of like vi, too. If you can't handle vi(or emacs, but vi is my choice,) and have to go use pico or some shit like that, then very clearly you aren't going to make it as a programmer anyway because you're stupid. You don't have to like them, but if you can't handle them, you've already lost.)

Second, designing a good systems programming language that is portable, generally useful, makes good use of hardware, and yet is expressive enough to be worth learning is unbelievably hard. Lots of people have tried, and so far the best result ever is C. This may have something to do with the fact that C was born in a place heavy with some of the smartest people in the world, but it is also partly sheer luck. In a sense, your question is like asking why nobody has built bridges across the oceans; were it practical to do so, we would.

--
'God dammit, your posts make me hard.' --LilDebbie

Problem with first reason (none / 0) (#259)
by bodrius on Sat May 18, 2002 at 04:15:09 AM EST

It puts the difficulty where it should not be (much like the case with vi/emacs/whatever).

Sure, a reasonably intelligent person should be able to handle the shortcomings/difficulties/eccentricities of C or any decent language.

But why should they have to? Isn't the point of a PROGRAMMING LANGUAGE to let the programmer concentrate on the problem, rather than prove how 1337 he or she is? Why did we get out of assembly in the first place place? Just come up with a set of mnemonics to use as universal assembly and eliminate those pesky constructs such as for/while/do loops, structures, data types, etc.

Anyone who can't handle that shouldn't be doing system programming in the first place, so why make their life easier? Could it be, perhaps, because making their life unnecessarily difficult is idiotic?

Weed out classes in undergrad courses are actually that idiotic. They waste the student time and resources in order to create an artificial difficulty that hides the mediocre level of the rest of the courses. If you need to have weed out courses, then you're solving the wrong problem: your faculty is not challenging the students at all in any meaningful way.

Caclulus, for example, is not a weed out course, nor is your typical Programming I course, because they are integral to the problem you're trying to solve: getting an education in your particular career. They only become "weed out" courses when they impose artificial difficulties that have nothing to do with the real material (such as forcing you to code in C a particular problem because it's too easy to solve it in other languages you have been using through the course).

That's assuming by "weed out" course you mean the other kind of barrier you compare C with: text editors.

I use vim to quickly edit my code and recompile whenever I'm not in GUI-mode or I'm working through SSH/telnet/whatever.

Do I feel I'm a better programmer because of that? No, it just means I had to spend some time learning vim commands in order to be able to code in the shell. Time that could have been spent learning a new programming language, library, technology or (god-forbid!) actually coding. Memory slots that I have to spend in keystroke combinations that have almost nothing to do with what I'm actually doing. It's not a lot of time and effort, but then, by your argument, it only means it should have been more challenging.

If someone can do the work more efficiently with pico than vim, then I'm afraid the stupider person is me. I learned vim to use it, not to prove something to myself or someone else. I once started to learn emacs in order to prove something, and quickly proved I was losing my time: it wasn't incredibly hard, it was simply not worth the investment, as I wasn't going to do anything with it dramatically better than I would with another editor.

I like vim and all, but I'll quickly choose "simpler" text editors or IDEs that offer the features I find actually useful if it makes my life easier, and it often does. Most people I know who can do wonders with vim/emacs learned to use those tools first, and once the investment is made they're great. But if you don't really have to, what's the point?

C has difficulties that are integral to systems programming, and these will be present in any low-level language. If it has difficulties that are not tied to the goal at hand, it only makes sense to remove them. If you're trusting knowledge of C to be the measurement of whom you're going to hire or work with as a system programmer, then you have bigger problems to deal with.
Freedom is the freedom to say 2+2=4, everything else follows...
[ Parent ]

Vault (4.00 / 3) (#197)
by kimbly on Mon May 13, 2002 at 06:08:57 PM EST

Vault is a Microsoft research project to provide a safe version of the C language, with all the low-level nitty gritty, but harder to core dump. Unfortunately I don't think they've released it yet, and it may be being neglected. But the ideas are very good (e.g. having a separate type category for potentially-null pointers, which require a check before dereferencing).

Microsoft propoganda (4.00 / 4) (#202)
by Skywise on Mon May 13, 2002 at 06:57:14 PM EST

Oh puh-LEEAZE.  Just because they throw the adjective "safe" in front of a language doesn't make it "safe".  There are many, many more ways of causing the code to fault the stack than buffer overruns and null pointers.  Just by disallowing their (very valid) use in programming does not make code "safe".  Java handles null-pointer exceptions without corrupting the system either, but I don't think you'll see Microsoft saying a thing about that...

[ Parent ]
Musings (4.66 / 3) (#198)
by epepke on Mon May 13, 2002 at 06:35:20 PM EST

First of all, I think that the first step in thinking about a better language would be to figure out the shortcomings of C. This whole thread is about C as a low-level language so, religious conflicts about the value of high- verses low-level notwithstanding, how low can you go? Here are some flaws with C as I see them:

  1. Lack of control over rounding
    For some tight code in a 3-D renderer, I once had to implement an ASM function just to get the correct rounding fast enough. Since the capability was in the hardware, it was a shame not to be able to use it directly in C, which otherwise did a very good job.
  2. No good support for weird primitive types
    I'm talking about things like vectors, rotation matrices, quaternions, complex numbers, and more exotic structures that are common in hardware on special-purpose devices like graphics hardware.
  3. Poor thread control
    This is an area where Java is really nice, being able to declare something synchronized and have the semaphores be handled right.
  4. No support for vector hardware
    Vector machines are out of style, but I think they might come back in style if there were the software tools to deal with them. Even something as relatively simple as the Itanium suffers from a lack of tools. There have been some OK vector FORTRANs, but FORTRAN is FORTRAN.
  5. No support for SIMD architectures
    Essentially, you have to roll your own with conventions and libraries.
  6. Mediocre non-local exits
    OK, setjmp and longjmp do sort of work, but only in the context of C's stack-based model. There really should be a way of doing something similar to call-with-current-continuation in scheme.

What I would like to see is a language heavily based on smart macros and operator overloading with Java-like synchronization built in. The idea is that it would be possible to produce an aware macro or operator that could implement some specific feature of an architecture but also be able to fall back onto elementary operations. The macros would essentially provide an extra level of syntax and could be analyzed by the compiler during optimization. I'd also like to see tighter and more visible integration between variables and registers, such as that once provided in Lightspeed C. Perhaps some of the ideas, if not the actual syntax, of LISP could be used here: that one presents an executable structure to the compiler for analysis rather than defining execution step by step. I'd like to see the macros detailed enough so that one can include cost information within them.


The truth may be out there, but lies are inside your head.--Terry Pratchett


Musings from a system programming perspective. (4.00 / 2) (#222)
by Lord of the Wasteland on Tue May 14, 2002 at 02:03:37 AM EST

1. Lack of control over rounding

In your discussion of this I think you actually exposed a strength of C--it's easy to hook to assembly. Many low-level applications don't need good rounding control, and it seems like more of a library feature than a language feature.

2,4,5. No good support for weird primative types,vectors, and SIMD

This is a weakness of C, and I think the only thing that it likely to provide enough motivation for a standard replacement. C is very hard to vectorize well, and vector processors are becoming an important market segment. SIMD is slightly less useful, Moore's law keeps crushing it. Assymetric multi-processing seems to me to be the way to go, and that implies multi instruction threads.

3. Poor thread-control

It's really hard to do thread control in an OS independant way. Java does thread control since it imposes a machine on you

I'm going to ignore the issue of non-local exits since it seems to touch off religious wars.

[ Parent ]

Reply (none / 0) (#245)
by epepke on Tue May 14, 2002 at 01:39:30 PM EST

In your discussion of this I think you actually exposed a strength of C--it's easy to hook to assembly.

True, however, I find that there's very little consistency between applications. What really cheesed my wiz was that there was no way that I could make the assembly function in this case an inline function, even under the C++ compiler. As I mentioned, I really liked the way that Lightspeed C handled assembly: you could have assembly blocks within a function and use the names of register variables as if they were registers. Since about 90% of the time I find the only real reason to go into assembly is for a couple of instructions, this is great. For that size job, it's not too hard to generate a preprocessor macro that can fall back onto plain code.

Many low-level applications don't need good rounding control, and it seems like more of a library feature than a language feature.

The thing is, though, that when you do need it, you really need it, and you usually need it in tight code.

C is very hard to vectorize well, and vector processors are becoming an important market segment.

See, I've never been much of a fan of vectorization. Back in the mid-1980's, I worked with vector machines like the Cyber 205, ETA-10, and Cray Y/MP a lot. It always seemed to me much better to have vector constructs in the language and generate the loops on scalar machines than to have the loops and generate vectors. Besides, the general "for" loop makes that hard in C anyway. I think something like Perl's constructs for arrays or even APL-like ideas would be good (in a compiler rather than an interpreter, of course). Something like a foreach loop could be handily vectorized or parallelized as long as it were hygenic.

SIMD is slightly less useful, Moore's law keeps crushing it.

It does seem that way. However, I think a good SIMD model would lead to spinoffs for a lot of special-purpose hardware.

It's really hard to do thread control in an OS independant way. Java does thread control since it imposes a machine on you

That's true; the JAVA VM makes it a lot easier because it controls what operations are atomic, but it also uses the multiprocessing capabilities of the underlying OS. I've never considered the fact that something is hard or even impossible as a good reason not to do it. Furthermore, the history of processors doesn't just go one way--hardware designers take their cues from software as much as the other way around.


The truth may be out there, but lies are inside your head.--Terry Pratchett


[ Parent ]
vectorization (none / 0) (#247)
by Cal Bunny on Tue May 14, 2002 at 03:28:21 PM EST

If it is done properly in the language it is unbeatable by scalar operations.  APL has a great history of crushing scalar languages.

You should not have loops generating vector operations.  You should rarely have any explicit loops in a language.  Bulk data and collection based languages that over means of describing iteration perform better, have less code, and have much more understandable code.

SIMD would be very useful if people actually used languages that could be vectorized properly.

I just wish there there was a language like that.  Do you know of one?

^cb^

[ Reply to This ]
[ Parent ]

Vectorization (none / 0) (#251)
by epepke on Tue May 14, 2002 at 04:21:03 PM EST

You should not have loops generating vector operations.

I agree, but back at the Supercomputer Computations Research Institute, that's what we used the word "vectorization" to mean. Using vector constructs in languages was just using vector constructs; it wasn't vectorization.

I am actually a fan of APL and started a proposal to write an ETA-10 version, but it never got funded.


The truth may be out there, but lies are inside your head.--Terry Pratchett


[ Parent ]
Ada anyone? (4.66 / 3) (#200)
by avdi on Mon May 13, 2002 at 06:47:48 PM EST

I'm surprised that no one has spoken up for Ada, one of the few languages that seems to be considered an alternative to C and C++ for embedded work.  I'm certainly not going to, mostly because I don't know a lot about it.  But isn't anyone going to say a few words about it?

--
Now leave us, and take your fish with you. - Faramir
Ada... (5.00 / 3) (#224)
by schlouse on Tue May 14, 2002 at 04:24:38 AM EST


I think you're right; somebody does need to say something about Ada. In some ways Ada is very unglamourous and unsexy. But I guess that depends on what you think is glamourous and sexy in the first place. Nothing like just finishing a project with a couple less-than-perfect coworkers and going home knowing you're in for a shitty next month chasing heisenbugs. On the other hand, what's it like going home after a long project with a couple less-than-perfect coworkers and knowing that your design and implementation has been formally proven correct? I'm not claiming formal verification useful in all circumstances, but it's an interesting thought for sure. Seems to me to be the kind of thing you might want to have in your bag of tricks. Perhaps someone here with experience in the area can comment.

I've been looking into some of the benefits and information associated with ada95 for a while now. I think I'm eventually going to take the plunge, but there's a couple of things I plan on doing first.

In all fairness, there is also some interesting things going on with C and C++: embedded C++ and MISRA-C

Mark S.

[ Parent ]

I'm only marginally knowledgeable about Ada, (3.33 / 3) (#244)
by Wolf Keeper on Tue May 14, 2002 at 01:36:41 PM EST

but I don't think it solves the problem at hand. I've read that it supports everything C++ has. I learned it as my second CS language, so to me the code is much easier to read than C or C++. But I think it has as much overhead, as an object oriented and strongly typed language, as C++. That precludes it from handling many of the low level applications that the article refers to. If someone else can correct any of my errors, feel free.

[ Parent ]
CYCLONE! (4.00 / 3) (#201)
by washort on Mon May 13, 2002 at 06:56:25 PM EST

Check out AT&T's effort to produce a safer C:

it uses the same data representation and calling convention as C, provides convenient region-based manual memory management, but also gives very good pointer control (automatic bounds checking on arrays, automatic null checks before pointer dereference), an advanced type system (parametric polymorphism), exceptions, and other stuff that makes segfaults just about impossible, without the gratuitous breakages of C++.

I don't get it... (5.00 / 1) (#253)
by Skywise on Tue May 14, 2002 at 05:18:11 PM EST

The REASON you use a low-level language is because you want to wring every cycle of speed out of the processor.  That means you also have to be aware of every action the program is performing.

Why write a low-level language which defeats that purpose so that your code will be "safe" from segfaults!?!

If you want that... use a high-level language.

And I'll say it AGAIN... just because your language now stops ONE instance of overrunning a buffer doesn't mean that your program is SAFE from segfaults.

[ Parent ]

Compiler design (4.00 / 4) (#207)
by awgsilyari on Mon May 13, 2002 at 10:42:11 PM EST

C has lived on because it's easy to compile. Many people have posted good comments on this article about C's shortcomings, but the fact remains: well-designed C code, passed through a good compiler, translates into F*CKING GOOD machine code.

As someone who's designed a number of interpretters and compilers, I can speak to this: C is one of the easiest languages to compile. Its syntax leads naturally to effortless compilation -- in fact, is was designed with this in mind. Remember that C was invented back when machines rarely had more than 16 kilobytes of RAM, and it was vital that the compiler be able to compile large source programs. This led to the requirements that all variables be declared at the top of the function, etc. One-pass compilation was God, and C was the leader of the pack.

Objects, garbage collection, and non-pointerism are modern (and WONDERFUL) concepts, but they deserve to live in application land. Systems programmers have, and I'm pretty sure always will, choose a low-level language when the job simply needs to GET DONE. Programmers often have a holier-than-thou attitude, but in fact, most programmers are simply incapable of doing software engineering at the systems level. Leave the systems people alone. They'll do their thing, and you'll do yours. Language bigotry is idiotic.

That is all.

--------
Please direct SPAM to john@neuralnw.com

No. (4.00 / 1) (#236)
by StrontiumDog on Tue May 14, 2002 at 11:01:38 AM EST

As someone who's designed a number of interpretters and compilers, I can speak to this: C is one of the easiest languages to compile.

C is not an easy language to write a compiler for, and if you have designed a number of compilers and interpreters then you should know this.

Remember that C was invented back when machines rarely had more than 16 kilobytes of RAM

Young man, I have seen Basic, Forth, and even Logo interpreters that fit in 5kb RAM. C was a big-iron language back in the day.

C is a reasonable, but far from ideal portable assembler; that's why systems programmers cherish the inline assembler opportunities ubiquitous in the C world.

[ Parent ]

640k (none / 0) (#239)
by ucblockhead on Tue May 14, 2002 at 11:14:26 AM EST

PCs had BASIC interpreters way back when 48k was standard. It wasn't until they started hitting 640k that C compilers became the norm. Pascal was on the PC long before C. I still fondly remember running UCSD Pascal on my 64k Apple ][.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
64k... (none / 0) (#248)
by Skywise on Tue May 14, 2002 at 03:50:44 PM EST

PC's had basic interpreters because of a thing called the "tape drive".  Because of the limited space, there wasn't room to generate a target executable, and it was impossible to do virtual loading from a tape drive.

Pascal achieved status first because it had been around for almost 20 years when C started gaining popularity and nearly 30 years old before C started really appearing on the scene.  C was a relative newcomer and NOT standardized until the mid 80's. (I'm thinking 85, but I might be wrong).  Pascal also gained a strong foothold because of Turbo Pascal from Borland which provided a very fast and full featured compiler in a very small footprint.

[ Parent ]

I lived that history... (5.00 / 1) (#250)
by ucblockhead on Tue May 14, 2002 at 04:17:14 PM EST

Yes, I know 64k PCs had tape drives. You see, I owned one. With Applesoft BASIC in ROM. 16k of ROM. You could also get something called Integer BASIC, which was loaded in a 16k RAM card that lived in the same address space as the ROM. Neither required a tape drive, floppy drive, or any sort of storage.

Before that, there was the TRS-80 Model I, which had 4k RAM, a small amount of ROM, and no tape drive, floppy drive or any permanent storage. It came with BASIC on ROM.

And, of course, the original PC BASIC was written for the Altair by a guy named "Bill Gates", and also had a footprint of less than 8k.

And you seem a might confused. There's no such thing as a "BASIC executable". BASIC was an interpreted language. (This is long, long before VB and compiled BASIC".)

Generally, those 64k PCs used floppy drives, not tape drives. Again, I owned one... UCSD Pascal certainly allowed virtual loading, though the Pascal compiler itself.

You are also wrong about C...yes, "standard" C was not there yet...in those days, it was K&R C, which was de rigeur at most universities, as C was the language behind Unix, and in 1985, Unix was king at the universities. Even the one I went to, UCSD, home of UCSD Pascal. At the time, C was more popular with most of the Unix guys and Pascal was mainly seen as a teaching language. (And, indeed, that's what Nicholas Wirth designed Pascal for...teaching...for real programming, he designed something called "Modula II", which unfortunately didn't catch on, mostly because the OO gold rush was just around the corner.) Indeed, in 1985 at UCSD, Pascal was used only for the introductory programming courses. For "real" work, you used C and C++ for Comp. Sci. stuff and Lisp for AI stuff.

Back then, the two selling points of Turbo Pascal were that it was cheap (as compared to its only real competitor, UCSD Pascal) and fast (UCSD used byte code, like Java, and so was slower. In those days, speed was a big deal.) The first C compiler that I am aware of on the PC was Turbo C, which came out a bit later. (Xenix may have had a C compiler, but Xenix typically ran on bigger machines, with more memory.)
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

So did I (none / 0) (#252)
by Skywise on Tue May 14, 2002 at 05:10:56 PM EST

I didn't say they made Basic executables.  I said they used interpreted Basic because it was difficult on a tape drive to make [C] executables.

My first machine WAS a TRS-80 Model I and it HAD a tape drive.  Cload... memories...

Microsoft made many Basics (that was pretty much their forte at the beginning.)  They wrote the one I used on my Challenger 1P from Ohio Scientific.  It had a tape drive too.  That I had to supply, with a no checksum basic loader... (whoo-hoo)

Once floppy drives came along with the PC's OF COURSE virtual loading became feasible.  But that was around the beginning of the 80's, and Turbo C showed up just after that. (85?)

Unix wasn't king of the universities outside of California, either.  In the midwest (where I went to Purdue) it was IBM's, Vaxes, or Decs.  Unix was used in LAN's in the 80's before taking over in the 90's.  (That may have been due to computer donations from the surrounding industries rather than pure intellectual choice.)

The problem with Modula II, I think, wasn't the OOP craze (though that didn't help), but that it "felt" too much like Pascal... which as you pointed out was a "beginner's" language.

[ Parent ]

Yes. (none / 0) (#249)
by Skywise on Tue May 14, 2002 at 03:55:01 PM EST

C is very easy to write a complier for. (And I have designed a number of compilers and interpreters...)

The trouble comes when you try to do C++ and/or fancy linking stuff.  But the compilation to code is completely straightforward. and nearly a one to one correlation to machine language.

But I'm sure you knew that that was the ENTIRE PURPOSE of developing C in the first place being that you've designed compilers and interpreters yourself...

And as a worker on the "big iron" I'd like to point out that you never saw Basic, Forth or Logo on them...

[ Parent ]

Huh? (none / 0) (#258)
by awgsilyari on Fri May 17, 2002 at 12:31:00 PM EST

Not easy? Have you actually tried it? I'll grant that C is not the simplest of the imperative languages, but it's a lightyear's distance from, for instance, functional languages. In particular, take OCaml. Writing a decent compiler for this language is several years work. It's hard enough for a human to understand the intricacies of its syntax -- to write a foolproof parser is even harder.

C has an interesting property: many people can sit down and write out its grammar (in BNF if you like) without a blink. Ok, the variable declaration syntax is somewhat clunky when it comes to pointers, but the rest of the language is purely straighforward.

As for ideal portable assembler... If not C, then what do you suggest? Are you proposing that an "ideal" portable assembler is possible?

--------
Please direct SPAM to john@neuralnw.com
[ Parent ]

Simple replacements (none / 0) (#229)
by fortytwo on Tue May 14, 2002 at 08:57:59 AM EST

  • Assembly
  • Fortran
  • Machine code(hex or binary)
Still want to ditch C?

C is a thnk of beauty (5.00 / 4) (#232)
by jolly st nick on Tue May 14, 2002 at 09:56:04 AM EST

Speaking as someone whose career started around the time C began to rise to ascendency, you have to look at what was available then. People were trying to do systems programming in languages like PL/1. PL/1 was a large, large language because people thought you needed large languages to tackle big problems. For application programs, COBOL and FORTRAN were the norm.

C was in many ways an unqualified technical success at addressing the problems of the day. First, it was a small language, which made it easy to implement. It's no accident that pretty much the first thing to get ported to microprocessor environments, other than perhaps basic, was C. This also enabled funcationly put into libraries to be available more quickly than if they were embedded in a large language design.

The small size of C made it easy to learn (as well as the excellent K&R book; I often say K&R is one of the best features of C). At the time the computer indudstry was taking off and needed legions of programmers trained.

C is often considered a low level language. It really is not (that is to say more goes on under the covers than many programmers realize), but it is simple and therefore less likely to run into performance problems. It tends to be efficient, which was good for the underpowered machines we had in the 1970s.

C was unrestrictive. Although weak type checking, particularly of pointers, lead to many problems, it meant that disciplined programmers were seldom hindered in doing operations like the infamous matrix multiplication problem that plaguged Pascal ANSI C of course improved the type checking problem considerably, while retraining the freedom of C.

C provided the ability to express the kinds of things programmers knew they needed to express in the 1970s. It had a clean and well chosen set of operators and precedence; it had fairly complete set of control flow constructs; it had a good ability to represent data structures.

Judged by the standards of the 1970s and early 80s, C was an unqualified technical success. The problem is that times have passed it by. Programming paradigms have changed (object orientation), and the kinds of problems we are handling have changed to. Even relatively simple application programs are now viewed as interacting systems of objects, which may have complex responsibilities.

What is remarkable is, not that C remains influential, but that it remains useful at all.

Even So (none / 0) (#254)
by taerom on Tue May 14, 2002 at 06:22:44 PM EST

Even if there was a serious "contenda" to the reign of C, the odds of it going away completely are nil. Consider that COBOL, a 50 year old language, is still used throughout the industry. Why? Millions of lines of code already exist in the language, and it's more cost-effective to maintain compatibility with the old dinosaur language than to rewrite everything in language X. Sure, anything you can do in COBOL you could probably do in Perl or AWK or something, but the code is already there, so it continues to be used. Just simpler and cheaper that way.

Think about how many things are written in C and C++. Its presence is significant on every major computing platform - Windows, UNIX, Mac, QNX, and so forth. If Perl 6 turned out to be as efficient as C, or more so, are we going to see the Linux kernel hackers rewriting the whole damn kernel in Perl? No, because the code is already there in C, and it works.

I'm all for a nice alternative to C for low-level programming, but don't think that even if such alternatives come to be that C will go away completely. Even if C fades into the background, it will never do so completely - and to the extend that it fades away at all, it will do so very slowly.



My choice (none / 0) (#255)
by ivancruz on Tue May 14, 2002 at 09:04:43 PM EST

"Despite I *don't* hate C, I use Delphi for everything."
"What about low-level programming?"
"Oh, I use Delphi also."

Ok, Delphi is not so low-level but it is low-level enought for me.
---


______________________________________
Eu vou, eu vou vender a minha vă, Eu vou vender a minha vă, A minha vă filosofia.(Zeca Baleiro)
Low level alternative to C? | 261 comments (244 topical, 17 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!