Some of these theory classes may provide better insight, and lacking them may limit you if you're attempting to enter a highly specialized, complex field with no demonstrable experience in it (which, by the by, doesn't really happen), but for 98% of your day job, it's going to be more important for you to know how to parse and sanitize input than it will be for you to know how to write a compiler, raytracer, decompose a function into mathematical terms, perform a Big-O analysis, design a memory manager for an OS, and you'll probably never use matrices or differential equations.
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.
And the vast, vast majority of developers will never need to know that. Most developers out there are doing pretty simple business apps that back up to a database....
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.
And any developer who finds himself needing to find the shortest path is going to google "shortest path algorithm" and guess what the very first result is...
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.
And theory is just that.... theory. Any academic approach will fails 90% of the time in the real world, hence RMS's bazaar (real world) vs. cathedral (theory) analogy.
Of course "pro-theory" advocates has a scapegoat: in the real world; if you didn't do it right, it's because you didn't follow the theory as most academics would say (e.g. Agile's "you didn't do it right" excuse). The irony....
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.
I think the real issue is in large part a chicken-and-egg problem. Since there are no libraries of 'components' that can be easily used, it's a lot of work to build everything yourself. And since there is no well-accepted tool, nobody builds the function libraries.
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.
In practice, I believe that the present text-based programming paradigm artificially restricts programming to a much simpler logical structure compared to those commonly accepted and used by EEs. For example, I used to say "structured programming" is essentially restricting your flow chart to what can be drawn in two dimensions with no crossing lines. That's not strictly true, but it is close. Since the late 1970s, I've remarked that software is the only engineering discipline that still depends on prose designs.
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.
Have you ever tried to actually visualize a data model that is from a real-world application, where you soon find that you need to draw hundreds of arrows all across the model? The technique that works well and gives you a really nice view for, say, a simple blog application or whatever the current tutorial app beyond "hello world" is, breaks down horrible when you're dealing with real-world complexity.
Here's a link to a few nice real world examples.
Are you talking about God? Or Santa? Or the Easter Bunny? I don't know who this "Market" person is but he's a douche and needs to be put down.
I'm talking about the combined effects of everybody's individual choices.
You say the market can't magically bend and let everyone be rich but you know it doesn't have to be as bad as it is. We, the people, run this market. We can make it do whatever the hell we want provided we have enough influence (ie money). The market isn't the greedy uncaring bastard you make it out to be- your boss is.
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.
Well, the point of copyright law is to support the arts and increase common culture. So if short copyrights result in a richer culture of works, then it should be the case. There is no 'god given right' here, all we have are a set of laws intended to benefit everyone, helping the author enforce their will is just a side effect or implementation detail.
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.
Just try to think of it as slightly less boring than just reading the bare essay itself.
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?
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.
My impression has been that the labor market is so inefficient that the only mechanisms by which it "sorts out" are outside the market. The US Civil War, for instance. Or Tompkins Square. Or Haymarket.
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.
"Negative liberties" refer to interference from others, including both private citizens and government.
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.
Progressives try to "enhance" people's "positive liberty"-- which is a zero-sum game.
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.