• Advertisement
Sign in to follow this  

So you want to be a real programmer?

This topic is 2420 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

The "real" programmer is the one who answers "yes sir!" when asked and goes about, you know, the actual business of programming. Your macho C++ skills won't help you when I slam my fist in the table and puffs that cigar smoke in the air asking you to make due with Java for the next three ungodly months because we just got a contract for it...or COBOL perhaps? People do, indeed, in fact still use that ancient mythical beast of a programming language. But, we're forgetting that we must remain C++ macho men here! In fact, your machoness have just earned you a promotion to independence free from the company's silly "languages"!

See the positive, now you can handle unhandled exceptions and undefined behavior all day long! :)

Share this post


Link to post
Share on other sites
Advertisement
C++ sucks because of it's (lack of) memory management and arcane syntactical constructs.

Java sucks because it's a pain in the butt for deployment to non-technical users.

C# sucks because it prevents you from getting down-n-dirty with the bits and bytes when you need to.

VB sucks because of it's overly-verbose syntax.

COBOL sucks because ... well... ADD SUCK TO COBOL, MOVE COBOL TO SUCK PILE ... it's COBOL.

Scripting languages suck because the performance needed just isn't there.

On the face of it, every programming language sucks to some degree and in some way that others don't. That's what it's all about. You have a problem. You need to solve it. You analyze and understand the problem and pick the most appropriate tool for the job. Sometimes you need more than one tool, and sometimes the tool that's good at one part of the job is hopelessly useless at another. If you're a langauge zealot or a one-trick-pony you'll never get this.

Share this post


Link to post
Share on other sites
Well said mhagain... and I should have figured my little COBOL snark would get out of control :lol:.

by the way, my intent before was not so much to evangelize C++ but to try to level the playing field as I tend to think C++ in particular takes a lot of flak compared to other "modern" programming languages. Apologies for any confusion

Share this post


Link to post
Share on other sites

C++ takes a lot of heat because it doesn't conform to today's fad ideas of mainline programming (this is IMHO, of course :P) namely: Strict adherence to OOP principles, and type safety. C++ wasn't designed to be an OO language, but rather to give you the ability to write OO code if you chose to. It was not really written to be type safe because strictly enforcing type safety can limit programmers, to a certain degree. It is a language of choice, designed to support multiple paradigms. Honestly, I think pure OO and type safety are both overrated... just like you should use the right tool for the job, you should use the right paradigm for the job -- and sometimes that is somewhat subjective. As for C++ being dangerous: Sure it is... it makes no effort to hold your hand. If you or I, as programmers, mess up then it won't work properly... because we messed up. The idea is to learn the tools available, apply good design skills (and I tend to think at least some degree of creative intuition), and be careful. If something is broken, take responsibility and fix it. Java/C# have somewhat different approach... They are "safer" to work in as often times you won't go quite as humorously or terrifyingly wrong, and yet they somewhat restrict you from trying the crazy idea which later turns out to be brilliant, etc etc etc. Of course, many will disagree, that is fine. When it comes to it, C++ is just as valid a language as Java/C#/whatever depending on use, and on programmer comfort and preference.


good points there.
heres another one:
it does not force you to do things in a specifiec mannor, i can do thread however i want, or i can read files however i want.
but the down side is that there are a lot of ways to shoot yourself in the foot, but when you have learnt that shooting yourself in the foot is not the way forward you do it in a better way :)

Share this post


Link to post
Share on other sites

C++ sucks because of it's (lack of) memory management and arcane syntactical constructs.


then dont use it.
if you cant handle the controll, use another language


C# sucks because it prevents you from getting down-n-dirty with the bits and bytes when you need to.


then learn C/C++


VB sucks because of it's overly-verbose syntax.


i also dont like the syntax, but it is supposed to be easy to learn for the non programmers.


Scripting languages suck because the performance needed just isn't there.


Lua can be "Compiled"(or so ive heard, so it is a lot faster)


