• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Serapth

So you want to be a real programmer?

61 posts in this topic

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! :)
0

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
0

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.
[/quote]

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 :)
1

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1307380853' post='4820175']
C++ sucks because of it's (lack of) memory management and arcane syntactical constructs.
[/quote]

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

[quote name='mhagain' timestamp='1307380853' post='4820175']
C# sucks because it prevents you from getting down-n-dirty with the bits and bytes when you need to.
[/quote]

then learn C/C++

[quote name='mhagain' timestamp='1307380853' post='4820175']
VB sucks because of it's overly-verbose syntax.
[/quote]

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

[quote name='mhagain' timestamp='1307380853' post='4820175']
Scripting languages suck because the performance needed just isn't there.
[/quote]

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

[quote name='mhagain' timestamp='1307380853' post='4820175']
COBOL sucks because ... well... ADD SUCK TO COBOL, MOVE COBOL TO SUCK PILE ... it's COBOL.
[/quote]

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

[quote name='mhagain' timestamp='1307380853' post='4820175']
Java sucks because it's a pain in the butt for deployment to non-technical users.
[/quote]

well, thats where all the fun is :cool:
-5

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.
[/quote]

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"][size="2"]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.[/size][/font]
[font="sans-serif"] [/font]
[font="sans-serif"][size="2"][quote][/size][/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 ]

[quote]
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.

[quote]
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?

[quote]
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.
0

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.
[/quote]

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.
2

Share this post


Link to post
Share on other sites
[quote name='D.Chhetri' timestamp='1307321177' post='4819928']
[quote name='return0' timestamp='1307320118' post='4819923']
Java really does suck though.
[/quote]

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.
0

Share this post


Link to post
Share on other sites
[quote name='Serapth' timestamp='1307390091' post='4820232']
[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.
[/quote]

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"][size="2"]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.[/size][/font]

[font="sans-serif"][size="2"][quote][/size][/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 ]

[quote]
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.

[quote]
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?

[quote]
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 [i]they[/i] 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):
[quote]In [i][url="http://en.wikipedia.org/wiki/The_Design_and_Evolution_of_C%2B%2B"]The Design and Evolution of C++[/url][/i] (1994), Bjarne Stroustrup describes some rules that he used for the design of C++:[sup][[i][url="http://en.wikipedia.org/wiki/Wikipedia:Citing_sources"]page needed[/url][/i]][/sup]

[list][*]C++ is designed to be a [url="http://en.wikipedia.org/wiki/Statically_typed"]statically typed[/url], general-purpose language that is as efficient and portable as C[*]C++ is designed to directly and comprehensively support multiple programming styles ([url="http://en.wikipedia.org/wiki/Procedural_programming"]procedural programming[/url], [url="http://en.wikipedia.org/wiki/Data_abstraction"]data abstraction[/url], [url="http://en.wikipedia.org/wiki/Object-oriented_programming"]object-oriented programming[/url], and [url="http://en.wikipedia.org/wiki/Generic_programming"]generic programming[/url])[*]C++ is designed to give the [url="http://en.wikipedia.org/wiki/Programmer"]programmer[/url] 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 [url="http://en.wikipedia.org/wiki/Computational_overhead"]overhead[/url] for features that are not used (the "zero-overhead principle")[*]C++ is designed to function without a sophisticated programming environment [/quote][/list]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.
0

Share this post


Link to post
Share on other sites
[quote name='medevilenemy' timestamp='1307411153' post='4820334']
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:
[/quote]

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:

[quote][color="#1C2837"][size="2"]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][/size][/color]
[size="2"] [/size]
[color="#1c2837"][size="2"]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.[/size][/color]
[color="#1c2837"] [/color]
[color="#1c2837"] [/color]
[color="#1c2837"][size="2"][quote][/size][/color][color="#1C2837"][size="2"]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][/size][/color]
[color="#1C2837"] [/color]
[color="#1C2837"][size="2"]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.[/size][/color]
0

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.
1

Share this post


Link to post
Share on other sites
[quote name='Serapth' timestamp='1307390507' post='4820236']
[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.
[/quote]

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.
-3

Share this post


Link to post
Share on other sites
[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.
[/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 [b]less options[/b]. 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[/size]
0

Share this post


Link to post
Share on other sites
[quote name='rip-off' timestamp='1307443994' post='4820463']
[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.
[/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 [b]less options[/b]. 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[/size]
[/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.
0

Share this post


Link to post
Share on other sites
[quote name='Storyyeller' timestamp='1307419897' post='4820381']
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.
[/quote]

Sure, but I am going to take the lazy way out. Let me [url="http://en.wikipedia.org/wiki/List_of_multi-paradigm_programming_languages"]present a list of languages/paradigms they support[/url] 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. [url="http://en.wikipedia.org/wiki/Aspect-oriented_programming"]Aspect Oriented programming[/url] 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#.
0

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!
0

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1307380853' post='4820175']
C# sucks because it prevents you from getting down-n-dirty with the bits and bytes when you need to.
[/quote]
:huh:

Negative!! Unsafe code to the rescue.
1

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1307454335' post='4820506']
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]

The language spec provides definition for the lock statement, which [b]does [/b]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 [b]standard library[/b] doesn't even have a concept of threads (C++0x not withstanding).
0

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.
0

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1307454335' post='4820506']
[quote name='rip-off' timestamp='1307443994' post='4820463']
[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.
[/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 [b]less options[/b]. 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[/size]
[/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 [url="http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf"]ECMA-335[/url] ( warning, 8MB PDF link! ) Its partition 4, section 5.3 that is most relevant, which addresses the [url="http://en.wikipedia.org/wiki/Base_Class_Library"]Base Class Library[/url], 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.
0

Share this post


Link to post
Share on other sites
[quote name='Storyyeller' timestamp='1307456098' post='4820517']
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.
[/quote]

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

Share this post


Link to post
Share on other sites
[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]
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.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0