Because of the high resolution.
Okay, I suppose you don't mind we also stop pretending the Five Eyes (especially the USA) and Israel at not in a low level war with any other country? Right?
The thing you linked more or less said design pattern are bad because... he doesn't like it. He says there is no scientific proof they are good and thus they must be bad (without giving any proof) and because people used them wrong and introduced unnecessary complexity. The argumentation of the GoF is as sound or unsound as his. I can always construct an argument against something if I point out how it is used incorrectly. By this argumentation Assembler, C, C++ and actually every programming language is bad, because I can write really messy code.
I wrote that design patterns are usefull to _me_, yes. I can't generalize my experience, of course. Yet I learned design patterns only quite some years after I started programming. And I really prefer it this way over everyone reinventing the wheel. The code bases I worked on were many years old and more than a million lines of code or so. It just would not have worked without design patterns and code formating rules.
The problem is, that there are almost no useful experiments in software engineering. Each one I saw until now was set up way too small, too short or used students instead of professionals or any combination of this. Really good experiments are just wayyy too expensive, as you would have to watch programming efforts with and without, on the same project, over years, with professionals. Nobody will finance that, unfortunately. And case studies are just case studies and can't be generalized. Thus it is hard to scientifical sound say what is bad or good. It would be great if we could, of course.
Forgot to note, that patterns also improve communication, as you can just say, you used the observer pattern and everybody (hopefully) knows what it means. Moreover by just harmonizing the code, so that the same problem is always solved the same way, you don't have to dig deep into the implementation to see what is going on. You see ItemsPurchasedObserver and you have a rough idea what's going on. On top you are not forced to reinvent the wheel for the millionth time.
Well, I don't want to miss at least a couple design patterns: Iterator, Observer, Adapter, Decorator, Dependency Injection, Object Pools (Threads and Connections in my case).
I also sometimes use Singleton, Builder, Proxy, Command, Circuit Braker.
Iterator: I want a simple Interface I know, to iterate over data structures if iterating is reasonable. Not 10 different interfaces for 10 data structures.
Observer: Often I want information to propagate. Yet the business logic should not depend on the UI, so I can easiely provide different UIs. And especally I don't want circular dependencies.
Adapter/Wrapper: Every so often I have to work with slightly off interfaces. Putting an Wrapper around it solves this.
Decorator: You don't have to maintain for example scroll functionality for every dsplay and input type (e.g. Text, Picture) but just do it once.
Dependency Injection: My code is so much easier testable since I use DI. Only downside, I have to admit is, that you potentially have your dependencies defined elsewhere. But then again this allows easier changes of those (for example in case of software product lines).
Object Pools: Thread and connection pooling can drastically improves performance. Noone nowaday creates 1000 new connections per second from one server to one DB.
Yet of course I don't sit there all day and try to use as many design patterns as possible. For a 100 line program I would never use DI, I use a wrapper only, if I really need to. And so on...
The goal is not to use _many_ design patterns, but those, that fit and actually improve the design by making it easier to maintain.
Yeah great, I have to use key combinations for the f-keys. Best keyboard evar!
That is somewhat along the line of "If I shoot him first, he can't shoot me."
There are already things hindering the customers to place their PC directly with their back to the walls. One is called cables, the other one is called convenience. Who wants to crawl under their desk to turn the PC on or to attach / detach an USB flash drive? Thus a PC is more often then not aligned with the front of the desk, with more than enough space towards the wall.
So I call BS on the "regular PCs heat up because of walls and thus we introduced this case design".
Even though risking to feed a troll:
Please elaborate why Java is a "slower language before we even start",
why you think java is single threaded (in Java multi-threading is really comfortable, and no libraries needed),
why you say there is no optimization (the JIT compiler DOES optimize the code),
where your "good logic" is, when there are numerous buffer overflows and similar problems regularly found in important C / C++ code,
and why you are thinking you would be forced to use any library? (of course you can reinvent the wheel for the thousands time with the same errors)
Have you ever seen real benchmarks between Java Code and C / C++ nowadays? It doesn't seem so.
And what are you referring to with '"easy" amature programming' and "fast food alpha"?
That is why it's called "management" and not "solving", "empowering" or "understanding".
This is no slippery slope, this is utter nonesense! If facts stated about your are wrong, you let your lawyer send a letter, that the author has to remove or change the information. They will comply if it's reasonable, if not one can escalate and go on trail.
Long strory short: In Europe you already have means against someone unrighfully diffaming you. No need for censoriing.
I don't have the time to go to every news page and look through if something new and important was written. So I still use RSS. I want the information come to me, not to chase it.
My project is in a really early state (no customer - problem fit) as I haven't had the time to invest lately. Feel free to drop me a mail (firstname.lastname@example.org) If you want to get updates or want to help me find out what current "problems" with readers and information acquiring in general you have.
No, it doesn't.
What the quote states is like "because you can't know anything to it's fullest it's okay to just don't care at all." To compare apples and oranges: "Because I can't run a marathon right now it's totally okay to be not able to run even 3 km." Hint: The one able to run a half marathon is nevertheless in a better state than somebody who can't run even 3 km, even though both cannot run a marathon.
Science will undermine it's claims with experiments and reasoning. Moreover we see the results of science in our daily life. Many basic things you can test for yourself (for example just start breeding plants, stretching springs, heating metals, measure a circuit) and actually understand. If you show me someone making wine out of water or dividing a sea I will totally belief in this story. There is a difference between something you see describing your daily life, making predictions about things not yet seen (but later verified) and a story "you just have to believe". Should I believe in the Nigerian prince wanting to give me money, too?
By definition everything we can't proof is just a theory. The only things we can proof are those, we base on a system of axioms ->see math. All the rest we can only explain, most often quite good, but most often there are missing pieces. We can't merge the theory of relativity with quantum mechanics. Both theories work really well for problems "of the right size". I hope you will see, that gravity is a theory, too, even though it's a very well working as it bases on a model.