COBOL sucks because ... well... ADD SUCK TO COBOL, MOVE COBOL TO SUCK PILE ... it's COBOL.


it appears that COBOL "sucks" for no apparent reason.


Java sucks because it's a pain in the butt for deployment to non-technical users.


well, thats where all the fun is :cool:

Share this post


Link to post
Share on other sites

C++ takes a lot of heat because it doesn't conform to today's fad ideas of mainline programming (this is IMHO, of course :P) namely: Strict adherence to OOP principles, and type safety. C++ wasn't designed to be an OO language, but rather to give you the ability to write OO code if you chose to.


Um, yes it it was. C was designed EXACTLY to be an OO language. C++ actually started out being called C with Classes ( aka, objects ). The very first extensions to C++ were to support Object oriented programming on top of C. ( Originally C++ compiled down to C code ). [font="sans-serif"]Bjarne Stroustrup was heavily inspired by and accredits Simula as one of the major inspirations for C++. Now, one of the design tenants of C++, at least as it evolved, was to but a multi paradigm language, but then, the same can be said of C# ( which supports functional, procedural, object oriented and various other programming methodologies ) and a lesser degree to Java and various other languages. Few languages actually force you into a specific coding style, beyond the likes of smalltalk, LISP and other specialty languages.[/font]
[font="sans-serif"] [/font]
[font="sans-serif"]
[/font]
It was not really written to be type safe because strictly enforcing type safety can limit programmers, to a certain degree.
[/quote]


Like what? What *good* programming practice does C++ lack of type safety enable it to perform, that a language such as C# cannot? [ There are a few answers, I'm curious to hear yours ]


It is a language of choice, designed to support multiple paradigms.
[/quote]

As explained earlier, this is by no means exclusively the domain of C++. Actually, in some areas, C++ is actually a very poor fit for some programming paradigms.


Honestly, I think pure OO and type safety are both overrated... just like you should use the right tool for the job, you should use the right paradigm for the job -- and sometimes that is somewhat subjective.
[/quote]

Really? Lets completely ignore the merits of object oriented programming for a second, which is a thread unto itself, but frankly you think type safety is overrated? Really?


As for C++ being dangerous: Sure it is... it makes no effort to hold your hand. If you or I, as programmers, mess up then it won't work properly... because we messed up. The idea is to learn the tools available, apply good design skills (and I tend to think at least some degree of creative intuition), and be careful. If something is broken, take responsibility and fix it. Java/C# have somewhat different approach... They are "safer" to work in as often times you won't go quite as humorously or terrifyingly wrong, and yet they somewhat restrict you from trying the crazy idea which later turns out to be brilliant, etc etc etc. Of course, many will disagree, that is fine. When it comes to it, C++ is just as valid a language as Java/C#/whatever depending on use, and on programmer comfort and preference.
[/quote]

If I can be completely honest for a moment, I highly recommend you take some time to familiarize yourself with some other languages. Some of your perceptions of different languages are just patently wrong, as are your understanding of the history and to a lesser degree, the merits of C++.

Had you mentioned portability as a strength, that I could understand. Had you mentioned 3rd party library support as a strength, that I could understand. Or the large repositories of code and the backward compatibility with C, that I could have understood. Had you mentioned performance as a strength, that I would have slightly disputed, but still it would be understandable. Yet almost every thing you did mention, to be completely honest, are the kind of things that one hears from another and puppets as truth.

Please don't take this as an insult or as an attack on C++, my intentions are good. It just seem so many people are working on bad supposition, and in the end that doesn't help anyone, especially when those suppositions are passed on generation after generation.

Share this post


Link to post
Share on other sites

