But lawyers don't normally work in a management hierarchy, do they? And I'm pretty sure hospital administrators hate physicians just as much as managers hate programmers. (Not all of them do, of course, but I'm guessing it's similar.)
Yes, this was an unusual release, and an experiment in shipping new features quicker than our major release cycle normally allows. Out-of-process-plugins was a good candidate for an interim release, because it is a stability enhancement and is transparent to the user (no UI changes).
The idea is to push things out that help users as fast as possible. Things that require users to rethink how they use a product require longer release cycles as to not confuse users. In other words, rethink releases from a user's prospective, not a developer's.
I don't think Iran would do that unless there was already an invasion of Iran underway. And while it might be possible to clear the scuttled ships, it would be extremely difficult and take months, if not years. That would be months or years in which oil supply from not only Iran but Iraq, the UAE, and Saudi Arabia would be choked off. That would be crippling to the world economy.
Just wondering -- wouldn't a couple (or a couple dozen) of well-placed explosive charges disintegrate the ships into small enough pieces and clear the way? Can you expand on the difficulties? It doesn't seem to a layman like it'd be that challenging or take that long. (Then again, I realize little does.)
He's not rejecting progress. He explicitly says that C isn't for everything. But he wants real progress: a language with GC, concurrency, etc., not just C-with-classes-plus-etc-etc-etc
I'll deal with this in order of decreasing insanity:
1) Polymorphism is NOT functional programming. Using function pointers, which you seem to detest, is one aspect of functional programming. If you've only used C++, then you don't know what you're missing from languages like Lisp or JavaScript. (I should know. I was once like that.)
2) I seriously doubt the Linux kernel avoids function pointers. Ever heard of dispatch tables? Good C hackers know that smarter data structures make for simpler code.
3) Any feature that can go horribly wrong will go horribly wrong when you have a large project with lots of contributors. Everybody who successfully uses C++ on a large project has a huge "coding standards" document to keep the project from crashing and burning. I know Google has it, and I've seen others, too. Even I have it for my own personal C++ projects!
4) What Linus meant by "context dependency" is that you have to know the object's type in order to know what the function will do and you even have to figure out which version of the function will be called, based on the arguments. This is hell when you get a small patch in the middle of a larger function.
1) You can pass around worker objects and apply them to things.
2) Declaring, initializing, and using dispatch tables requires a boat load of syntax, or GTK+ style macro hell. To the best of my recollection, Linux only goes to the trouble for a few large, complex subsystems, like networking and filesystems. Many other areas could probably benefit from it but cannot afford the price.
3) True. But once you climb the hill, you get to offload a lot of crap onto the compiler. Forever.
4) Linus already applies his +18 Axe of Correction to large functions and nesting depth. Anybody who reviews patches without a color-highlighting code browser deserves what they get.
Users work in an infinite number of different ways, and they way they worked before they use your app is probably forced by whatever crap they are currently using.
No matter what you do, you end up forcing a lot of people to learn to work the way the app wants them to. The best you can hope for is to build an app where, once it's explained, most users first go "Oh, ok, that makes sense." and then actually remember it later. If you're really good, the users will even say, "Wow! That's much better than the app I used before."
Ok, sure, you have to draw a line somewhere. Point conceded. But the position taken by the parent article seems to be pretty close to "don't make a damn thing configurable" and that is a position I think is flat wrong - for many classes of software.
Then again, my interest is more in complex, multi-user, enterprise systems, where you are likely to have more varying forces at work (integration with other systems, needs of different classes of users, etc.) than something like, say, a TODO app for ones iPhone.
I have yet to see a highly complex piece of enterprise software that people actually liked to use. Honestly, I think the current state of enterprise throw everything and the kitchen sink at the problem software just demonstrates the downsides of a complex and highly configurable system. If you don’t know what people will be using it for then you can’t build a streamlined system.
I have yet to see a highly complex piece of enterprise
software that people actually liked to use. Honestly, I
think the current state of enterprise throw everything
and the kitchen sink at the problem software just
demonstrates the downsides of a complex and highly
configurable system. If you don’t know what people will
be using it for then you can’t build a streamlined system.
True, true. And that's why I find articles like the parent useful, because they do serve to remind use that we should strive for simplicity... That is, while I may largely disagree with what seems to be the "logical conclusion" of the article, I don't disagree that things should be, as they say, "as simple as possible, but no simpler." And since I am working on some "complex, enterprise software" - and being aware of how notorious this kind of stuff is for NOT being friendly and easy to use - I feel drawn to try and break that trend by making things that are both powerful and flexible, but without being confusing and difficult. It's a difficult balance to strike, and I don't claim to have all the answers, but at least acknowledging the problem and having that as a goal is a start, I think.
This assumes a one-to-one relationship between pieces of software and workflows, which is absolutely incorrect. Just because you design a piece of software to be used in a certain workflow does not mean that that workflow will work for everyone; software which allows users to configure it to fit their individualized problems and processes is infinitely more valuable than software that tells the user "it's my way or the highway."
