I'm not arguing against your idea, I'm just pointing out additional problem that needs solving. My point is that lots of programmers without at least a little bit of formal university-level CS education have never heard of even the most basic CS concepts. You say "graph" and they hear "squiggly lines going from left to right on a sheet of paper". Wikipedia.org already has articles about the most common CS problems and algorithms. Those articles may not be as detailed as they should be but this part of the problem is already at least partially solved. The big problem is giving people who need this information the ability to find their needle in the wiki haystack. I have no idea how to do that. Searching for keywords simply doesn't cut it, because the vast majority of programmers don't know the right keywords.

... in the subject field, your post looks like this to me. Splitting the first sentence like that between two fields is confusing. The subject line is supposed to contain a summary of your entire post so that people can decide whether or not to open the full text when it's shown abbreviated, not a meaningless half-sentence. Thank you.

You don't learn any of those things to actually remember them. They are supposed to teach you many different ways of thinking about problems. And most importantly, all of them are supposed to teach you how to prove correctness of your own algorithms. You can't learn those things on your own or in a job and without those abilities, you're driving blind on a cliffside road.

Oh, believe me they will. And they'll happily run off a cliff when they come across one of those problems where they need it because they won't even realize they do need it. How do I know? Because I also write those "pretty simple business apps that back up to a database" for a living and I've come across such problems several times just in the past year.

Really? I'll give you a little more real-life example: You need to write a program that will manage consultant assignments. Your company has a handful of specialist consultants who visit customers on request (for a hefty fee, of course). Each visit takes one full day. Most requests require a specific consultant because the others aren't qualified to do the task. Some requests require two or more specific consultants to come on the same day. There are enough requests all the time to fill the consultants' calendars for the whole next year. Your program needs to decide which consultant goes where and when.

I don't want you to find a solution to that problem, I just want to know what generic problem you'd google for in this case to find a solution.

There's always the problem of knowing what to look for. While I was working on my master thesis, I came up with a special graph property which would help me solve the problem. When I submitted a paper about the main problem to a conference, two of the reviewers pointed out that the graph property is already known under a different name (but luckily, nobody used it yet for what I was doing). I talked about the problem to a lot of people in my department but none of them, including my advisor, have heard about that graph property until I got review feedback for my paper.

Also, the theory is not so much about specific knowledge. It's a lot more about your way of thinking. If you can look at the problem from the right angle and then find and fix all the holes in your algorithm yourself, you don't need to look for existing solution you've never heard of. Or you can find out that the problem is too hard for you and you really need to find somebody else's solution. This knowledge of your own limitations is what separates real programmers from code monkeys.

Let me illustrate the difference between theory and "real world skills" on solving any problem which is equivalent to finding shortest path in a graph. There are three basic algorithms to solve that problem: depth-first search (linear-time, only works if the graph is a tree), Dijkstra's algorithm (O(m+n log n) where "m" is the number of edges and "n" is the number of vertices, works on any graph as long as no edges have negative weight) and Floyd-Warshal algorithm (cubic time in the number of vertices, works even with negative weights and detects if the graph contains a negative loop, in which case the shortest path is undefined).

Somebody who knows the theory will inspect the specific problem he's trying to solve and choose the fastest algorithm from the list above that will work with the data. There are lots of reference implementations around so writing those about 50 lines of code will be easy.

Somebody who doesn't know the theory but has lots of "real world skills" probably won't realize that the problem has a well-known 50-line solution that works in all cases and he'll hack together some poorly thought-out piece of crap that's too slow and fails spectacularly on data that don't match the coder's assumptions. As the time goes by and bug reports pile up, the mess will grow even bigger into a convoluted tangle of several thousand lines of code that only the best and bravest dare to maintain.

Lack of libraries is a secondary problem at best. The single biggest problem of all non-plain text programming "languages" is lack of advanced development tools. When you program in a good old text, no matter which specific language you use, you have a hundred different editors to choose from, a dozen diff tools, a dozen version control systems, a hundred different ways to search through your code for whatever you need to find and writing a code generator is trivial. None of those tools need to make sense of the code because it's all just human-readable plain text.

But when you use a programming "language" which stores code in some weird structured format (even XML qualifies if the code structure is complex enough), every single tool you use needs to understand the format. You can't use Vim, Emacs, Eclipse, Gedit or whatever to write the code, you need a special editor made specifically for the language. You can't use GNU Diffutils to diff your code, you need special diff tool made specifically for the language. You can use most of the version control systems out there but you won't be able to compare changes between revisions, unless you use a VCS made specifically for the language. You can't just grep your sources, you need special search tool made specifically for the language. And you can probably forget outright about generating any code automatically.

Maintaining code is much more important in the real world than simply writing it. Most of the problems related to maintaining code have already been solved by general-purpose tools which work with any human-readable plain text programming language. Every new non-text code format requires solving those problems again from scratch and usually makes solving them much more difficult.

Any sufficiently complex software with event loop or multiple threads most likely contains K5 or K3,3. BTW, plain C pretty much allows you to work with full OOP objects, including simple class inheritance and virtual methods. The only limitation is that all members are always public and you have to call destructors manually.

Here's a link to a few nice real world examples.

I'm talking about the combined effects of everybody's individual choices.

Well, guess what: the average Joe McNobody, including you and me, doesn't have anywhere near enough money to make the market care about him. Believe what you want but you can't win against game theory. At best, you could stop playing the game that has been stacked against you from the very beginning. But most people don't have even that option.

Completely replacing the monopoly with a right to a slice of any revenue made from any commercial use of creative work would be even better than short monopoly. Artists get money, big publishers don't get to stomp out competition.

It wouldn't be so boring if there was at least a hint of some deeper thought behind all that text. Seriously, can you think of just one important thought in the whole novel that I didn't cover in my two-paragraph summary above?

Define "efficiently." There are so many mutually exclusive metrics of market efficiency that the word itself is completely meaningless without further elaboration.

I read that. While the base idea of the story is interesting, the actual plot (or rather complete lack thereof) is boring as hell. Chapter 1: an employee management system that micromanages you as if you were a retarded three-year-old. It might help employees during the very first week on the job but nobody could stand that kind of treatment for more than a month. I expected that employee morale would plunge through the floor by the end of chapter and everybody would start messing with the system in very creative ways, making that experiment a well-deserved failure.

Instead, it's a resounding success and we get 3 chapters of rambling narrative about how things go downhill from there over about the next 10 years. When the novel returns back to the protagonist (now living in a high-tech slum), he just keeps longing for a way out of the slum without actually thinking of any real plan while his buddy delivers a lame philosophical rant that it's people's own fault they all ended up in the slum because they didn't care about the rest of the world back when they still had any means to actually change something (tell us something we don't know already). Next chapter: Deus Ex Machina! How predictable, given protagonist's longing for escape without any actual plan. Then the author just wanks to his fantasies of perfect egalitarian Utopia without any plot happening at all for 3 chapters. The End.

Well, duh. When the supply of something is too big, the market will reduce it by force, making companies go out of business to reduce production and restore balance between supply and demand. But this kind of solution is unacceptable when there's too much human labor available. The market exists to serve people's needs, not the other way around.

Yet some people still believe that the law of supply and demand will magically bend around human labor and let everybody become rich despite the mathematical impossibility of that happening.

There's a slight problem here: Negative liberty is directly proportional to the size of your bank account. If you can't afford to defend your negative liberty on your own against interference from others, you lose it.

Not by a long shot. If you don't have to spend so much time defending yourself from people who keep trying to make your life miserable for their own personal gain, you can actually go about using the more enjoyable aspects of your remaining liberty.