Shining examples of C++



  • I'm a long-time lurker of this forum and have found myself in need of some advice.

    I will be starting a rather challenging C++ project soon (few months away). However, my C++ skills are a bit rusty. I have been working in Java, primarily, for the last few years, and am quite competent in the language. I can read C++ with no difficulty at all (and often have to), but have not written any serious C++ in a few years.

     I think the best way to refresh myself would be to download an OpenSource C++ project, thoroughly investigate and map the codebase, and refresh my skills by extending it in some non-trivial way. I am also interested in learning the Boost library.

    I am looking for suggestions on which OpenSource project to tinker with. Ideally, it would fulfill the following:

    * Competent and appropriate use of standard design patterns 

    * Heavy but appropriate use of the Boost library

    * Moderate-sized codebase (I only have a few months, and am doing this in my spare time)

    * Hopefullly, an active community so that I can ask questions if I get stuck

    * Preferably Windows compatible without too much wrestling with the code

    If anyone knows of some OpenSource C++ projects that satisfy the bulk of the above I would greatly appreciate your suggestion. 



  • @variableName said:

    * Competent and appropriate use of standard design patterns

    "Design patterns" are a java-ism; they mean either "thing that should have been in the standard library, but isn't for no good reason", or "limitation of the language that you have to work around", or "bloody obvious approach to a trivial problem", in descending order of frequency.



  • @asuffield said:

    @variableName said:

    * Competent and appropriate use of standard design patterns

    "Design patterns" are a java-ism; they mean either "thing that should have been in the standard library, but isn't for no good reason", or "limitation of the language that you have to work around", or "bloody obvious approach to a trivial problem", in descending order of frequency.

     

    Design patterns do usually mean something like that, but I don't see how you can they're a java-ism when they predate java.

     http://en.wikipedia.org/wiki/Design_Patterns


     



  • @Licky Lindsay said:

    @asuffield said:
    @variableName said:

    * Competent and appropriate use of standard design patterns

    "Design patterns" are a java-ism; they mean either "thing that should have been in the standard library, but isn't for no good reason", or "limitation of the language that you have to work around", or "bloody obvious approach to a trivial problem", in descending order of frequency.

    Design patterns do usually mean something like that, but I don't see how you can they're a java-ism when they predate java.

     http://en.wikipedia.org/wiki/Design_Patterns

    The book alone is insignificant. What counts is the large crowd of people waving it in the air. They're all java nuts.



  • You forgot to ask for a pony.



  • The only thing you need to know about C++ is that C is better.



  • "Design patterns" are much larger than Java and most modern C++ libraries use them to some degree.

    *Iterators and Visitors (STL makes heavy use)

    *Delegates and Publish/Subscribe (any GUI toolkit)

    *AbstractFactory (anything that needs platform-specific implementations with platform-neutral interfaces)

    Labeling "Design Patterns" as a Java-centric concept is just wrong. The Java class library is merely consistent in calling instances of patterns by the names set forth in the GoF text. The idea that they are obvious or trivial solutions is readily contradicted by the content of this entire site. I suggest you read the GoF text. All of the patterns are presented in Smalltalk/C++. "Design Patterns" are important because they give software designers a common vocabulary to talk about behavioral structures independent of the implementation language.

    I think everyone is a better software designer for reading the GoF text, but maybe I'm biased because I had Ralph Johnson as a professor and he always made a very persuasive argument for their importance during lecture (much better than I could manage here).

     I'm surprised asuffield, usually your posts are much higher quality than snarky gibes.

     



  • Yeah asuffield, why the pattern-bashing?? I was also very surprised.



  • There's a good point here, is there a good intro or walkthrough for the most-popular Boost libraries?  I can't just start hacking it into a project, I'd like to do some sandbox coding with it first

    It seems like their site documentation is pretty much "Here's a bunch of crap, have fun!"  It looks like there's a TON of stuff there and it's probably something that C++ desperately needs (not for every project, but many of them)...but I'm just not sure where to start.

    edit: Okay, there's http://www.boost.org/libs/libraries.htm -- it seems pretty well organized.  I guess you just have to pick what you need and learn from there.

     



  • @asuffield said:

    "Design patterns" are a java-ism; they mean either "thing that should have been in the standard library, but isn't for no good reason",

    Some patterns (i.e. iterator) already made it into the standard library or even the syntax


    or "limitation of the language that you have to work around"

    even if the language includes them as a new feature, the pattern still exists 

     

    or
    "bloody obvious approach to a trivial problem"

    That's no surprise. Design patterns describe often used approaches to solve common problems. They do not have to be very complex or ingenious. (If they were, they would rather fall into the "algorithm" category)

    Design patterns are valueable because IMO a) developers now have names for those solutions and b) less experienced developers can learn how to do that, and what the advantages and limits of each pattern are
     



  • @ammoQ said:

    @asuffield said:

    "Design patterns" are a java-ism; they mean either "thing that should have been in the standard library, but isn't for no good reason",

    Some patterns (i.e. iterator) already made it into the standard library or even the syntax

    Actually, that one is documentation of pre-existing library features. I believe iterators originated in the Smalltalk library, but I'm not completely sure - it might have been Ada. Most of the things in this category originated in a standard library for some language other than the one the author is currently using.


    or "limitation of the language that you have to work around"

    even if the language includes them as a new feature, the pattern still exists 

    Something like 'delegation' or 'decoration' is unnecessary in a language that permits call-site modification of code, like ruby (where it is common practice to add your own methods to the standard classes).

    The "object pool" pattern is a workaround for impure languages with slow object allocation; in a pure functional language like Haskell, it has no relevance or purpose, since there is no object allocation at all.

    There's a whole bunch of "patterns" that fall into this category - a differently designed language, like (for example) Haskell or Prolog, completely obliterates any need or meaning for them.

     

    Design patterns are valueable because IMO a) developers now have names for those solutions and b) less experienced developers can learn how to do that, and what the advantages and limits of each pattern are 

    This kind of lego-brick thinking is counter-productive. Software cannot be decomposed into a set of discrete components that you can name, and attempting to do so merely leaves you unprepared for the highly fluid nature of non-trivial design work.

    There are no intrinsic 'advantages' and 'limitations' - they're things which were made up along with the brick itself. Any or all of them can be moved, eliminated, or worked around as necessary. Teaching people about bricks just means that later they're going to have to make the very difficult leap to realising that there are no bricks. This does not make somebody a better programmer.

    I have lost count of the number of times I've seen some Java nut do things in a sub-optimal way, and when you point out to them how it could be done better, they just look at you blankly and say "that's not how the pattern works".

    Software development is not a sack of lego bricks. It's a way of thinking. 



  • @asuffield said:

     

    The "object pool" pattern is a workaround for impure languages with slow object allocation; in a pure functional language like Haskell, it has no relevance or purpose, since there is no object allocation at all.

    This statement seems extremely narrow minded. "Object pools" are mostly used for objects that are inherently slow to allocate and/or resource intensive, like database connections. It's not a limitation of Java that it takes (say) 1.5 secs and 5MB RAM to open a connection to a database server.

     

    There's a whole bunch of "patterns" that fall into this category - a differently designed language, like (for example) Haskell or Prolog, completely obliterates any need or meaning for them.

    Of course. That's because design patterns are described in the context of object oriented programming.

     

    This kind of lego-brick thinking is counter-productive. Software cannot be decomposed into a set of discrete components that you can name, and attempting to do so merely leaves you unprepared for the highly fluid nature of non-trivial design work.

    There are no intrinsic 'advantages' and 'limitations' - they're things which were made up along with the brick itself. Any or all of them can be moved, eliminated, or worked around as necessary. Teaching people about bricks just means that later they're going to have to make the very difficult leap to realising that there are no bricks. This does not make somebody a better programmer.

    I have lost count of the number of times I've seen some Java nut do things in a sub-optimal way, and when you point out to them how it could be done better, they just look at you blankly and say "that's not how the pattern works".

    Software development is not a sack of lego bricks. It's a way of thinking. 

    SW Developers must be aware that reasonably complex software cannot be entirely composed of standard lego bricks. On the other side, for many routine tasks, those lego bricks are suitable. Since many programmers use those bricks anyway, why not give them a name?



  • @ammoQ said:

    Of course. That's because design patterns are described in the context of object oriented programming.

    All of the patterns?

    Nah.

    But this thread is derailing a little. The OP must wonder what the fuck he stumbled in to. Ask a simple question and these academic bastards run with it.



  • @dhromed said:

    @ammoQ said:

    Of course. That's because design patterns are described in the context of object oriented programming.

    All of the patterns?

    Nah.

    But this thread is derailing a little. The OP must wonder what the fuck he stumbled in to. Ask a simple question and these academic bastards run with it.

    At least the GoF book is named "Design Patterns - Elements of Reusable Object-Oriented Software" (emphasis mine)

    But of course some patterns are usefull in other paradigms also; and I see no reason why design patterns should not exist in Prolog or Lisp programs. 



  • In my original post I did not mean "Design Patterns" in the strictly GoF sense.

    Design Patterns are much bigger than that and there are thousands of them. Something like using a lock file as a mutex across process boundaries is a design pattern. I simply meant that I was looking for a project that is not full of WTF's. If an application has been implemented using well-known solutions to common problems (i.e. Design Patterns) then you can be reasonably sure of several things:

    * It has at least a few seasoned, competent developers

    * It probably does not suffer terribly from the NIH syndrome

    * The developers at least put some thought into the problems they're solving, and recognized it has a well-known solution

     

     This was the main reason I included the "Design Pattern" bullet. I am looking for a project that has been coded to some reasonable standard.

    I'd rather not spend all of my time lost in a maze of spaghetti. I didn't know it would spark a debate on what is or is not a Design Pattern and their merits.  

    If removing the Design Pattern bullet makes it any easier to answer the original post then just ignore it.

    But I'd still like some suggestions in response to my original post.

     



  • @variableName said:

    But I'd still like some suggestions in response to my original post.

    Sorry, but your thread has already been captured. Better start a new one. 



  • @variableName said:

    Design Patterns are much bigger than that and there are thousands of them. Something like using a lock file as a mutex across process boundaries is a design pattern.

    If you were to figure out what you meant by that, you would find that you're defining "design pattern" as simply "a thing". A category that encompasses the entire world is not particularly interesting.



  • @ammoQ said:

    @variableName said:

    But I'd still like some suggestions in response to my original post.

    Sorry, but your thread has already been captured. Better start a new one. 

    Yeah, you're probably right. Guess I'll just have to search around on my own. For how long I've been reading this forum I really should have expected this.



  • @variableName said:

    For how long I've been reading this forum I really should have expected this.

    I'm an upstanding member of the community and would like to inquire as to the smiley that comes after that:

    A) :</p>

    B) :)

    C) :D

    :D) >:*(

    E:) :&!

    @asuffield said:

    @variableName said:

    Design Patterns are much bigger than that and there are thousands of
    them. Something like using a lock file as a mutex across process
    boundaries is a design pattern.

    If you were to
    figure out what you meant by that, you would find that you're defining
    "design pattern" as simply "a thing". A category that encompasses the
    entire world is not particularly interesting.

    Agreed. If you start doing that you might as well call "using variables" a design pattern.

    Maybe I swing the other way too far, but it seems to me that "design pattern" has as little value as "interpreted language". Just write the damn code.



  • @asuffield said:

    @variableName said:

    Design Patterns are much bigger than that and there are thousands of them. Something like using a lock file as a mutex across process boundaries is a design pattern.

    If you were to figure out what you meant by that, you would find that you're defining "design pattern" as simply "a thing". A category that encompasses the entire world is not particularly interesting.

    I'm gonna disagree with you on that. That example is specific to software development, commonly used, and rather elegant in that it leverages the OS to eliminate race conditions and provide mutual exclusion. I will concede that it is not an "Object-oriented Design Pattern" and was perhaps a bad example to use in this context.

    In the GoF text they compare software design patterns to those found in structural engineering. For example, the problem of distributing the load of a roof to the walls.

    There are lots of ways to do it.

    Yeah, you could put any "thing" there to transfer the force, but there are accepted structures that perform the job efficiently (arches, trusses, etc.)

    And it's obvious you're flailing in your argument since you've progressed as follows:

    *Attacking "Design Patterns" as a "Java-ism" (a clear indication that you don't actually have a clear idea of what they are)

    *Attacking Object-Oriented "Design Patterns" by noting their uselessness in the context of Haskell (bravo)

    *Attacking a specific example I gave (albeit, perhaps a an ill-suited one) to shift the argument into a semantics debate after I had explained I had used the term in a wider sense than the original GoF text.

    There is no cohesive thrust to your arguments and I don't see you adding any kind of useful information to this discussion.

    I'd just like to reiterate that I have been kind of disappointed by your posts in this thread. I've come to expect your posts to be more informative and insightful than most.



  • @dhromed said:

    Agreed. If you start doing that you might as well call "using variables" a design pattern.

    Maybe I swing the other way too far, but it seems to me that "design pattern" has as little value as "interpreted language". Just write the damn code.

    Design patterns have received a lot of hype during the last years, and some people might even mistake them as some kind of technology. Anyway, in a reasonable context, design patterns are valueable and "interpreted language" has a meaning (as in "a language that in most real-world cases runs in an interpreter") 



  • @variableName said:

    *Attacking "Design Patterns" as a "Java-ism" (a clear indication that you don't actually have a clear idea of what they are)

    They're a concept proposed in a book that only achieved significant popularity with java nuts, and never really achieved any with the C++ crowd. Hence, they are a java-ism. Any time you find somebody running their mouth about "design patterns", it's a safe bet that they're a java nut.


    *Attacking Object-Oriented "Design Patterns" by noting their uselessness in the context of Haskell (bravo)

    I described that group as "limitation[s] of the language that you have to work around". Calling them 'Object-Oriented "Design Patterns"' does not excuse them just because they're limitations that are present in C++, Java, and Smalltalk. Their uselessness in the context of languages without those limitations would be the whole point, since it exposes them as nothing more than workarounds.

    Also, everybody who writes significant amounts of Haskell code writes 'object-oriented' code - hence, it's not even a limitation of a design style, it's just a limitation of C++, Java, and Smalltalk.

     

    *Attacking a specific example I gave (albeit, perhaps a an ill-suited one) to shift the argument into a semantics debate after I had explained I had used the term in a wider sense than the original GoF text.

    When you start redefining terms, you should expect people to challenge it, particularly if your redefinitions don't make any real sense.

    Also, you should consult a dictionary on the meaning of the words "semantics" and "debate". One post is not a "debate". Redefining a term is not "semantics". 



  • @asuffield said:

    @variableName said:

    *Attacking "Design Patterns" as a "Java-ism" (a clear indication that you don't actually have a clear idea of what they are)

    They're a concept proposed in a book that only achieved significant popularity with java nuts, and never really achieved any with the C++ crowd. Hence, they are a java-ism. Any time you find somebody running their mouth about "design patterns", it's a safe bet that they're a java nut.

    They are popular in the .net world also. Though .net (read: C#) is not too different from Java ;-) 




  • The way this thread is going, we might as well just start with conservation of mass, charge, momentum, and energy and re-derive everything from first principles.

     

    ;-)





  • @asuffield said:

    They're a concept proposed in a book that only achieved significant popularity with java nuts, and never really achieved any with the C++ crowd. Hence, they are a java-ism. Any time you find somebody running their mouth about "design patterns", it's a safe bet that they're a java nut.

    I don't consider myself a Java nut. As a language it's not great, but the standard class library makes it useable.

    The fact that the "Design Pattern" movement never gained significant ground in the C++ world doesn't change the fact that many C++ libraries make abundant use of them, even if they are not identified with the names set forth in the GoF text. The original text heavily cites libraries written in C/C++ as the basis for the patterns included in the book. The book does not purport to have invented any of the patterns presented, in fact it clearly states this several times, it is merely an attempt to catalog some of the most useful and abundant patterns.

    @asuffield said:


    I described that group as "limitation[s] of the language that you have to work around". Calling them 'Object-Oriented "Design Patterns"' does not excuse them just because they're limitations that are present in C++, Java, and Smalltalk. Their uselessness in the context of languages without those limitations would be the whole point, since it exposes them as nothing more than workarounds.

    Also, everybody who writes significant amounts of Haskell code writes 'object-oriented' code - hence, it's not even a limitation of a design style, it's just a limitation of C++, Java, and Smalltalk.


    Yes, and in a perfect world we could all work in whatever language we want.

    But we can't.

    Calling them "language limitations" doesn't negate the fact that when working in a specific language it is helpful to have a catalog of "work-arounds" to accomplish tasks that come up over and over. The use of patterns from these catalogs shows that the designers recognized the problem and applied a standard solution, as all good designers should.  Solving the same problem using different methodologies each time is a sure WTF factory. Your Haskell example is not helpful or pertinent because it is not addressing the language I originally specified, i.e. C++. 

    It essentially amounts to "Pfffft, C++ is fer LuZerS, USE HASKELL !!!!1111"

    Also, I apologize for my snarky comment to your Haskell suggestion.

    @asuffield said:

    When you start redefining terms, you should expect people to challenge it, particularly if your redefinitions don't make any real sense.

    Also, you should consult a dictionary on the meaning of the words "semantics" and "debate". One post is not a "debate". Redefining a term is not "semantics". 

    I used the word "semantics" appropriately:

    the meaning, or an interpretation of the meaning, of a word, sign, sentence, etc

    You seemed to be shifting the discussion towards what the phrase "Design Pattern" means. The problem here is that even in the GoF text the definition given is fairly nebulous.

    After examining what I had previously written, you are probably correct in that I was on shaky ground using the term that broadly.

    Perhaps "Software Design Conventions" is more to your liking. But that term is equally nebulous. There is no widely-used term (at least that I know of) that captures the idea of a "behavioral structure in software" that is as well-known as "Design Pattern". 

    If you know of such a term I would appreciate your input so that this doesn't happen again.

    Just out of curiosity, have you ever read the GoF text?

     

     

     



  • Maybe the debate is about what encompasses the term "design patterns". In my world, they are a way of communicating good praxis to newcomers and also a way of sharing ideas. If we take GOF patterns as examples, Prototype tells you that cloning might be a better approach if you have complex, context-based initialization problems. Visitor tells you that moving the operator around can be better than moving the operand, Observer teaches a publish-subscribe approach, etc etc.

    Now, one _could_ argue that all these pattern are no longer patterns if they are integrated into the language. If you can do runtime renaming of methods, Adapter would be useless. If you can have static classes, singleton is useless. However, my strong belief  is that unless the programmer is aware of how to use these features, he/she either don't touch them, or uses them in a completely stupid way. For instance, how many newbie coders use function pointers in C? How many newbie java coders use anonymous inner classes? How many newbie python coders uses anonymous functions and fancy stuff like reduce and the built in visitor thingy for lists? That's right, almost noone. So design patterns are really about communicating these ideas and to show _examples_ on how to implement them.

     The principles of coding needs to be taught. Of course mutexes and other basic stuff are obvious to experienced programmers, but they are still important, well-documented, proven solutions to real problems. Now this can be taught in several ways, but I believe that design patterns have helped to communicate these solutions in a good way. I for one completely changed coding style after seeing the strengths of some of these patterns, and realizing how narrow-minded is was before I encountered them. Now, assufield,  saying that design-patterns are simple solutions to obvious problems is basically saying that you already used and acknowledged these solutions. Well maybe you should write a new book about your über-patterns then :D

     



  • @Obfuscator said:

    Now, assufield,  saying that design-patterns are simple solutions to obvious problems is basically saying that you already used and acknowledged these solutions. Well maybe you should write a new book about your über-patterns then :D

    You seem to have missed my earlier point - showing people some basic solutions to common problems does not teach them how to create software. They learn nothing unless they develop the ability to construct those solutions themselves. A person who is not capable of finding them is a failure as a developer, and the kind of deadweight that the real developers have to work around.

    It would be like a math textbook that consisted only of solutions to exercises. You don't learn how to solve complex problems by looking at the answers to simple ones.



  • @asuffield said:

    You seem to have missed my earlier point - showing people some basic solutions to common problems does not teach them how to create software. They learn nothing unless they develop the ability to construct those solutions themselves. A person who is not capable of finding them is a failure as a developer, and the kind of deadweight that the real developers have to work around.

    I don't think anyone here is arguing that *just* knowing design patterns is going to make someone a good developer. We are arguing that having a good understanding of common design patterns can make people better developers. There is no reason for everyone to rediscover well-known solutions to common problems on their own. Additionally, having a working knowledge of standard design patterns makes it easier to recognize when you run into a truely unique situation. 

    @asuffield said:

    It would be like a math textbook that consisted only of solutions to exercises. You don't learn how to solve complex problems by looking at the answers to simple ones.

    I think this is a bad analogy.

    Design patterns are general enough for application to many instances of a specific problem.

    In the math analogy, a design pattern would be closer to something like the quadratic formula. It's very good for doing a specific job, finding the roots of 2nd degree polynomials. Its derivation is obvious to someone who has an understanding of algebra, but to someone who is just starting to learn algebra it is anything but obvious. Knowing it doesn't make you a mathematician, but try and find one that doesn't know it by heart.

    Every algebra course teaches the quadratic formula because it is a useful tool to have in your mathematics toolbox, just like a solid understanding and working knowledge of common design patterns is a nice addition to any developer's mental toolbox.

     

    I don't understand why you are arguing against knowledge.



  • @variableName said:

    There is no reason for everyone to rediscover well-known solutions to common problems on their own.

    Go and say that to any professor of mathematics. (If they snigger and walk away, try some others until one of them delivers a lecture on the subject)

    In the math analogy, a design pattern would be closer to something like the quadratic formula. It's very good for doing a specific job, finding the roots of 2nd degree polynomials. Its derivation is obvious to someone who has an understanding of algebra, but to someone who is just starting to learn algebra it is anything but obvious. Knowing it doesn't make you a mathematician, but try and find one that doesn't know it by heart.

    Every algebra course teaches the quadratic formula because it is a useful tool to have in your mathematics toolbox, just like a solid understanding and working knowledge of common design patterns is a nice addition to any developer's mental toolbox.

    Every halfway decent course teaches students how to derive the quadratic formula. They don't simply present students with it and say "this is how you solve a quadratic equation", they spend a considerable amount of time teaching them how to factor quadratics by hand, how to find the roots by completing the square, and how to generalise this into the formula. They do all this because it enables you to solve problems other than finding the roots to pure quadratics (which is the only thing that the formula can do).


    I don't understand why you are arguing against knowledge.

    Do you understand why students are taught how to do math, rather than handed a copy of the exam solutions and told to memorise them? The solutions are knowledge.



  • @asuffield said:

    Go and say that to any professor of mathematics. (If they snigger and walk away, try some others until one of them delivers a lecture on the subject)

    I wasn't suggesting that discovering solutions on your own isn't valuable. I am a big fan of exercises "left to the reader."

    @asuffield said:

     

    Every halfway decent course teaches students how to derive the quadratic formula. They don't simply present students with it and say "this is how you solve a quadratic equation", they spend a considerable amount of time teaching them how to factor quadratics by hand, how to find the roots by completing the square, and how to generalise this into the formula. They do all this because it enables you to solve problems other than finding the roots to pure quadratics (which is the only thing that the formula can do).

    Again, I wasn't suggesting that an algebra course just present students with the quadratic formula and tells them that they now know algebra. Of course "teaching" the quadratic equation encompases its derivation, application, theoretical basis, etc. It's merely a building block in a much larger process.

    You seem to think that design patterns are taught in isolation, that people are taught design patterns and then ordained as developers. This is certainly not the case. In most universities "Design Patterns" is a senior or graduate level course, taught only after students have had a lot of exposure to different programming methodologies. Teaching design patterns encompasses their theoretical basis, analysis of performance and scalability, etc.

    You never answered my question as to whether or not you have ever read the GoF text (or any serious work concerning design patterns). I'm going to take that as a no.

    I'll do you the same courtesy you did me, and extend your argument to absurdity:

    "Let's not teach anyone any knowledge ever learned by anyone else, because if you teach someone something you're robbing them of their ability to think."

    You have an axe to grind against "Design Patterns" for some unknown reason. Maybe it's because you never had much exposure to them, and feel you have to downplay any significance they might have. I don't know.



  • Showing people good ways to solve common problems at least should teach them not to invent inferior solutions to those problems. Just like you teach quicksort so people do not reinvent and use the more obvious bubble sort algorithm.

    Of course programmers should be able to find good solutions by themself, but some patterns like "Visitor" are not too obvious. And I can only reiterate, even for an experienced developers who have already used those patterns without knowing that they are considered patterns, it improves communication if they have a common name for those patterns.



  • @variableName said:

    You seem to think that design patterns are taught in isolation, that people are taught design patterns and then ordained as developers. This is certainly not the case. In most universities "Design Patterns" is a senior or graduate level course, taught only after students have had a lot of exposure to different programming methodologies. Teaching design patterns encompasses their theoretical basis, analysis of performance and scalability, etc.

    I tire of your straw man arguments. I have passed one of these courses (taught from the GoF book and a couple of others) and observed several more. If any courses like the one you describe actually existed, people wouldn't make so much fun of CS degrees.

    Go back to humping your book. 



  • @asuffield said:

    @variableName said:
    You seem to think that design patterns are taught in isolation, that people are taught design patterns and then ordained as developers. This is certainly not the case. In most universities "Design Patterns" is a senior or graduate level course, taught only after students have had a lot of exposure to different programming methodologies. Teaching design patterns encompasses their theoretical basis, analysis of performance and scalability, etc.

    I tire of your straw man arguments. I have passed one of these courses (taught from the GoF book and a couple of others) and observed several more. If any courses like the one you describe actually existed, people wouldn't make so much fun of CS degrees.

    Go back to humping your book.

    I took this course, too.  To be fair, at my university (University of Maryland), it was a senior level course.  We used GoF, although I see they've since moved to Holub on Patterns, and now some terrible looking O'Reilly book called Head First Design Patterns.  I'm looking at it now on Google book search.  Jeez, this book is awful.  How in the hell are they using this as a textbook?!?  But I digress.

    The class's official name was "Programming Language Technologies and
    Paradigms," but do you know what the students called it?  Java.  As in,
    "I have to run, I have Java in five minutes." Every other general-purpose programming-heavy course was C/C++, but this was in Java because it was, and I'm quoting my professor here, "easier."  We wrote a web server using every single design pattern in that book.  What a waste of my life that class was.  But, hey, easy A.



  • @bstorer said:

      We wrote a web server using every single design pattern in that book.  What a waste of my life that class was.  But, hey, easy A.

    Could have been worse. A web server using every single design pattern in that book... absolutely stupid, but possible. Contrast that to the other course: "Software Development Technologies and Frameworks". Those poor lads hat to write a web server using every single java framework out in the wild. The course started in 2001, and they are still not finished. The only reason you didn't have to attend that course is that the classroom is still blocked by the unlucky class of 2001.



  • @ammoQ said:

    @bstorer said:

      We wrote a web server using every single design pattern in that book.  What a waste of my life that class was.  But, hey, easy A.

    Could have been worse. A web server using every single design pattern in that book... absolutely stupid, but possible.

    Possible, yes.  But requiring almost 300 pages of JavaDoc just to return a freaking on-disk text file. 



  • @asuffield said:

    I tire of your straw man arguments. I have passed one of these courses (taught from the GoF book and a couple of others) and observed several more. If any courses like the one you describe actually existed, people wouldn't make so much fun of CS degrees.

    At UIUC, where I earned my degree, patterns are presented in a series of Software Engineering courses, CS 427, CS 429, CS 527 (senior/grad level)

    Each course covers much, much more than patterns. They are merely one topic in the software engineering sequence. And when patterns are presented they are analyzed as I described.

    The reason people make fun of CS degrees is that there is a huge difference between a top-tier CS degree and a less than top-tier CS degree. Unfortunately, most people have CS degrees from the latter category. If a CS program doesn't have a substantial wash-out / fail-out rate, they're doing it wrong. I have friends who have these substandard degrees. They're not from bad schools, just schools where CS/Engineering isn't particularly important. They go through college and all they know is VB/Java/whatever, and they couldn't quantify the time/memory complexity of an algorithm if their life depended on it.

    Maybe the courses you took were from one of these programs?

     @asuffield said:

    Go back to humping your book. 

     I'm not a patterns fan-boy.

     There are places where they are appropriate and places where they are not. It's just that your assertion that they are *never* helpful and should not even be taught is so narrow-minded I feel compelled to defend them.



  • @variableName (about Asuffield) said:

    There is no cohesive thrust to your arguments and I don't see you adding any kind of useful information to this discussion.

    I'd just like to reiterate that I have been kind of disappointed by your posts in this thread. I've come to expect your posts to be more informative and insightful than most.

    His posts are generally mere verbiage and rarely contributes anything beyond keeping his own ego afloat in his own perception. Nonetheless his posts often look significant enough to fool many readers. Any idea is met by obfuscation (needless complication) rather than helpful insight. Any criticism of his ideas are deflected into tangled technical minutae. Any disproving of his ideas are deflected into superficially seemingly related but irrelevant areas (semantics, semiotics, etc). Any posts are dressed in aggrandising terminology that looks impressive for those succumbing to such effects but which fails to contribute additional explanatory or pedagogical power. And he is all too impressed by himself and seem to believe his words as Gospel by merit of simply being uttered by him. However, you can forget about making him realise this.



  • @Mikademus said:

    His posts are generally mere verbiage and rarely contributes anything beyond keeping his own ego afloat in his own perception. Nonetheless his posts often look significant enough to fool many readers. Any idea is met by obfuscation (needless complication) rather than helpful insight. Any criticism of his ideas are deflected into tangled technical minutae. Any disproving of his ideas are deflected into superficially seemingly related but irrelevant areas (semantics, semiotics, etc). Any posts are dressed in aggrandising terminology that looks impressive for those succumbing to such effects but which fails to contribute additional explanatory or pedagogical power. And he is all too impressed by himself and seem to believe his words as Gospel by merit of simply being uttered by him. However, you can forget about making him realise this.

    I don't know if that's entirely fair. I think his posts, on the whole, tend to be pretty good.

    Provided it doesn't turn into a pissing match, which this most definitely has. In that case, I might be inclined to agree.



  • why is there such a raging argument dealing with patterns?  you can hate on patterns (or anything for that matter, even Java) all you want, but sometimes its the most appropriate solution to a problem. 



  • @segmentation fault said:

    why is there such a raging argument dealing with patterns?  you can hate on patterns (or anything for that matter, even Java) all you want, but sometimes its the most appropriate solution to a problem.

    (emphasis mine)

    I love that you phrase that as if it might come as a surprise to someone that one could hate on Java. 



  • @bstorer said:

    I love that you phrase that as if it might come as a surprise to someone that one could hate on Java. 

     

    my intentions were to say "even something as hated as Java has its uses." 


Log in to reply