What are the good and bad sides of these languages?
Author
C/C++
COBOL
FORTRAN
Assembly
Pascal
I''m just curious as to what is good and bad about these languages...what are each specifically good for, etc. I''m not asking "what is the best", just what are the up and downsides to all of them.
Hi,
I am not an expert on computer languages, but perhaps I can help out a bit.
FIRST off C and C++ are NOT the same language! Everybody groups them together because the use identical syntax in certain control structures( functions, variables ).
1. C - C is fast. C is a procedural language, you define processes, ala functions, then invoke them from somewhere in the program, like the main loop, or in some other function(please feel free to correct my terminology)
2. C++ - C++ is also fast, but not as fast as C. Not that it is a big deal. Unless you are writing some embedded systems, or real time missle control system, you will not miss out on C''s speed when using C++. In fact, in certain situations C++ can be faster than C. C++ is an Object Oriented Programming language. What that means is that you define Objects which provide interfaces(services) to each other. Instead of modelling processes the emphasis is on modeling objects which represent a part of your system. C++ is very good for modeling Large, complex systems, such as Game Engines, Operating Systems(please do not start a flame war), and almost anything that requires more than a thousand lines of code(that is generally the rule of thumb I use when selecting my language, with a few exceptions).
3. COBOL - If I ever write any COBOl code... Shoot me.
4. FORTRAN - I think it is procedural, but I do not know enough about FORTRAN to comment on it.
5. Assembly - FAST, REALLY REALLY FAST! But incredibly tedious to program large things in. Assembly is the code native to a particular machine architechture(I think... ?) so it is like skipping a normal language and defining the exact instructions yourself. It can be really usefull in areas with high performance restrictions, and to implement algortihms.
I personally recommend C++ as a language because, Once you learn C++, you know C and it is very easy to learn Java, so it is like learning 3 languages at once. Second, it is fast(enough) so that you can write Game Engines, AI, scripting engines and whatever else and not worry about it running like a stoned turtle.
I hope I have not patronized you in this reply, and whatever language you use, happy programming!
I am not an expert on computer languages, but perhaps I can help out a bit.
FIRST off C and C++ are NOT the same language! Everybody groups them together because the use identical syntax in certain control structures( functions, variables ).
1. C - C is fast. C is a procedural language, you define processes, ala functions, then invoke them from somewhere in the program, like the main loop, or in some other function(please feel free to correct my terminology)
2. C++ - C++ is also fast, but not as fast as C. Not that it is a big deal. Unless you are writing some embedded systems, or real time missle control system, you will not miss out on C''s speed when using C++. In fact, in certain situations C++ can be faster than C. C++ is an Object Oriented Programming language. What that means is that you define Objects which provide interfaces(services) to each other. Instead of modelling processes the emphasis is on modeling objects which represent a part of your system. C++ is very good for modeling Large, complex systems, such as Game Engines, Operating Systems(please do not start a flame war), and almost anything that requires more than a thousand lines of code(that is generally the rule of thumb I use when selecting my language, with a few exceptions).
3. COBOL - If I ever write any COBOl code... Shoot me.
4. FORTRAN - I think it is procedural, but I do not know enough about FORTRAN to comment on it.
5. Assembly - FAST, REALLY REALLY FAST! But incredibly tedious to program large things in. Assembly is the code native to a particular machine architechture(I think... ?) so it is like skipping a normal language and defining the exact instructions yourself. It can be really usefull in areas with high performance restrictions, and to implement algortihms.
I personally recommend C++ as a language because, Once you learn C++, you know C and it is very easy to learn Java, so it is like learning 3 languages at once. Second, it is fast(enough) so that you can write Game Engines, AI, scripting engines and whatever else and not worry about it running like a stoned turtle.
I hope I have not patronized you in this reply, and whatever language you use, happy programming!
C
If your gonna learn C++, then it may be to your advantage to learn C first. C++ compilers can compile C code, and you will be able to get a hang of the syntax without worrying about OOP. It''s very possible to write a modern game in it, however you would probably want to use C++ instead. Can be difficult to learn, especially pointers (I got a seperate book on just those, and it rules btw), but the syntax is amazingly comfortable once u get the hang of it.
C++
OOP language based on C. Very good, very fast, and an industry standard at least for games. My language of choice.
COBOL
FORTRAN
No comment on either of these, save that they are quite dated. Never actually coded in ''em.
Assembly
Either very very slow or very very fast. Since all higher level languages (such as C) are first converted to assembly and then compiled into an .exe, anything you can do in those languages u can do in assembly. But you would need many years of experience in assembly to be able to produce an entire program that actually performs faster than a C/C++ equivelent compiled with a good compiler. Sprinkling C++ code with in-line assembly is a good idea if you know what your are doing, but you do not want to write programs in assembly unless u want to spend the rest of your life doing so.
Pascal
First programming language I *ever* tried
It''s nifty, fairly easy to learn while not being ridiculously crappy like BASIC. C is better, but Pascal is quite good, and Delphi, which uses Object Pascal, is an excellent RAD tool. I don''t like Pascal''s memory control, and you aren''t going to find as much support for it as you will for C. Good place to start though.
C/C++ has a clean streamlined syntax. This allows a compiler to more accurately convert it to machine code, which allows faster execution. C/C++ has very few keywords, and none which are system dependant. This allows C/C++ to be standardized, multiplatform, and portable. The others are not.
Assembly isn''t really a language (there aren''t actually any keywords nor are there syntax rules). The only quality assembly language has is that it describes what instructions a processor should execute instead of what the program should do.
cmaker
- I do not make clones.
Assembly isn''t really a language (there aren''t actually any keywords nor are there syntax rules). The only quality assembly language has is that it describes what instructions a processor should execute instead of what the program should do.
cmaker
- I do not make clones.
C is an extremely portable language, if a processor exist, it has a C compiler. It''s important to know what is and is not C code (as opposed to C++ code), there are a few things that work very differently in C than C++ (like casting).
C++ is a very robust OOD language, it has certain features that make developing an OOD program easier than other languages (many but not every processor has a C++ compiler available). My language of choice.
COBOL is an ancient language, but like all good vampires, refuses to die. There was resurgance if infections due to Y2k bugs. It''s syntax is mind numbing, avoid at all cost. In the earlier 1990''s sadist created a OOP versions of COBOL.
Fortran is only ''mostly dead'' which we all know is very different from ''completely dead''. Much DSP code was originally written in Fortran, and has not been rewritten in other languages (or has been very poorly *cough* www.nr.com *cough*). In the days of yore, it was the engineer''s language of choice (seems to have been replaced by VBA today...)
Assembly; sprinkle lightly.
Pascal blows chunks so large they do no fit on this page. Borland has created a sophisticated ventilator to keep it alive called Delphi. Slowly the Delphi language is morphing into Ada, the transmutation should be complete early 2010.
Magmai Kai Holmlor
- The disgruntled & disillusioned
C++ is a very robust OOD language, it has certain features that make developing an OOD program easier than other languages (many but not every processor has a C++ compiler available). My language of choice.
COBOL is an ancient language, but like all good vampires, refuses to die. There was resurgance if infections due to Y2k bugs. It''s syntax is mind numbing, avoid at all cost. In the earlier 1990''s sadist created a OOP versions of COBOL.
Fortran is only ''mostly dead'' which we all know is very different from ''completely dead''. Much DSP code was originally written in Fortran, and has not been rewritten in other languages (or has been very poorly *cough* www.nr.com *cough*). In the days of yore, it was the engineer''s language of choice (seems to have been replaced by VBA today...)
Assembly; sprinkle lightly.
Pascal blows chunks so large they do no fit on this page. Borland has created a sophisticated ventilator to keep it alive called Delphi. Slowly the Delphi language is morphing into Ada, the transmutation should be complete early 2010.
Magmai Kai Holmlor
- The disgruntled & disillusioned
C, C++, and assemby share a common disadvantage. You can easily get into real trouble with them.(Going into OS memory space, crashing stuff, etc) While Pascal can also do that it is more restrictive on the data it handle, because it was designed as a programming learning aid.(Despite what most people thing Pascal is not to far from C in power) COBOL is mostly a text-oriented, business app language. And last time I checked was considered very slow. FORTRAN is mostly for science and engineering.Although it does have bindings to OpenGL.(not all bad, eh)
For more information vist the 000 section of your local library. If Memphis has book on this stuff I know other cities have got big long row of book on it.
PS Go Maniax!
It''s me, it''s that T-H-E-D.
For more information vist the 000 section of your local library. If Memphis has book on this stuff I know other cities have got big long row of book on it.
PS Go Maniax!
It''s me, it''s that T-H-E-D.
Since everyone here talks about how good C/C++ is, I'll post this borrowed bit that explains how bad it is also, and it pretty much sums up how I feel about the language.
C/C++ do not include functions as a first-class object, thus creating a boundary between using and programming: it's a static language; you can't both program and use at the same time. That's the opposite of user programmer/user friendliness.
C/C++ is not a structured language: procedures are all global; that's why C/C++ will NEVER allow having independent light threads, and why it's impossible to have a lightweight multitasking system under C/C++. You may notice that this point is related to the preceding remark: if procedure were objects, you could include them individually inside thread objects, then each thread would have its own independent code.
C/C++ knows only early binding (i.e., it only compiles directly executable code), hardly knows about dynamic library linking (in the case of C, it's not a language feature, only a linker feature); C/C++ considers a program to be complete, finished, and run in the absolute without interaction with other programs, but through the system; that's why all ROI in C must be explicitly done through system calls !!!
The "we won't have to rewrite a compiler" argument doesn't stand: if the system is to be OOed, we'll have to adapt the compiler so that it produces OO code compliant to our system's requirements. Unless our system brings nothing that can't be done easily by replacing the standard library, it's impossible; so only front ends can be reused, which are trivial to write (although more difficult in the case of C than with other languages). All in all, "C" would only get in the way if used.
As it's a low-level language, either we'll have to have low-level specs for the OS (as with Unix), so that we can't adapt to an architecture different from that for the which the OS was designed; or we'll have to rewrite a great amount of the C/C++ code on each system adaptation. So we lose either system functionality, or language portability. Interoperability of code is also impossible, unless we define a common target architecture that other computers will have to emulate.
For the same reason (C/C++ being low-level), we can never achieve object-level security, but by having a C/C++ program for each object, which either disallows everything -however little- is an object in the system, or requires many a low-level system (as opposed to language) declaration in a C source, and/or requires having tiny C/C++ programs, which contradicts the heavy compilation cost and the class philosophy of the language.
It is remarkable that most security alerts in operating systems are related to buffer overruns in C code, because the language doesn't help in any way to automatically ensure safety -- unsafety is the default, and manually ensuring it is a long, tedious, difficult task. A higher-level language could fully automatize safety, making it the default, whereas it would be unsafe operations that would have to be explicitly coded.
Horrible in C and dreadful in C++ is the lack of really first-class structured values. This makes C nothing more than a badly specified portable assembler (with very limited macro facility, and restrictions in calling conventions), and gives a completely obfuscated notion of object identity to C++.
The C++ philosophy contradicts the idea of late user-object binding. C++ knows only of early compile-time object binding, or at best/worst, binding with compile-time defined virtual class realization through so called virtual tables. So to make the slightiest add/change, you must recompile the whole application.
Because the whole object system in C++ is based on braindead inheritance, enhancements in a program may mean complete rewrite of the type hierarchy.
The C/C++ preprocessor allows simple macro-definitions, but neither macro instructions, nor recursive macro definitions. If #define DEF #define was possible, for example, it would be possible to Ziv-Lempel compress a source program from C to C. But cpp just plain sucks.
Note that "C" offers absolutely no particular interest when cut from all its standard compilers and libraries, for you can no more port existing software. As TUNES won't support any standard "C" library (at least as support for native code), and requires a different compiler anyway, because its semantics is so much different, "C" offers no interest on top of TUNES. Thus, "C" just has nothing to do with TUNES, except perhaps as a layer between TUNES and a POSIX compliant system, if TUNES is to be implemented as an application under such system (see OTOP subproject).
Edited by - multitap on January 31, 2001 10:57:18 PM
C/C++ do not include functions as a first-class object, thus creating a boundary between using and programming: it's a static language; you can't both program and use at the same time. That's the opposite of user programmer/user friendliness.
C/C++ is not a structured language: procedures are all global; that's why C/C++ will NEVER allow having independent light threads, and why it's impossible to have a lightweight multitasking system under C/C++. You may notice that this point is related to the preceding remark: if procedure were objects, you could include them individually inside thread objects, then each thread would have its own independent code.
C/C++ knows only early binding (i.e., it only compiles directly executable code), hardly knows about dynamic library linking (in the case of C, it's not a language feature, only a linker feature); C/C++ considers a program to be complete, finished, and run in the absolute without interaction with other programs, but through the system; that's why all ROI in C must be explicitly done through system calls !!!
The "we won't have to rewrite a compiler" argument doesn't stand: if the system is to be OOed, we'll have to adapt the compiler so that it produces OO code compliant to our system's requirements. Unless our system brings nothing that can't be done easily by replacing the standard library, it's impossible; so only front ends can be reused, which are trivial to write (although more difficult in the case of C than with other languages). All in all, "C" would only get in the way if used.
As it's a low-level language, either we'll have to have low-level specs for the OS (as with Unix), so that we can't adapt to an architecture different from that for the which the OS was designed; or we'll have to rewrite a great amount of the C/C++ code on each system adaptation. So we lose either system functionality, or language portability. Interoperability of code is also impossible, unless we define a common target architecture that other computers will have to emulate.
For the same reason (C/C++ being low-level), we can never achieve object-level security, but by having a C/C++ program for each object, which either disallows everything -however little- is an object in the system, or requires many a low-level system (as opposed to language) declaration in a C source, and/or requires having tiny C/C++ programs, which contradicts the heavy compilation cost and the class philosophy of the language.
It is remarkable that most security alerts in operating systems are related to buffer overruns in C code, because the language doesn't help in any way to automatically ensure safety -- unsafety is the default, and manually ensuring it is a long, tedious, difficult task. A higher-level language could fully automatize safety, making it the default, whereas it would be unsafe operations that would have to be explicitly coded.
Horrible in C and dreadful in C++ is the lack of really first-class structured values. This makes C nothing more than a badly specified portable assembler (with very limited macro facility, and restrictions in calling conventions), and gives a completely obfuscated notion of object identity to C++.
The C++ philosophy contradicts the idea of late user-object binding. C++ knows only of early compile-time object binding, or at best/worst, binding with compile-time defined virtual class realization through so called virtual tables. So to make the slightiest add/change, you must recompile the whole application.
Because the whole object system in C++ is based on braindead inheritance, enhancements in a program may mean complete rewrite of the type hierarchy.
The C/C++ preprocessor allows simple macro-definitions, but neither macro instructions, nor recursive macro definitions. If #define DEF #define was possible, for example, it would be possible to Ziv-Lempel compress a source program from C to C. But cpp just plain sucks.
Note that "C" offers absolutely no particular interest when cut from all its standard compilers and libraries, for you can no more port existing software. As TUNES won't support any standard "C" library (at least as support for native code), and requires a different compiler anyway, because its semantics is so much different, "C" offers no interest on top of TUNES. Thus, "C" just has nothing to do with TUNES, except perhaps as a layer between TUNES and a POSIX compliant system, if TUNES is to be implemented as an application under such system (see OTOP subproject).
Edited by - multitap on January 31, 2001 10:57:18 PM
Some notes on the assembly language:
A good time to learn this after you have a strong understanding of working with bits within data. If you program in C++ and are using a DWORD flags parameter to store info rather than multiple BYTEs or otherwise, it is time to look into the assembly language, because you are now seeing data in terms of bits masks rather than just numbers.
I knew quite a bit of C++, yet an understanding of it becomes more rich through the world of assembly language. Suddenly, your data is packed in a fashion that can be quickly used by asm opcodes. You can read asm output of C++ code and see how your compiler works (and where it should get slapped on the wrist.)
In any case, I recommend rarely (ahem, never) inlining asm within a C++ program because that is only seeing part of the picture. A separate ASM module will give you insight on different calling conventions and how parameters are passed in asm code.
Just because a module is coded in asm doesn''t make it fast, so understand deeply how it can be used for the powers of good. Look for optimization articles and print yourself out the opcodes and related information (from Intels site). I found that working in assembly language is extremely puzzle-like. Optimizing for Pentium processors is fun, as there are pairing rules for opcodes that will keep you working with a smile on your face (and unlike puzzle games, this has a real award... high performance code).
The popular myth of assembly language being scary is totally bogus (to quote Bill or Ted). It is most truly excellent and most rewarding. Party on dudes!
.travois.
Oh... and give my love to the princesses... you''ll see!
A good time to learn this after you have a strong understanding of working with bits within data. If you program in C++ and are using a DWORD flags parameter to store info rather than multiple BYTEs or otherwise, it is time to look into the assembly language, because you are now seeing data in terms of bits masks rather than just numbers.
I knew quite a bit of C++, yet an understanding of it becomes more rich through the world of assembly language. Suddenly, your data is packed in a fashion that can be quickly used by asm opcodes. You can read asm output of C++ code and see how your compiler works (and where it should get slapped on the wrist.)
In any case, I recommend rarely (ahem, never) inlining asm within a C++ program because that is only seeing part of the picture. A separate ASM module will give you insight on different calling conventions and how parameters are passed in asm code.
Just because a module is coded in asm doesn''t make it fast, so understand deeply how it can be used for the powers of good. Look for optimization articles and print yourself out the opcodes and related information (from Intels site). I found that working in assembly language is extremely puzzle-like. Optimizing for Pentium processors is fun, as there are pairing rules for opcodes that will keep you working with a smile on your face (and unlike puzzle games, this has a real award... high performance code).
The popular myth of assembly language being scary is totally bogus (to quote Bill or Ted). It is most truly excellent and most rewarding. Party on dudes!
.travois.
Oh... and give my love to the princesses... you''ll see!
assembly - slow
C/C++ - slower
Fortran/Cobol - very slow, I suppose
Pascal - falls somewhere in the slower - very slow region, I think
Anyways, isn''t Fortran a decent choice when doing scientific applications? Heavy math etc?
C/C++ - slower
Fortran/Cobol - very slow, I suppose
Pascal - falls somewhere in the slower - very slow region, I think
Anyways, isn''t Fortran a decent choice when doing scientific applications? Heavy math etc?
Asm is not as tedious as people make it seem . Using Masm 32 lets you define macros , making your code look more c like . There are some RAD tools like Prostart that generate code ala MFC app wizard. I use a modified version of Prostart and I can produce a skeleton app just as fast and as easily as in VB or MFC APP wiz , without compensating speed and size . I did a test and made a simple dialog based app . In asm the app size was 2k , C++ (winapi) was 67k , MFC 268 k and in Vbasic , well , lets not go there 
.How effective a language is depends on the profciency of the programmer in most cases.
.How effective a language is depends on the profciency of the programmer in most cases.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
