Programming Languages?

Holy Jesus. To explain the differences and pros and cons of those languages people have written very thick books. Any attempt here to answer it will result in a flamewar (85% of the time I would guess).

Try amazon or your local library for these books:
Principles of Object Orieented Software Development
Concepts of Programming Languages
Essentials of Programming Languages (advanced)

Err, there are zillions of languages, and their pros and cons depends on what you need them for. So start by saying what you need. And flangazor is right, asking this kind of questions results in either a flamewar, or pages of pointless arguing over different people's opinions and preferences.

Fear my uninformed opinion!

C:
+ very portable (platforms without C compilers are really unusual)
+ close to machine code (easy to determine what the output will be)
+ the C way of linking is compatible with a whole lot of programs (delphi, caml, C++), so libraries you build can be used by many people.
- makes it terribly easy to make mistakes by forgetting important details (null terminations, buffer overflows, sneaky goto's etc)
- can sometimes be lengthy to write things in, and quite prone to obfuscation
- only natively supports a procedural paradigm, although with effort you can also code in an object-oriented fashion.
- if I remember correctly, the standard does not require detection of tail recursion

C++:
+ in theory, as portable as C (the first C++ compiler actually output C code, which was then compiled using a C compiler).
+ natively supports object-oriented and procedural programming (although it can get sloppy in some rare cases).
+ powerful template system that is safer than preprocessor macros.
+ stricter type checking than C
+ widely used, so a lot of resources exist for it.
+ the STL, prevents reinventing the wheel every time you need to copy a string or use a linked list etc
- no native support of multi-dispatch polymorphism, it even is near-impossible without RTTI
- the language is huge and therefore hard to master
- while templates are great in theory, very few good and complete implementations exist
- some find that due to C backwards compatibility, inherent flaws of C have moved on to C++ (but it also makes for some fun stuff, such as "0<:A]", which is an alternate way of writing "*A").

C#:
+ fresh language, some flaws of previous languages have been corrected (such as switch case fall-through, explicit conversion of int to bool...)
+ .NET provides even more things than the C++ STL. You will usually only have to deal with the highest level of things
+ Fast!
+ it is not necessary to use pointers. Also, pointer manipulation is put into "unsafe" zones, which increases the speed of debugging.
+ garbage-collected.
+ runtime optimization through JIT compiling, also (in theory) does not require recompiling to run on a different processor since JIT takes care of transforming the general code into processor-specific code.
+ Excellent productivity. No, better than excellent.
+ Direct use of the Windows and DirectX APIs
+ Forget about definition/declaration issues or circular dependencies
+ Easier manipulation of RTTI
+ Can use string literals in switch cases (iirc)
+ Generics in version 2.0 !
- although multiplatform, a .NET standard implementation is required for it to run. Mono provides it on Linux and Unix, but esoteric platforms cannot run it.
- JIT compiling cause a minor slowdown at launch (but not at runtime)
- a lot of people bull**** you into believing it is windows-only, slow as a snail, lacks essential features, and similar false statements.
- On the outside, .NET looks all clean and shiny, but there ARE design flaws inside, and ones that can be hard to go around (such as FormatterServices + System.String failures, no IBinarySerializable interface although there were plans for it but not enough time...)

Assembly:
+ can be the fastest of all when done by a genius hacker
+ some platforms can only be developed on in assembler (or almost), such as pocket calculators or the old PDP-10 series (although I have heard a C compiler is rumored to exist).
- not portable at all, a different implementation is required for each family of processors
- NO type-checking or general bug-preventing system whatsoever
- is the slowest development tool, except maybe for writing INTERCAL to a tape using a magnetized needle.

Objective Caml (3.08):
+ Probably the best language to write compilers in.
+ A standard library that rivals with the STL
+ Strong typing and universal polymorphism (you only need to write types of objects in signatures, and signatures are optional)
+ Supports procedural, functional and object-oriented programming styles!
+ Garbage-collected
+ Functions can return anything, such as pairs, other functions...
+ Pattern matching system (it's like a switch in C or C++ or C#, but your cases can be anything, such as "a pointer to a group of three objects, the first being the string "abc", the second being a positive integer below 18, and the third being anything).
+ Fast!
+ Possibility to use lazy evaluation for anything.
+ Powerful module system (with functors)
+ Extremely modular system, with interface files (as opposed to the included headers from C or C++)
+ Excellent exception system (WITH exception pattern matching)
- Strong typing prevents operator overloading
- The object-oriented part seems a little bit rushed and awkward, and quite useless given the far superior module system used with a functional paradigm
- Does not use C syntax
- In particular, uses begin/end or (/) instead of {/} which I have found annoying
- Two structures cannot have the same member names (so vector2d and vector3d could not both have an "x" member), although this is overcome with the module system
- No "easy" link-time solving of circular dependencies, they must all be solved locally or worked around, hence defeating a little bit the power of the module system.
- Integer types are 31-bit, makes writing 32bit ARGB colors painful.
- Few external libraries to use (not even a decent graphics library, aside from a half-done OpenGL wrapper).

Feel free to correct anything of the above.

[Edited by - ToohrVyk on January 15, 2005 10:26:51 AM]

What about of just C# and java?

lol dont mind what i just said

Thanx Dude!

Good grief there must be @ least one of these threads a day

Resources > For Beginners > What Language Do I Use?

It's a good place to start to get an idea. The best way ofcourse is just to delve in & get some experience. You can basically adapt any language to achieve what you want, & once you've learnt one you'll know where you want to move on & it'll be easy to learn another

btw: ToohrVyk: Wow[attention]

ToohrVyk:
A few things you said weren't quiiite true.

C++ CAN be faster than C#. You can optomize C++ but not C#. Having the ability to optomize will allow you to increase its speed.

Garbage collection isn't always a good thing. It is why I hate java and C#. If you just program safely in a non-garbage colecting language, then there is nothing to worry about.

My magical ESP sense tells me you program C#.

Quote:

Original post by Darobat ToohrVyk: A few things you said weren't quiiite true. C++ CAN be faster than C#. You can optomize C++ but not C#. Having the ability to optomize will allow you to increase its speed.

Let me get this right. You can't optimize C#?

Quote:

Garbage collection isn't always a good thing. It is why I hate java and C#. If you just program safely in a non-garbage colecting language, then there is nothing to worry about.

Hmmmmmmm. Body armor isn't always a good thing. If you just dodge bullets whilst wearing a day-glo orange suit, then there is nothing to worry about.

Darobat: I know it can happen that I make mistakes.

It is of course possible to optimize unmanaged C++ to be faster than C# (if only through manually optimizing for a given processor better than the JIT system could ever hope to do). What I meant by "fast" is that C# or O'Caml will not be magnitudes slower than C or C++, but rather at the same level.

Also, garbage collecting can indeed become a hassle, but only if it cannot be turned off, which is why C# allows you, should the need arise, to manage memory yourself (through the IDisposable interface, for instance). Since nobody crams GC down your throat (unlike Java or O'Caml), I'd say it's a very good point in favor of C#.

As for the languages I code in, I spend my time as 10% C#, 70% C++ and 20% O'Caml programming. Out of said 70%, 50% are done in a strict g++ -W -Wall -ansi -pedantic kind of way, the other 20% are hacky due to sneaky platforms and non-standard-respecting compilers for these platforms.

Quote:

Original post by Mayrel Quote: Original post by Darobat ToohrVyk: A few things you said weren't quiiite true. C++ CAN be faster than C#. You can optomize C++ but not C#. Having the ability to optomize will allow you to increase its speed. Let me get this right. You can't optimize C#?

Obviously, ANY programming language can be optimized, but in managed languages such as C#, platform-specific tricks don't work (since the language IS platform-independent). Hence there exists a level of optimization that an unmanaged C++ program can reach, but managed C# can't. It is left to the reader to decide whether this is such a big problem after all...

Quote:

Quote: Garbage collection isn't always a good thing. It is why I hate java and C#. If you just program safely in a non-garbage colecting language, then there is nothing to worry about. Hmmmmmmm. Body armor isn't always a good thing. If you just dodge bullets whilst wearing a day-glo orange suit, then there is nothing to worry about.

Indeed, GC is not always a good thing, but not for the reasons Darobat mentioned. What can be annoying about GC is its uncontrollability, such as in the case of O'Caml. Having the app spend 30% of its computing time on GC in short peaks of a few milliseconds every so often causes frame jitter and spikes that are better avoided in a game (although they have no such impact in, say, end-user interfaces).

When it becomes really annoying is when the programmer or designer has better information than the GC about what should be destroyed when. C# has a "GC when memory is asked for" policy which is obviously not adapted to all cases. For instance, if it is perfectly known that an object will not be used anymore, deleting it instead of leaving it behind for the GC to choke on it is in some cases an excellent optimization (and in some cases, isn't).

I have been confronted with the problem of a BSP tree of around 100k nodes in O'Caml. Their tight nature made the garbage collector run in O(n²), or close, every so often to delete unused temporary parts of the tree. An obvious optimization of "remove references, delete" would have gotten this time down to O(n).

Quote:

Original post by ToohrVyk C++: + the STL, prevents reinventing the wheel every time you need to copy a string or use a linked list etc

It doesn't prevent it, it just makes it unnecessary. Plently of people still go ahead and reinvent the wheel anyway.

Quote:

+ fresh language, some flaws of previous languages have been corrected (such as switch case fall-through, explicit conversion of int to bool...)

Not everyone thinks fall-through is a flaw.

Quote:

+ Fast!

Compared to what?

Quote:

+ garbage-collected.

- Lack of control over the GC.

Quote:

+ Direct use of the Windows and DirectX APIs

In what sense is this more 'direct' than in C/C++? The C# language itself doesn't contain these APIs, and neither does the CLI.

Quote:

- although multiplatform, a .NET standard implementation is required for it to run. Mono provides it on Linux and Unix, but esoteric platforms cannot run it.

1. Mono is not a .NET implementation, it is a CLI implementation. .NET includes a lot of features that are not part of the CLI standard. Whilst Mono provides versions of many of these non-CLI components, many others have been plastered with patents and are unlikely to be available in Mono.

2. But that doesn't really matter because you don't need a .NET implementation to run all C# programs, you only need a CLI implementation. And you don't even need that if C# was compiled to native code: it's likely that if future versions of gcc include support for C#, it will, like gcj, support compiling to native code.

Quote:

Original post by MayrelIt doesn't prevent it, it just makes it unnecessary. Plently of people still go ahead and reinvent the wheel anyway.

Why can't we make the assumption nobody is stupid? :)

Quote:

Not everyone thinks fall-through is a flaw.

Uncontrolled fall-through is a flaw, because it can cause bugs more easily than controlled fall-through. C/C++ fall-throughs occur as mistakes (forgetting to write a break;) a lot more often than deliberate ones in your average production code, because many programmers do make these stupid mistakes at least once. To prevent these mistakes, you can either add "company coding standards" which may or may not be perfectly respected, or add compiler support for wrist-slapping.

As far as I am concerned, every time I have received that error, it was because I didn't intend to fall through, but did anyway. Adding a simple "goto case x;" is not that long to write, and it does not happen that often anyway.

Quote:

Compared to what?

I'd say, most programming and script languages.

I KNOW that a language has no speed of its own, only programs + compiler implementations do. However, your average C# or O'Caml will be just as fast as an average C or C++ program (an average taken over the usual compilers for a platform, and without extreme optimizing or stupid inefficiency)..

Quote:

- Lack of control over the GC.

Yes.

Quote:

In what sense is this more 'direct' than in C/C++? The C# language itself doesn't contain these APIs, and neither does the CLI.

Quote:

1. Mono is not a .NET implementation, it is a CLI implementation. .NET includes a lot of features that are not part of the CLI standard. Whilst Mono provides versions of many of these non-CLI components, many others have been plastered with patents and are unlikely to be available in Mono. 2. But that doesn't really matter because you don't need a .NET implementation to run all C# programs, you only need a CLI implementation. And you don't even need that if C# was compiled to native code: it's likely that if future versions of gcc include support for C#, it will, like gcj, support compiling to native code.

As I feared, these parts with me confusing .NET and CLI were wrong. Thank you for clearing that up.

How long do you think it will take for gcc to include native C# compiling?

Quote:

Original post by Mayrel [...] Quote: Garbage collection isn't always a good thing. It is why I hate java and C#. If you just program safely in a non-garbage colecting language, then there is nothing to worry about. Hmmmmmmm. Body armor isn't always a good thing. If you just dodge bullets whilst wearing a day-glo orange suit, then there is nothing to worry about.

Body armor isn't always a good thing. Wearing plate mail won't stop bullets, and kevlar won't stop knives, and when you're at the grocery store not worrying about either situation you'd just be carrying around dead weight that is slowing you down for no good reason.

GC is the same way - one type will solve one set of situations well, another a different set of situations, and just turning it off might be best sometimes.

Quote:

Original post by Extrarius GC is the same way - one type will solve one set of situations well, another a different set of situations, and just turning it off might be best sometimes.

Or simply...implement the best garbage collector to resolve a specific problem.
With STL implement a GC is very very simple!!! From a GC list to a more sophisticated memory pool manager.

However in MY OPINION the best languages are C, C++ and java...why? because they are portable, usefull and used by a lot of people.
Probably C, C++, java is also the right order to learn them...

Quote:

Original post by Extrarius Quote: Original post by Mayrel [...] Quote: Garbage collection isn't always a good thing. It is why I hate java and C#. If you just program safely in a non-garbage colecting language, then there is nothing to worry about. Hmmmmmmm. Body armor isn't always a good thing. If you just dodge bullets whilst wearing a day-glo orange suit, then there is nothing to worry about. Body armor isn't always a good thing. Wearing plate mail won't stop bullets, and kevlar won't stop knives, and when you're at the grocery store not worrying about either situation you'd just be carrying around dead weight that is slowing you down for no good reason. GC is the same way - one type will solve one set of situations well, another a different set of situations, and just turning it off might be best sometimes.

All very true. But don't you rather get the impression that Darobat is opposed to garbage collection even if you have a lot of control over it?

In computing, the grocery stores are full of rifle-toting sociopaths. Unless you absolutely know you're great, it's irresponsible to use unsafe language features, at least in important programs.

One of my favorite reads about "which language" can be found here. Here are a few select quotes:

Quote:

The people who ask this question typically don't have any specific project in mind; if they did, it would be a lot easier to answer them. Instead, they're really saying "I don't know much about programming, but I think it might be kind of fun. Where's the best place to start?"

Quote:

A shorter way of saying this is: don't worry about learning the syntax of a language. Don't concentrate on it. Don't spend time worrying about it. Learning where the semicolons or parentheses go will come by itself, as you write code and go through compile-run-test cycles. Look that stuff up when you need to, but understand that "learning what a constructor in Java looks like" is, in the long term not a valuable thing to concentrate on. Learning what a constructor is and what it does is a valuable thing to concentrate on.

Quote:

Practical Considerations Programming is fundamentally a "learn by doing" activity, so your language choices are somewhat constrained by the need to use a language that can actually run on your operating system of choice. This still leaves you with a fairly wide set of options. Language availability isn't the only practical consideration. If applicable, is there a debugger for the language you want to use? What set of libraries will you be using? How much documentation is available for the language you want to learn? Is there an active community you can turn to for help?

It's a very good read. In fact, it would probably be a good page to send beginners to when they ask the inevitable question "what language should I learn?"