[quote name='medevilenemy' timestamp='1307330294' post='4819962']
C++ takes a lot of heat because it doesn't conform to today's fad ideas of mainline programming (this is IMHO, of course :P) namely: Strict adherence to OOP principles, and type safety. C++ wasn't designed to be an OO language, but rather to give you the ability to write OO code if you chose to. It was not really written to be type safe because strictly enforcing type safety can limit programmers, to a certain degree. It is a language of choice, designed to support multiple paradigms. Honestly, I think pure OO and type safety are both overrated... just like you should use the right tool for the job, you should use the right paradigm for the job -- and sometimes that is somewhat subjective. As for C++ being dangerous: Sure it is... it makes no effort to hold your hand. If you or I, as programmers, mess up then it won't work properly... because we messed up. The idea is to learn the tools available, apply good design skills (and I tend to think at least some degree of creative intuition), and be careful. If something is broken, take responsibility and fix it. Java/C# have somewhat different approach... They are "safer" to work in as often times you won't go quite as humorously or terrifyingly wrong, and yet they somewhat restrict you from trying the crazy idea which later turns out to be brilliant, etc etc etc. Of course, many will disagree, that is fine. When it comes to it, C++ is just as valid a language as Java/C#/whatever depending on use, and on programmer comfort and preference.


good points there.
heres another one:
it does not force you to do things in a specifiec mannor, i can do thread however i want, or i can read files however i want.
but the down side is that there are a lot of ways to shoot yourself in the foot, but when you have learnt that shooting yourself in the foot is not the way forward you do it in a better way :)
[/quote]

To be honest, I give you the exact same advice I gave medevilenemy, you should probably familiarize yourself with other languages a bit more, as your examples make very little sense. To use your file reading example, as for example in C#, I can't think of a single way you couldn't read a file like you could in C++. I mean, if you want to read a file byte by byte, you can, if you want to read a file to a memory buffer, you can, hell if you want to pInvoke back to the Win32 apis for whatever bizarro reason you can think of... you can.

Really, and with complete sincerity, I recommend you try a couple other languages, instead of going by their "reputations". I believe it will be an eye opening experience for you. I am not saying you will quit being a C++ programmer after, but I almost guarantee you will be a better programmer after, regardless to which language you chose to go with.

Share this post


Link to post
Share on other sites

[quote name='return0' timestamp='1307320118' post='4819923']
Java really does suck though.


Why? I feel like most people says this but that language actually makes a lot of jobs easier. Sure there are a couple of things in Java thats 'weird', but I wouldn't go to say that java sucks. Its actually isn't thaaaat bad as people display it out to be. Maybe you can show me why exactly java sucks? Is it all the libraries it provides? Or the automatic garbage collection? Or all of the exception safety it has? Or all the libraries it provides? or all the libraries it provides? Or is it because its not manly enough?
[/quote]

It's needlessly verbose for a bog standard curly bracer, has a horrible 'enterprise' legacy, crappy lambda/closure constructs, sucky community. Occupies an awkward middle ground between c++ and c#. Not fun to use. Terrible for non strict oop paradigm stuff.

Share this post


Link to post
Share on other sites

[quote name='medevilenemy' timestamp='1307330294' post='4819962']
C++ takes a lot of heat because it doesn't conform to today's fad ideas of mainline programming (this is IMHO, of course :P) namely: Strict adherence to OOP principles, and type safety. C++ wasn't designed to be an OO language, but rather to give you the ability to write OO code if you chose to.


Um, yes it it was. C was designed EXACTLY to be an OO language. C++ actually started out being called C with Classes ( aka, objects ). The very first extensions to C++ were to support Object oriented programming on top of C. ( Originally C++ compiled down to C code ). [font="sans-serif"]Bjarne Stroustrup was heavily inspired by and accredits Simula as one of the major inspirations for C++. Now, one of the design tenants of C++, at least as it evolved, was to but a multi paradigm language, but then, the same can be said of C# ( which supports functional, procedural, object oriented and various other programming methodologies ) and a lesser degree to Java and various other languages. Few languages actually force you into a specific coding style, beyond the likes of smalltalk, LISP and other specialty languages.[/font]

[font="sans-serif"]
[/font]
It was not really written to be type safe because strictly enforcing type safety can limit programmers, to a certain degree.
[/quote]

