One can argue these topics until the cows come home, and possibly later. One can strongly argue for/against imperative programming, functional programming, OOP, design patterns, Design Patterns with Cool Names, Design Patterns as Implemented in Your Favorite Language, etc... At the end of the day, the only thing that matters is whether your team thinks your source code is structured or not. If you're on a team of one, well then you have your future self to contend with.
Design Patterns – A comprehensible guide
81–90 of 112 posts
Re: Design Patterns – A comprehensible guide
#82I appreciate the effort, but one of my pet peeves with OO / design pattern examples is when they're completely contrived. Once you've understood the very basics of OO, I think talking about a door factory or a burger builder tends to obfuscate real-world usage more than it aids comprehension. I have this problem with most science/technology analogies, to be honest.
Reminds me of physics books from college where they might say "a horse is approaching a barn door at relativist speeds..." - always seemed much too contrived and I'd maybe have preferred "an exotic particle is moving towards an electron at...".
Check out Soviet books. You don't get the feeling the authors assume you're mentally challenged as you do in most other books.
This is all fun, but I think knowing how to apply knowledge is an important part. Many don't have a problem with electrons and pulleys, but put a real world example and they're out of their wits compared to someone who uses to dead reckoning.
There's an interesting book on the site by Belikov: "General Methods for Solving Physics Problems".
Re: Design Patterns – A comprehensible guide
#83Stop the for humans meme. Try-hards use it to signal that they're "in" but its outlived any meaning beyond some meta-meaning which is no meaning at all. Just make your project quality. Don't proclaim it, just do it.
Note: this comment should not apply to Kenneth Reitz.
Re: Design Patterns – A comprehensible guide
#84Object-oriented programming is a disease, and I can't wait until we're collectively done with it. All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language. The fact that there's this encyclopedia of hundreds of discrete things with arcane toxic names that practitioners are required to individually learn and…
I dislike OOP. It's my least favorite paradigm. The "objects-first" approach to teaching programming was such a bad idea. All that said, there is a place for OOP. And while a world without OOP would be a better place than a world without FP (if we had to choose), I think you'll be waiting a looong time for that world to materialize.
I've spent the vast majority of my career in OO-centric projects, but between my experience in Javascript and Clojure I've begun to see OO as FP with a layer of syntactic sugar. Objects are just closures at the end of the day, after all.
The mental fun was when it dawned on me that most of the benefit from the FP I was falling in love with was coming not from FP itself, but from the liberal use of immutability... and that OOP can be written in a way that similarly embraces immutability.
I don't know if my OO code got better or worse from an outside perspective once I realized that, but it certainly made it easier for me to reason about my experimental side projects.
Re: Design Patterns – A comprehensible guide
#85why on github and not on like... medium?
Off the top of my head:
1. GitHub is a broadly-adopted tool that the author probably already knew how to use
2. It's hard to accept PRs on Medium
3. It allows the author to list the repository on his profile, thereby helping them convey competency to potential employers
4. It's easier to archive a git repo than a Medium post, and easier to rehost elsewhere in the future if/when GitHub dies.
5. Git allows change tracking.
6. It uses Markdown, which can be processed through automated tools to produce a variety of formats, from PDFs for email to EPUB to send to a physical publisher.
Re: Design Patterns – A comprehensible guide
#86Earlier quoted context omitted.
>OOP is very powerful to organize the architecture of your code and capture very common patterns such as reusing an existing piece of five functionalities while overriding one (something that's still awful to achieve in FP, regardless of the language you pick). This is not true, ad hoc polymorphism works fine without subtype polymorphism.
You're absolutely right but you're not answering my objection. Show me an example of a type class with five functions and then how I can reuse it while overriding one of these five.
What you're describing can easily be done by making a module that re-exports four functions from another module and implements the fifth itself (in haskell, anyway).
Re: Design Patterns – A comprehensible guide
#87In a galaxy far far away, there was a kingdom where people didn't know structured programming. Their programming languages only had (conditial) branches, jumps, or GOTOs (as they were colloquially called). And they had a very influential programming book, called "GOTO design patterns". Here's a few examples of design patterns from the book: - "IF pattern" - If you need to execute code only if some condition is true,…
> "Why don't you just add these patterns into your computer language as abstractions? Wouldn't that aid comprehension even more?" I often asked myself this question! Why do I have to say public class DatabaseConnectionSingleton { public static DatabaseConnectionSingleton getInstance (){ ... }; } and then get an object using: var db = DatabaseConnectionSingleton.getInstance(); Why can't I say public singleton Database…
Just one of many reasons that Scala is such an attractive option for Java developers:
// There is only one object DatabaseConnectionConnor {}
Re: Design Patterns – A comprehensible guide
#88Earlier quoted context omitted.
> IMO naming these programing constructs after their arcane mathematical roots is toxic to the advancement of the field. I disagree. Why not call a duck a duck, and instead invent your own terminology, just because you're in a different field? Mathematicians invented those concepts first, whether you like it or not. It's actually one of my three criticisms of (OOP) design patterns. Often they are just another names f…
> I disagree. Why not call a duck a duck, and instead invent your own terminology, just because you're in a different field? Mathematicians invented those concepts first, whether you like it or not. Mathematicians discovered the existence of these structures first and gave them names. Programers also came across them, and there is no shame in giving the structures better names more appropriate to their own field - wh…
> Mathematicians discovered the existence of these structures first and gave them names. Programmers also came across them, and there is no shame in giving the structures better names more appropriate to their own field - whether mathematicians like it or not.
Actually this is not what happened here - when programmers added the concepts you mentioned, they were very much aware of the mathematical counterparts.
Regardless, I think it is a shame to call the same thing differently just for the sake of it.
> They are not, and have been employed by couple of generations of programmers to create useful software.
I can somewhat recommend this presentation: https://www.youtube.com/watch?v=Rmer37g9AZM
The concepts presented are very sound, however the presentation could be a little better.
Re: Design Patterns – A comprehensible guide
#89Earlier quoted context omitted.
I can appreciate that, but empirically we know from long experience that such comments lead to downward spirals. That's why the site guidelines are the way they are; it isn't to dampen conviction.
so, if i'd noticed you were dang before i responded i probably wouldn't have. only because i was trying to form a consensus. i didn't realize the consensus was being explained to me. :)
Not sure I know what you mean but I'm glad you responded—I like it when people respond :)
Re: Design Patterns – A comprehensible guide
#90Earlier quoted context omitted.
You're absolutely right but you're not answering my objection. Show me an example of a type class with five functions and then how I can reuse it while overriding one of these five.
What you're describing can easily be done by making a module that re-exports four functions from another module and implements the fifth itself (in haskell, anyway).
Yes, like I said, OOP does this a lot more elegantly.