The success of a project is not the sum of design plus evolution, where enough of one can make up for too little of the other. It's more like the product of design multiplied by evolution: if either is too small, your project goes nowhere fast.
It would be possible to measure energy and temperature in the same units...
Do you mean that we could measure temperature in joules? That would be strange--for materials of different heat capacities, we would add different amounts of heat joules to get the same increase in temperature joules.
I'm no expert, but as I understand it, if you want a physical quantity with which to associate entropy, it can be considered the logarithm of the probability of finding a system in a certain state. Low-entropy states are so vastly, astoundingly, inconceivably improbable that the laws of thermodynamics simply assume high-entropy states to be inevitable.
The fact that it's a logarithm makes me wonder how it can have units (namely joules per kelvin, the units of heat capacity). Then again, as I said, I'm no expert.
Oh Christ,
not again. If every damn dollar isn't spent preventing people from starving, then it's wasted. That's certainly an easy moral position to take, isn't it?
The Self project at Sun was the first language which truly fleshed out the idea of prototype-based languages, and their goal was clearly stated as designing the successor to OO.
Ah, so the project billed itself as the successor to OO? That's easy. Every new paradigm, or minor modification to a paradigm, thinks it will be the successor to object-oriented programming. Some have even gone so far as to market themselves this way with names like "aspect-oriented" and "subject-oriented" programming.
It's all bollocks if you ask me. Certainly something will succeed OO, but the proponent's own claims are not a good predictor of success in this area.:-)
I don't see any reason to require an engineering certification to write software, just like you don't need an engineering certification to build a bridge. However, certain projects can require certification if they want to have certain quality guarantees.
Also, to continue the analogy, the engineer doesn't actually construct the bridge; he designs it and certifies it. Same could be true of software: if the appropriate practices are developed, an engineer could certify the work of a hundred non-engineers.
Assuming you're not a troll, but really are that confused...
Not everyone writes application software using Visual Basic and ActiveX. For example, what about the people who write the compilers? Anyway, optimization is not a "solved problem" as most people think it is, and hand-coded assembler is still undoubtedly superior in some cases.
Ask me why you need to know assembly after you've written a JVM (without a JIT even) that needs to achieve respectable performance. You'd have to be a better man than I to do that without peeking at the assembly code your compiler generates.
Well, personally I don't like singletons much at the modelling level, but whatever suits you. The point is that the difference between types and instances is fundamental--not some artifact of bad language design--so obscuring that difference is not a desirable thing to do.
For those unfamiliar with the concept of prototype-based programming languages, Bob (and all prototype-based languages, for that matter) are by their very nature single-inheritence.
I don't think that's true. If I'm not mistaken, both Cecil and Self are prototype-based languages with multiple inheritance.
Languages such as this are called prototype-based languages, and are generally seen as the successor to object-oriented programming.
"Generally seen" by whom? Perhaps I'm out of touch, but I have never heard this before. Is this really a common belief?
Prototype-based languages have an interesting minimalistic feel that allows language designers to get right to the heart of some issues, and I think they are very valuable for that reason. However, I think ultimately classes will win out.
One of the common mistakes in OO programming is to confuse kinds-of-things with instances-of-things. A program for a clothing store might have "shirt" objects with properties such as the manufacturer, size, colour, and quantity in stock. Seems ok so far. Then, when looking for a place to store information on a specific shirt, such as the customer who bought it, the programmer notices that a "shirt" has two meanings: a kind of shirt versus a specific individual shirt. The quantity-in-stock belongs to a shirt type, while the purchasing-customer belongs to a specific shirt instance. The design has to be juggled a bit to accomodate this new insight.
Combining classes and objects the way prototype-based languages do seems to encourage this kind of confusion on a massive scale. Programmers would undoubtedly add comments to indicate which objects are actually "meta-objects" (ie. classes). The Bob language examples do exactly this, as a matter of fact. I suspect that the degree to which they don't differentiate between classes and objects is exactly the degree to which they will have confusion between instances and kinds of things.
Incidentally, I think there is a great deal of promise in the idea that everything (including classes) is an object, but I don't see prototype-based languages as being a successor to class-based ones.
It's hard to find any documentation for the Bob language. Having a quick look at some Bob source code, it is a simple OO language without classes, where subclassing is the same as instantiation, much like Self or Cecil. It seems to support only single inheritance, though I gather it's dynamically typed, so there's no need for "interface inheritance".
It's not "purely" object-oriented, since you can define procedures that are not methods of any class. At first glance, there doesn't seem to be any access control: all features of an object are public.
The effect of good variable names is different from that of good comments. A variable name, no matter how long and descriptive, only tells you what that variable is. You still need comments to know why and how it's being used.
Also, it's silly to eschew all comments because some comments are inaccurate. A comment that don't match the code should be considered a bug like any other. Inaccurate comments should be fixed, even if only by adding "TODO: double-check this comment--it seems wrong".
Yes, comments usually don't need to explain what the code does, unless it's really obscure. Rather, they should explain why the code does what it does. Just like writing any documentation, have an audience in mind.
Absolutely right. Otherwise, you're at the mercy of an unknown factor. This is what software engineering is all about.
Make sure your interface is designed to place the least possible requirements on the underlying library, or else you may find it difficult to substitute another later. It would be wise to look at a few libraries (say, Qt, Gnome, and Windows' own) and concentrate on their differences, just to get an idea of the range of possibilities. Then design your interface in such a way that it doesn't rule any of them out unless it really needs to.
I know it sounds like you're designing your own GUI library from scratch, but that's not the case. You're simply expressing your GUI needs in terms of an interface which can be implemented easily in terms of existing GUI libraries.
Slashdot Mirror
The success of a project is not the sum of design plus evolution, where enough of one can make up for too little of the other. It's more like the product of design multiplied by evolution: if either is too small, your project goes nowhere fast.
My lickspittle told me I never cease to amaze him.
I'm no expert, but as I understand it, if you want a physical quantity with which to associate entropy, it can be considered the logarithm of the probability of finding a system in a certain state. Low-entropy states are so vastly, astoundingly, inconceivably improbable that the laws of thermodynamics simply assume high-entropy states to be inevitable.
The fact that it's a logarithm makes me wonder how it can have units (namely joules per kelvin, the units of heat capacity). Then again, as I said, I'm no expert.
Oh Christ, not again. If every damn dollar isn't spent preventing people from starving, then it's wasted. That's certainly an easy moral position to take, isn't it?
It's all bollocks if you ask me. Certainly something will succeed OO, but the proponent's own claims are not a good predictor of success in this area. :-)
That's funny. I disliked the pilot, and I have liked every episode since. To each his own, I guess.
I remember a friend showing me Doom on a PDA, and it used the PDA's thumbwheel to turn. It seemed to work really well.
I suppose a real 3D game would need two thumbwheels.
I'm not sure what you mean by "guarantee" but I mean that the engineer stakes his reputation and his career on the quality of the end product.
I don't see any reason to require an engineering certification to write software, just like you don't need an engineering certification to build a bridge. However, certain projects can require certification if they want to have certain quality guarantees.
Also, to continue the analogy, the engineer doesn't actually construct the bridge; he designs it and certifies it. Same could be true of software: if the appropriate practices are developed, an engineer could certify the work of a hundred non-engineers.
Assuming you're not a troll, but really are that confused...
Not everyone writes application software using Visual Basic and ActiveX. For example, what about the people who write the compilers? Anyway, optimization is not a "solved problem" as most people think it is, and hand-coded assembler is still undoubtedly superior in some cases.
Ask me why you need to know assembly after you've written a JVM (without a JIT even) that needs to achieve respectable performance. You'd have to be a better man than I to do that without peeking at the assembly code your compiler generates.
Well, personally I don't like singletons much at the modelling level, but whatever suits you. The point is that the difference between types and instances is fundamental--not some artifact of bad language design--so obscuring that difference is not a desirable thing to do.
Prototype-based languages have an interesting minimalistic feel that allows language designers to get right to the heart of some issues, and I think they are very valuable for that reason. However, I think ultimately classes will win out.
One of the common mistakes in OO programming is to confuse kinds-of-things with instances-of-things. A program for a clothing store might have "shirt" objects with properties such as the manufacturer, size, colour, and quantity in stock. Seems ok so far. Then, when looking for a place to store information on a specific shirt, such as the customer who bought it, the programmer notices that a "shirt" has two meanings: a kind of shirt versus a specific individual shirt. The quantity-in-stock belongs to a shirt type, while the purchasing-customer belongs to a specific shirt instance. The design has to be juggled a bit to accomodate this new insight.
Combining classes and objects the way prototype-based languages do seems to encourage this kind of confusion on a massive scale. Programmers would undoubtedly add comments to indicate which objects are actually "meta-objects" (ie. classes). The Bob language examples do exactly this, as a matter of fact. I suspect that the degree to which they don't differentiate between classes and objects is exactly the degree to which they will have confusion between instances and kinds of things.
Incidentally, I think there is a great deal of promise in the idea that everything (including classes) is an object, but I don't see prototype-based languages as being a successor to class-based ones.
Just in case anyone is wondering...
It's hard to find any documentation for the Bob language. Having a quick look at some Bob source code, it is a simple OO language without classes, where subclassing is the same as instantiation, much like Self or Cecil. It seems to support only single inheritance, though I gather it's dynamically typed, so there's no need for "interface inheritance".
It's not "purely" object-oriented, since you can define procedures that are not methods of any class. At first glance, there doesn't seem to be any access control: all features of an object are public.
Here's a related article at LinuxDevices.com. It's not a review, but it has links to more information.
I agree completely. To me, that's exactly what comments are for.
The effect of good variable names is different from that of good comments. A variable name, no matter how long and descriptive, only tells you what that variable is. You still need comments to know why and how it's being used.
Also, it's silly to eschew all comments because some comments are inaccurate. A comment that don't match the code should be considered a bug like any other. Inaccurate comments should be fixed, even if only by adding "TODO: double-check this comment--it seems wrong".
Yes, comments usually don't need to explain what the code does, unless it's really obscure. Rather, they should explain why the code does what it does. Just like writing any documentation, have an audience in mind.
Absolutely right. Otherwise, you're at the mercy of an unknown factor. This is what software engineering is all about.
Make sure your interface is designed to place the least possible requirements on the underlying library, or else you may find it difficult to substitute another later. It would be wise to look at a few libraries (say, Qt, Gnome, and Windows' own) and concentrate on their differences, just to get an idea of the range of possibilities. Then design your interface in such a way that it doesn't rule any of them out unless it really needs to.
I know it sounds like you're designing your own GUI library from scratch, but that's not the case. You're simply expressing your GUI needs in terms of an interface which can be implemented easily in terms of existing GUI libraries.
Yeah, so long as every ounce of human effort is not going into relieving human suffering, we're all wasting our time.
Whatever.