None of our languages of preference are perfect, nor are we (certainly not me), but there is plenty to be learned from both the strengths and weaknesses of various languages. I mean simply to have us consider various languages and paradigms as equals as, honestly, language doesn't matter nearly so much as design skills and thinking both inside and outside the box.

Like what? What *good* programming practice does C++ lack of type safety enable it to perform, that a language such as C# cannot? [ There are a few answers, I'm curious to hear yours ]


It is a language of choice, designed to support multiple paradigms.
[/quote]

As explained earlier, this is by no means exclusively the domain of C++. Actually, in some areas, C++ is actually a very poor fit for some programming paradigms.


Honestly, I think pure OO and type safety are both overrated... just like you should use the right tool for the job, you should use the right paradigm for the job -- and sometimes that is somewhat subjective.
[/quote]

Really? Lets completely ignore the merits of object oriented programming for a second, which is a thread unto itself, but frankly you think type safety is overrated? Really?


As for C++ being dangerous: Sure it is... it makes no effort to hold your hand. If you or I, as programmers, mess up then it won't work properly... because we messed up. The idea is to learn the tools available, apply good design skills (and I tend to think at least some degree of creative intuition), and be careful. If something is broken, take responsibility and fix it. Java/C# have somewhat different approach... They are "safer" to work in as often times you won't go quite as humorously or terrifyingly wrong, and yet they somewhat restrict you from trying the crazy idea which later turns out to be brilliant, etc etc etc. Of course, many will disagree, that is fine. When it comes to it, C++ is just as valid a language as Java/C#/whatever depending on use, and on programmer comfort and preference.
[/quote]

If I can be completely honest for a moment, I highly recommend you take some time to familiarize yourself with some other languages. Some of your perceptions of different languages are just patently wrong, as are your understanding of the history and to a lesser degree, the merits of C++.

Had you mentioned portability as a strength, that I could understand. Had you mentioned 3rd party library support as a strength, that I could understand. Or the large repositories of code and the backward compatibility with C, that I could have understood. Had you mentioned performance as a strength, that I would have slightly disputed, but still it would be understandable. Yet almost every thing you did mention, to be completely honest, are the kind of things that one hears from another and puppets as truth.

Please don't take this as an insult or as an attack on C++, my intentions are good. It just seem so many people are working on bad supposition, and in the end that doesn't help anyone, especially when those suppositions are passed on generation after generation.
[/quote]


No need to be quite so rude, Serapth, we are all simply discussing opinions in good faith. I will not respond point for point except perhaps for a couple and to try to clarify my general meaning: I was not trying to say that OO and type safety are bad, or that C++ is the greatest thing ever, but rather that I don't think they are the greatest things ever. Focusing too much on any given paradigm or practice is limiting in that you box yourself up and won't necessarily think of alternate methods of doing things. For example, a messaging system. There are lots of ways to go about it, the general idea simply being to pass data/arguments in a type agnostic format as well as the context to decode the message on the far end (because different messages can, conceivably, need different types of arguments). You can do this lots of ways, from generics, to polymorphic wrappers, to string packing or even void pointers. There are pros and cons to each, with the void pointer method probably being the most sketchy from the perspective of type safety... but really, so long as you are careful and provide yourself appropriate context, even the void pointer method can be worked with relative ease.

On C++ design intentions, allow me to quote something (from the C++ man himself by way of wikipedia):
In The Design and Evolution of C++ (1994), Bjarne Stroustrup describes some rules that he used for the design of C++:[sup][page needed][/sup]

  • C++ is designed to be a statically typed, general-purpose language that is as efficient and portable as C
  • C++ is designed to directly and comprehensively support multiple programming styles (procedural programming, data abstraction, object-oriented programming, and generic programming)
  • C++ is designed to give the programmer choice, even if this makes it possible for the programmer to choose incorrectly
  • C++ is designed to be as compatible with C as possible, therefore providing a smooth transition from C
  • C++ avoids features that are platform specific or not general purpose
  • C++ does not incur overhead for features that are not used (the "zero-overhead principle")
  • C++ is designed to function without a sophisticated programming environment [/quote]The second point there is what I was attempting to express.... not that C++ wasn't intended to be useful for OOP, but rather that C++ wasn't intended to be solely OO... OO is simply a tool, albeit an important tool, in the C++ feature set. It is not the end-all be-all for programming nor is it the only valid way to approach all problems.

    Point three above is really the perfect overall statement -- As stated above... there are indeed plenty of ways to shoot yourself in the foot... the responsibility is the programmers to try not to do so, and to take responsibility if they accidently do.

