mic@lapis.berkeley.edu (Michel Bruneau) (04/15/87)
I have been explained long long ago how sensible a thing it was to program in C on a Unix system, as the whole operating system is already written in C. That being said, if somebody owns a PC (IBM clone type ) why would he want to program in C at all????? I must be missing something here!!!! ALSO: I am asking the people in the other parts of this country: Is C something used a lot (not just in california I hope) or is it just another fad language that will be completely gone two years from now..... I am pretty ignorant as you can see, and would appreciate any sparks of light.
cbenda@unccvax.UUCP (carl m benda) (04/16/87)
In article <3180@jade.BERKELEY.EDU>, mic@lapis.berkeley.edu (Michel Bruneau) writes: > ALSO: I am asking the people in the other parts of this country: > Is C something used a lot (not just in california I hope) or is it > just another fad language that will be completely gone two years > from now..... Well Michel.. C is not just another fad language, it so happens that more advances in the knowledge of compilers and compiler tools have been made as a result of the existence of the C programming language, than any other single entity. It may well be that C is greatly used (in more ways than one) in California, but lets remember that it was developed in part by New Jersey based Bell Laboratories. The functional utility of the language is inherently part of its design and evolution from B, etc.. That plus the fact that C remains the most portable of all source code, even when the code is ported across differing operating systems and differing architectures.. Hopefully this will quell(sp) your fears about using the C language for application programming. This language, beyond all others has the most hope of survival. /Carl
dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/16/87)
A project I worked on 2 summers ago involved writing a pc-based telemetry system, approximately 15000 lines of C code. It would have been impossible to do in assembly for several reasons. (1) It would have been about 40000 lines of assembly. (2) The sourece would have been unreadable due to the large number of structures in the system. (3) The assembly would have been extremely messy because the program references a helofalot more than 64K of data. (5) It would have taken 8 months instead of 3 to write. (6) It would be difficult to make major modifications if it had not been written in C. As it turned out, I still needed about 200 lines of assembly for the serial, parallel, and real-time clock drivers. In that particular project, speed was not a problem area. Compiled C code on 808x systems is usually between 1.5 and 2 times slower than equivalent handcoded assembly, but it depends on the compiler. -Matt
ward@chinet.UUCP (ward) (04/19/87)
C is here to stay. Early micros HAD to be programmed in assembler - there weren't enough "cycles" to get the job done in higher level languages (with their associated inefficiencies in MOST cases). As microprocessors become more powerful, the programmers' time becomes more important - productivity reigns over program speed. A popular way to develop programs for the PC is to write the entire application in C, then if it isn't running fast enough, run an execution profiler to find where you are spending time. Then, re-write these routines in assembler. There are some very good C languages out there - Microsoft is very good, and Borland promises to make C the language of choice of more and more people.
leder@ihlpm.ATT.COM (Leder) (04/20/87)
In article <3180@jade.BERKELEY.EDU>, mic@lapis.berkeley.edu.UUCP writes: > I ... how sensible ... program in C on a Unix system, ... > That being said, ... a PC (IBM clone type ) why would he want > to program in C at all????? I must be missing something > here!!!! You just knew the world would repond to that line of statement. Maybe your underlying question is: Should we just program in the language that the operating system was written in? I personally think not. > Is C something used a lot ...just another fad language For me, C is not a fad language. I have used C on non-UNIX machines more and for longer than I have on UNIX machines. An interesting thing that happened to me and I think quite a few others is that C provided all of those things that we would have personally put into a language if we had been the designer. Obviously, one language is not right for everyone so pick what you like. In response to the speed issue, on MS-DOS C compilers exist that will generate code that outruns everything else except machine language. Some day, the compilers will generate code that we don't have to appologize for. Bob Leder - just looking in
shaun@buengc.BU.EDU (Shaun Keller) (04/21/87)
Anyone know what the story is on Borland's C? When will it be out? Do you know if it will compare to Microsoft C? -Shaun
doug@edge.UUCP (Doug Pardee) (04/21/87)
I have to agree with everyone else; C is almost certainly here to stay. It's the high-level language which is most likely to join the ranks of FORTRAN and COBOL as "immortal" languages. In the specific case of the PC, the existence of Turbo Pascal has given the Pascal language a temporary boost. It didn't do much for other computers, though. So, if you have a reason for programming in a high-level language, and if the application doesn't immediately suggest using some other language (for example, a structural engineering program would be best written in FORTRAN), then C is indeed the language of choice. But but but but... If you're writing a program that you hope to sell commercially (a software product, that is), pay no attention to the folks who tell you to use C, or for that matter, *any* high-level language on the PC. Yes, it's true that there are a lot more software products written in C and Pascal than there are written in assembler. It's also true that nearly all *successful* software products for the PC are written in assembler. Quotes like this one: > As microprocessors become more powerful, the programmers' time becomes > more important - productivity reigns over program speed. come from programmers who are concerned about doing a minimum amount of work, *not* from potential customers. If you try to tell some poor guy who has a 256K PC that in order to run your program he "only" has to get a 10MHz Turbo-AT with 640K of main memory and then not have a RAM-disk, and he can't load Sidekick or any other pop-ups, just to run your wonderful program, guess what he's gonna say! There's a reason that people are buying ATs, Turbo-ATs, and '386 boxes: they want/need *speed*. And there seems to be never enough memory in any given PC, especially with all of the TSRs (Terminate-and-Stay-Resident programs) that people like to keep around. And now for a cheap shot: > A popular way to develop programs for the PC is to write the entire > application in C, then if it isn't running fast enough, run an execution > profiler to find where you are spending time. Then, re-write these > routines in assembler. This is a popular thing to *talk* about doing. Almost nobody ever does go back and profile and rewrite. Can't say as I've seen any discussion on the net about the "best" profiling package. Having been involved in the profiling business, I can testify that everyone who has ever really used a profiler has very strong opinions about which ones are good and which are bad. Besides which, there are "distributed" inefficiencies in any high-level language that won't appear on a profiler, and couldn't be individually recoded in assembler anyway. The two most common ones are a) procedure call overhead, especially parameter passing, and b) overall size of the instruction code. A third distributed inefficiency can occur when there is no straight-forward way to implement a major data structure, and every reference to it has to be done with a kludge. I'll skip the details, this posting is already ghastly long. -- Doug Pardee -- Edge Computer Corp. -- Scottsdale, Arizona