Wow I've just noticed what they've done to C2 Wikis. An amazing site and resource, and they had go to and JS framework it. It was looking a bit long in the tooth, sure, but couldn't they just have added a few lines of CSS?
Downvotes? The look of the original website (the URL without the "better" [1]) much closer resembles the original c2 wiki style. The CSS is not even needed in this case.
Part of Ward Cunningham's roadmap is to make mirroring (even to other wiki implementations) much easier.
That said, given that he's the original inventor of the wiki, I'd say he's earned a bit of patience on our part. Let's wait and see where he's going with these ideas (some of which are: federation, bi-directional linking between wikis, forking & merging, transclusion, etc.), a bit longer before contemplating setting up a "classic" wiki with this content.
Well, that's technically fine. However, the page should be a static document which was rendered on the server side and the other stuff should be loaded later and only when needed.
There is no reason why the initial render can't be done in <20 KB and <5 requests.
My experience shows that almost all GoF design patterns, except singleton, are not useful at all in writing modern C++ software.
The singleton is really just about a language trick, it hardly means anything more than a global variable fit into C++'s class hierarchy.
I've been writing C++ in the past 1.5 years. All I have saw is design patterns being used forcefully and awkwardly. And there has not been a single instance where a pattern is used and improves the overall quality.
Such practices result into closely coupled class webs, which is hostile to testing, extremely difficult to understand and change; the worst, they easily causes circular dependency, which was once considered a norm in C++ code.
They also result into overengineerred interfaces, which gradually morphed into a "DoEverything" interface, like DoEverything(ActionOptions, RuntimeEnvironment). ActionOptions literally captures every options you can have on anything; and RuntimeEnvironment includes all data for the action to happen.
IMHO, C++ code is about as good as it can be, when it manages to achieve 2 things:
1. DAG in translation unit dependency.
2. Predominantly prefer composition to inheritance.
Plus, class access control (private/protected), and anonymous namespace should not be used to hide your implementation. That makes writing tests way too troublesome. And TBH, no one wants to abuse implementation details, unless the interface is bad or no comprehensive tests.
>They also result into overengineerred interfaces, which gradually morphed into a "DoEverything" interface, like DoEverything(ActionOptions, RuntimeEnvironment). ActionOptions literally captures every options you can have on anything; and RuntimeEnvironment includes all data for the action to happen.
Also known as a function on the IO monad. The people who were writing that might have a good time with Haskell.
I never really got the whole public/private thing. If you want to only expose certain functionalities, that's what the interface does. Making things private just hides things that are potentially nice hooks for testing or whatever.
> I never really got the whole public/private thing.
It's about encapsulation and class invariants. Public methods must preserve them, private methods can break them temporarily. You get a prepackaged component and you're prevented from introducing bugs into the component from the outside of the component.
Take std::vector, for example. By keeping implementation details (pointer to element storage and element count) private, you prevent users of the class to accidentally shoot themselves in the foot by, say, changing the element count directly.
You could use interfaces, but for that you have to use virtual functions: Objects have to be created dynamically and you have to handle pointers or references instead of values.
The assumption is that your public members are your interface. Anything private is an internal implementation detail, possibly subject to future change or replacement.
Thorough testing of the public methods should end up calling all of the private methods. Of course, that's a best case scenario. In C++ at least, it'd be an option to make a testing class that's a friend of the class it tests. Then you could test the private members individually.
I think almost all modern languages end up with granting (unit) testing code free access to everything. The idea of testing only the public interface is about an unique snow flake only meaningful in C++ design, and was never a viable practice at all. Otherwise, I'd say at least one other language follow the similar approach...
Are you just complaining about a lack of introspection to get around access controls? Friend classes are better for encapsulation than introspection is.
Are those also considered anti-patterns, or simply "bad practices"? The examples in the article seem to have a wider scale than the ones mentioned in your collection.
My question is, where is the line the line between an anti-pattern or simply a "bad practice", or if they are the same?
Probably more bad practice by that definition, though for me the two concepts are very similar. I think the original article aimed more at process and large scale patterns, where our book aims more at small scale patterns.
Anti-patterns can be copied as well as reinvented. Also, some can manifest simply through developers' inattention rather than being a deliberate reinvention, such as:
I guess there can be an antipattern opposite to NotInventedHere, where developers don't want to solve small problems, only reuse existing libraries that already address the problem in hand. I guess this is most noticeable in the javascript world.
I feel like this list has been designed in such a way that it is not possible to create any code, without implementing an example from the list.
When you make a list this long, you're attempting to cast a wide net over most conditions, if not trying for total coverage by including catch-all buckets.
Meanwhile, it feels slightly impossible to ask anyone to write code at all, without having them complain about something.
The only lesson I can glean from this is that every project requires a compromise of combining abominations with idealized perfection, and that transitory human moods and emotions have more effect on programming tastes, than actual practicality.
This is the case with most such lists of verboten practices. It's good to know the general rules, but it's also important to know when your situation justifies breaking them. Competency is all about good judgment.
I don't know which is funnier, the inaccessibility of the "anti-pattern" website in general which is bitching about inaccessibility of applications, or the fact that the 'constructor' (loosely) for serving you that page is clearly 'null'~
At least it works now. There was a hot minute there where they'd decided that the `fetch` API was a required feature and didn't polyfill it, totally breaking the site in browsers that lacked the feature.
No, and that's ridiculous. Your rule says, "Please don't bait other users by inviting them to downvote you or proclaim that you expect to get downvoted."
I didn't bait anyone nor did I say I expected it. I said I was risking downvotes by having a contrarian opinion. Expectation and acknowledgement of risk are not identical.
In any case, you've won dang. While I've been a user here for nearly four years, you've really convinced me that participating in this community is wasted effort. Feel free to delete this account. I won't be back.
Antipatterns are on rather firmer academic ground than the guy at the airport barstool. Antipatterns are simply a negative version of design patterns. Design patterns in software started with the book Design Patterns: Elements of Reusable Object Oriented Software (aka Gang of Four or GoF), one of the greatest classic works in software engineering. GoF was itself based on the book A Pattern Language, by Christopher Alexander, a classic of the architectural field.
Alexander came up with the idea of a "pattern language" to describe patterns in architecture, a formal structure for observable phenomena. The GoF reused pattern language in a formal way to describe software patterns. Part of the pattern language describes how to implement the pattern. Antipatterns first appeared in the book Antipatterns: Refactoring Software, Architectures, and Projects in Crisis. Again, pattern language was used, including patterns for solving the problems caused by the antipattern.
So yes, this is rigorous. Not math-rigorous, but rigorous.
The kinds of things listed on the link have to do with project management and anecdotes about human interactions on teams that happen to be building software. You can try to tie this intellectually to more legitimately thought-out ideas, but you're stretching its content enormously. It's a farce to call this kind of thing "rigorous."
However, it should be noted that Design Patterns as we know them have very little to do with those described by Alexander: They are the same in name only.
Exactly. This is just compulsive obsession over classifying (imaginary) things. The worst part is, that many of these are probably somewhat valid observations. I would actually be happy to read well-written book of short anecdotes about "how a bad decision was made and what happened" related to software development. It's not like such books (about life in general) do not exist already, but it is always treated as fiction/publicistic literature (as it should be). Trying to make a list of these and name these (especially in stupid camel-case manner, that does not contribute to readability at all), and assign "properties" ("Type", "Root Causes", "Refactored Solution") to them — it is just stupid and counter-productive.
Sheesh, people, did they kick your dog or something?
They're just some people trying to help others by identifying some common problems they've encountered. Sure, the presentation might not be the best (though most of them don't have "properties", they're just a discussion), but does it really merit the epithets?
Also, regarding the camel case, that's just the Wiki's own linking format. I agree it wasn't the best decision, but considering this is the first invented Wiki ever, surely Ward can be excused a bad decision or two?
What a mess of a list. Management, coding, architectural, and uncategorized "anti-patterns" lumped together. I bet many of them are just from somebody blowing off steam.
it's still in plaintext, i.e WikiWikiWeb markup format, and I haven't touched it in a while. if anybody knows how to convert this to HTML, let me know and I'll batch-convert it.
ward, your site is taking a down-hill turn. stop with this remodeling and go back to the static site, please.
Reaching for heavy and complex tools when a straightforward solution would have sufficed.
Example: Requiring JavaScript for a simple static site. Making a wiki as an SPA.