Share this post


Link to post
Share on other sites

No need to be quite so rude, Serapth, we are all simply discussing opinions in good faith. I will not respond point for point except perhaps for a couple and to try to clarify my general meaning:


By no means was my intention to be rude, if it came across that way, I apologize. That said, my point had absolutely nothing to do with opinion, with the exception of my suggestions of course, I was simply addressing factual errors. I don't do this to be a dick, I do this to hopefully help you and more importantly, help others that might be reading your words. There are certain rather harmful stereotypes that are propagated about various programming languages and frankly this mis-information is harmful to new developers. All languages have their strengths and weaknesses, but they weren't properly represented in the earlier conversations.

EDIT, to address your direct points in your response:

[color="#1C2837"]Focusing too much on any given paradigm or practice is limiting in that you box yourself up and won't necessarily think of alternate methods of doing things. For example, a messaging system. There are lots of ways to go about it, the general idea simply being to pass data/arguments in a type agnostic format as well as the context to decode the message on the far end (because different messages can, conceivably, need different types of arguments). You can do this lots of ways, from generics, to polymorphic wrappers, to string packing or even void pointers. There are pros and cons to each, with the void pointer method probably being the most sketchy from the perspective of type safety... but really, so long as you are careful and provide yourself appropriate context, even the void pointer method can be worked with relative ease.[/quote]

[color="#1c2837"]I don't exactly understand what you are trying to say or more accurately, what point of mine you are trying to dispute. You are correct, you can address a message system using a variety of paradigms, sure... but this has absolutely nothing to do with C++. This is a big part of the reason I suggest you expose yourself to other languages, your wording seems to imply you think such actions are exclusive to the domain of C++, but not a thing you said heard wasn't equally applicable to C# or Java or various other general purpose languages. The flexibility your are attributing to C++ are by no means exclusive to C++! Actually with events and delegates, there are far superior ways to implement such a message system in other languages that wouldn't even come close to being as kludgey and error prone as a void pointer. Until you try other langauges of course, you aren't going to recognize the alternatives, nor the relative strengths and weaknesses of your chosen language.
[color="#1c2837"]
[color="#1c2837"]
[color="#1c2837"]
[color="#1C2837"]The second point there is what I was attempting to express.... not that C++ wasn't intended to be useful for OOP, but rather that C++ wasn't intended to be solely OO... OO is simply a tool, albeit an important tool, in the C++ feature set. It is not the end-all be-all for programming nor is it the only valid way to approach all problems.[/quote]
[color="#1C2837"]
[color="#1C2837"]Ok... ditto for Java and ditto for C# and ditto for Python, Pascal, D, Ruby, Javascript and various other general purpose languages. Not really sure again what point you are trying to dispute, in fact, you seem to be agreeing with me from what I can tell.

Share this post


Link to post
Share on other sites
For the benefit of people who aren't experienced in other languages, can you explain what you mean?

For example, from what I've seen of Java, I don't really see how it's designed for a non OOPS paradigm. The only thing I can think of is that Java has a primitive form of closures due to inner classes.

Share this post


Link to post
Share on other sites

[quote name='ryan20fun' timestamp='1307387852' post='4820217']
[quote name='medevilenemy' timestamp='1307330294' post='4819962']
C++ takes a lot of heat because it doesn't conform to today's fad ideas of mainline programming (this is IMHO, of course :P) namely: Strict adherence to OOP principles, and type safety. C++ wasn't designed to be an OO language, but rather to give you the ability to write OO code if you chose to. It was not really written to be type safe because strictly enforcing type safety can limit programmers, to a certain degree. It is a language of choice, designed to support multiple paradigms. Honestly, I think pure OO and type safety are both overrated... just like you should use the right tool for the job, you should use the right paradigm for the job -- and sometimes that is somewhat subjective. As for C++ being dangerous: Sure it is... it makes no effort to hold your hand. If you or I, as programmers, mess up then it won't work properly... because we messed up. The idea is to learn the tools available, apply good design skills (and I tend to think at least some degree of creative intuition), and be careful. If something is broken, take responsibility and fix it. Java/C# have somewhat different approach... They are "safer" to work in as often times you won't go quite as humorously or terrifyingly wrong, and yet they somewhat restrict you from trying the crazy idea which later turns out to be brilliant, etc etc etc. Of course, many will disagree, that is fine. When it comes to it, C++ is just as valid a language as Java/C#/whatever depending on use, and on programmer comfort and preference.


good points there.
heres another one:
it does not force you to do things in a specifiec mannor, i can do thread however i want, or i can read files however i want.
but the down side is that there are a lot of ways to shoot yourself in the foot, but when you have learnt that shooting yourself in the foot is not the way forward you do it in a better way :)
[/quote]

To be honest, I give you the exact same advice I gave medevilenemy, you should probably familiarize yourself with other languages a bit more, as your examples make very little sense. To use your file reading example, as for example in C#, I can't think of a single way you couldn't read a file like you could in C++. I mean, if you want to read a file byte by byte, you can, if you want to read a file to a memory buffer, you can, hell if you want to pInvoke back to the Win32 apis for whatever bizarro reason you can think of... you can.

Really, and with complete sincerity, I recommend you try a couple other languages, instead of going by their "reputations". I believe it will be an eye opening experience for you. I am not saying you will quit being a C++ programmer after, but I almost guarantee you will be a better programmer after, regardless to which language you chose to go with.
[/quote]

yes it proberbly was not the best example, but my point is that you can do it any way you want, in C# i found that certain stuff had to be done a certain way, wheres C++ does not really have a certain way of doing stuff.

Share this post


Link to post
Share on other sites

yes it proberbly was not the best example, but my point is that you can do it any way you want, in C# i found that certain stuff had to be done a certain way, wheres C++ does not really have a certain way of doing stuff.
[/quote]
Parse error at line 1. Still, inferring as best I can I think you are mistaken. A more accurate analysis is that modern languages give you really good support to lots of things, and the support encourages you to do things a certain way. C++ tends to give you little or no support, so people have gone and done things in many ways.

It is erroneous to go from there to the idea that C++ gives you more options - it does not. As a language, it gives you less options. The fact that library developers have improved the situation is irrelevant - the same could be done on managed languages like C#.

For example, C++ does not have any concept of threads*. As a result many libraries were created to rectify this. Modern managed languages such as C# have built-in threads, and give you tools designed to use them a certain way. They aren't always exhaustive (though they are certainly comprehensive). However, there is nothing stopping you from writing libraries for C# that do other things with threads. The fact that few exist owes mainly to how much you can do with the built-in support.

Replace "threads" with almost any other concept and the above statement is still usually true.

A notable exception might be 3D graphics. There were a number of abortive "official" attempts to add support for 3D graphics to managed languages like Java and C#. Most have failed (except for XNA - which isn't strictly 3D graphics so I'll ignore it). In the absence of built-in support, the communities involved have created libraries.

* [size="1"]Ignoring C++0x for the moment

Share this post


Link to post
Share on other sites


yes it proberbly was not the best example, but my point is that you can do it any way you want, in C# i found that certain stuff had to be done a certain way, wheres C++ does not really have a certain way of doing stuff.

Parse error at line 1. Still, inferring as best I can I think you are mistaken. A more accurate analysis is that modern languages give you really good support to lots of things, and the support encourages you to do things a certain way. C++ tends to give you little or no support, so people have gone and done things in many ways.

It is erroneous to go from there to the idea that C++ gives you more options - it does not. As a language, it gives you less options. The fact that library developers have improved the situation is irrelevant - the same could be done on managed languages like C#.

For example, C++ does not have any concept of threads*. As a result many libraries were created to rectify this. Modern managed languages such as C# have built-in threads, and give you tools designed to use them a certain way. They aren't always exhaustive (though they are certainly comprehensive). However, there is nothing stopping you from writing libraries for C# that do other things with threads. The fact that few exist owes mainly to how much you can do with the built-in support.

Replace "threads" with almost any other concept and the above statement is still usually true.

A notable exception might be 3D graphics. There were a number of abortive "official" attempts to add support for 3D graphics to managed languages like Java and C#. Most have failed (except for XNA - which isn't strictly 3D graphics so I'll ignore it). In the absence of built-in support, the communities involved have created libraries.

* [size="1"]Ignoring C++0x for the moment
[/quote]

Not strictly speaking true; the language spec for C# just defines the language itself, whereas threads are part of the .NET framework. In effect, support for threads is provided by a library (or at least by the .NET analogue of a library) although in practice one could be forgiven for seeing the lines as being a little blurred with this example.

Take graphics. The "attempts to add graphics to the language" were not actually adding graphics to the language at all either. Again, it's a .NET assembly (still assuming C#) which is the .NET analogue of a library.

Share this post


Link to post
Share on other sites

For the benefit of people who aren't experienced in other languages, can you explain what you mean?

For example, from what I've seen of Java, I don't really see how it's designed for a non OOPS paradigm. The only thing I can think of is that Java has a primitive form of closures due to inner classes.


Sure, but I am going to take the lazy way out. Let me present a list of languages/paradigms they support courtesy of the all knowing brain Wikipedia. Granted, there are some oddities on this list ( it treats generic and metaprogramming as different, and the same, depending on langauge and it massively sells javascript short, as prototype itself should be considered a paradigm IMHO, plus it is capable of metaprogramming ) but generally it is a good starting place. Also, it misses some completely.

Java is the goto language of corporate America and much of academia, so it is often the birthplace of new paradigms. Additionally, the Java ecosystem is startlingly capable of overcoming inherit flaws of the language. Java for example has taken service oriented programming to a new level. Aspect Oriented programming began life on Java for example.

Far be it from me to defend Java though, with the exception of some work with EDS in the past, some experimentation when Java was first released ( applets, like everyone else at the time ) and a brief foray into Android land I have minimal experience. I am by no means an expert in Java, so somebody else would probably be better served addressing this question in greater detail.

All told, I am actually not much of a Java fan. It is functionally similar enough to C# that I can work in it, but I find using it frustrating. Now, 95% of the time, if given the choice between C++ and Java, I would take Java, but 100% of the time if given the choice between C# and Java, I would take C#.

Share this post


Link to post
Share on other sites
Serapth,

Nice story. Really enjoyed it. For about 8 years I worked at a small-ish company never really feeling like a "real" programmer because 1) I didn't have a degree and 2) I was working in a small company and felt had I been "good enough" some larger corporation would want me. Recently I got into a larger corporation and noticed everyone was more or less just like me and that I had been a "real" programmer all along. :lol:

Very encouraging stuff!

Share this post


Link to post
Share on other sites

C# sucks because it prevents you from getting down-n-dirty with the bits and bytes when you need to.

:huh:

Negative!! Unsafe code to the rescue.

Share this post


Link to post
Share on other sites

Not strictly speaking true; the language spec for C# just defines the language itself, whereas threads are part of the .NET framework. In effect, support for threads is provided by a library (or at least by the .NET analogue of a library) although in practice one could be forgiven for seeing the lines as being a little blurred with this example.

Take graphics. The "attempts to add graphics to the language" were not actually adding graphics to the language at all either. Again, it's a .NET assembly (still assuming C#) which is the .NET analogue of a library.


The language spec provides definition for the lock statement, which does rely upon the .NET framework to implement the critical section, but is also part of the language proper. But let's be honest here, C++'s standard library doesn't even have a concept of threads (C++0x not withstanding).

Share this post


Link to post
Share on other sites
What about Boost? It seems to me that it's popular enough to practically be a standard, and some parts are being added in C++0x.

Share this post


Link to post
Share on other sites

[quote name='rip-off' timestamp='1307443994' post='4820463']

yes it proberbly was not the best example, but my point is that you can do it any way you want, in C# i found that certain stuff had to be done a certain way, wheres C++ does not really have a certain way of doing stuff.

Parse error at line 1. Still, inferring as best I can I think you are mistaken. A more accurate analysis is that modern languages give you really good support to lots of things, and the support encourages you to do things a certain way. C++ tends to give you little or no support, so people have gone and done things in many ways.

It is erroneous to go from there to the idea that C++ gives you more options - it does not. As a language, it gives you less options. The fact that library developers have improved the situation is irrelevant - the same could be done on managed languages like C#.

For example, C++ does not have any concept of threads*. As a result many libraries were created to rectify this. Modern managed languages such as C# have built-in threads, and give you tools designed to use them a certain way. They aren't always exhaustive (though they are certainly comprehensive). However, there is nothing stopping you from writing libraries for C# that do other things with threads. The fact that few exist owes mainly to how much you can do with the built-in support.

Replace "threads" with almost any other concept and the above statement is still usually true.

A notable exception might be 3D graphics. There were a number of abortive "official" attempts to add support for 3D graphics to managed languages like Java and C#. Most have failed (except for XNA - which isn't strictly 3D graphics so I'll ignore it). In the absence of built-in support, the communities involved have created libraries.

* [size="1"]Ignoring C++0x for the moment
[/quote]

Not strictly speaking true; the language spec for C# just defines the language itself, whereas threads are part of the .NET framework. In effect, support for threads is provided by a library (or at least by the .NET analogue of a library) although in practice one could be forgiven for seeing the lines as being a little blurred with this example.

Take graphics. The "attempts to add graphics to the language" were not actually adding graphics to the language at all either. Again, it's a .NET assembly (still assuming C#) which is the .NET analogue of a library.
[/quote]

This is like saying iostream isn't part of C++ because it is provided by a library. Threading is a core part of the .NET library, and is part of the language spec.

It's a bit confusing by the naming conventions used, but C# is covered by ECMA-335 ( warning, 8MB PDF link! ) Its partition 4, section 5.3 that is most relevant, which addresses the Base Class Library, which primarily composes the standard library ( and is implemented by Mono ) and is unencumbered by patents. Anyways, you will notice System.Threading is part of the BCL.

Keep in mind, the .NET framework is an implementation of ECMA-335, plus some libraries which are not included ( WinForms & ASP.NET being most prominent ).


Anyways, the .NET equivalent of the C++ Standard libraries very much DO include threading. Plus as Telastyn stated, the language includes the lock keyword.


EDIT: For clarity, the 'language' itself is covered by ECMA-334.

Share this post


Link to post
Share on other sites

What about Boost? It seems to me that it's popular enough to practically be a standard, and some parts are being added in C++0x.


I think I would have gone with pthreads before boost when talking about standards.

Share this post


Link to post
Share on other sites

Not strictly speaking true; the language spec for C# just defines the language itself, whereas threads are part of the .NET framework. In effect, support for threads is provided by a library (or at least by the .NET analogue of a library) although in practice one could be forgiven for seeing the lines as being a little blurred with this example.

Take graphics. The "attempts to add graphics to the language" were not actually adding graphics to the language at all either. Again, it's a .NET assembly (still assuming C#) which is the .NET analogue of a library.
[/quote]
C# is thread aware, the language spec makes references to threads, even if the language itself doesn't provide the ability to create/manipulate them. It is necessary for defined memory semantics when threads are created. Yes, graphics is more obviously external, I did put official in quotes though.

Point taken, but for the purposes of the debate I'm not particularly bothered with this distinction.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement