Yeah, the Borg-as-bees thing bugged me too. I would have preferred an ant-colony metaphor.
Nevertheless, that's just one (moderately large) flaw in an otherwise very enjoyable movie. It was the execution of it that I liked so much. You can't beat lines like "if you were any other man, I would kill you where you stand!" when you know the characters enough to know that Warf was not exaggerating in the least.
IMHO the worst was definitely Generations, for three reasons:
The "plot dev^H^H^H nexus" was the most contrived thing I have ever seen. It was a construction whose sole purpose, it seems, was to allow the plot to unfold as it did.
They gratuitously wrecked practically every feature of the Star Trek universe they could get their hands on:
Data got emotions.
Geordi got eyes.
The Enterprise was destroyed.
Kirk was killed.
Lursa and Betor died.
et cetera...
Oh, and by the way, the plot sucked.
</SPOILERS>
To go from that dreck to First Contact (IMHO the best movie of them all) was a triumph, and Jonathan Frakes deserves a lot of credit. (I think he also deserves credit for making the best odd-numbered movie, Insurrection. Yeah, it wasn't very good, but look at the other odd-numbered movies.)
That sounds like a lot of vacant hand-waving to me. How does someone "determine if there is some 'shady' reviewing going on" or "find out who's responsible for it"?
I know, you gather the mob and I'll get the pitchforks.
I was referring to your statement regarding "what I haven't yet seen used anywhere outside my own software and some programming languages internals...". I think this is more indicative of your lack of exposure, rather than the novelty of the idea.:-) It probably doesn't belong in the final HOWTO.
The "data stacks" described in the article sound like a slightly less-evolved version of GNU obstacks. The main difference seems to be that the article uses a single global data stack.
I think the HOWTO should have a reference to obstacks, rather than claiming data stacks are a new invention. (Hint: data stacks have been used many, many times in many, many projects. GNU obstacks are the only one for which I can find a URL at the moment.)
What does this mean? Have you used the Boehm GC? You may be interested to look into so-called conservative garbage collection, a technique that works quite well with C.
No offence intended, but you definitely need to have some knowledge of conservative GC before you write a C memory management HOWTO.
You have a good point, that refactoring mitigates the difficulty of creating OO components. To continue the already-strained pre-fab construction analogy: it's like discovering that certain parts of a building (like walls) are required over and over again, then designing pre-fab parts, and re-designing the buildings to use those parts. This does not require a tremendous amount of foresight; only pattern recognition.:-)
Fine. I was just responding to your claim that "any major software company not reusing components and controlling the design/implementation process will fail", which I believe is patently false.
Incidentally, after being a long-time OO components advocate, I now believe it never works in practice the way we imagine it will. They simply require more foresight than human beings have, and more planning than they are worth. It's like expecting every new construction project not just to build a thing, but first to design pre-fabricated parts that can be used to build all kinds of things. We don't expect this kind of thinking from any industry except software, and I believe it's unrealistic there too.
When opportunities for good OO components present themselves, then go for it. However, making a specific effort to build software out of OO components is putting the cart before the horse.
The fact that "50 years in computer time is an eternity" is precisely because there have only been 50 years of computer time. During the first 50 years of bridge-building time, we might have said exactly the same thing in that field.
Software is not special. It is just another human endeavor, and we are simply not very good at it yet because we have not done it for very long. The dot-com bubble was one piece of evidence for this: the mere presence of computers doesn't change all the rules of the free market.
I agree with Richard Gabriel's assessment that creativity is needed in software, to the extent that we don't know how to reduce it to practice yet.
No, software hasn't changed because we have only been doing it for 50 years. That's not very long in terms of human scientific/engineering development.
You and I wouldn't even recognize how software is built 1000 years from now. By then, I certainly hope most of it will have been reduced to practice, but even if it hasn't, I'm certain they won't do it the way we do it today.
I disagree. I have yet to work at a company that uses real object-oriented components "properly" and yet all these companies are successful (though I'd rather not name names of course). One company was small enough that it produced only a single product, and a single developer knew the whole product inside and out. Anther was so large that they can throw manpower at the product to wrestle it into submission regardless of any lack of OO componentry.
OO components are cool and all, but they are not necessary or sufficient to run a successful company writing software.
Re:Not very well-explained nor convincing
on
Concept Programming
·
· Score: 1
I think there are people who get this, and people who don't. Some people define "syntactic sugar" in such a broad way that you would think there is nothing separating anything from machine language but syntactic sugar.
Personally, I think of the "power" (ie. expressive power) of a language metaphorically as in physics: power = work / time. In this case, it's how much "work" a program can do divided by the amount of developer "time" it took to write the program.
I think it's likely that we are not even within an order of magnitude of the power that languages will eventually possess.
To me, syntactic sugar is an equivalent syntax for some construct that has no value but to save some finite number of keystrokes every time it is used. An example of this is infix operators in OO languages, where we write "3 + 4" rather than "3.plus(4)". (So, clearly, syntactic sugar can be important, since I don't think people would willingly use a language that mandated the latter notation.)
In contrast, working around the lack of varargs in Java the way your parent post described would require an infinite number of keystrokes every time you do it, because you need an infinite number of makeListXXX methods in order to be truly "equivalent". Therefore, varargs is not just syntactic sugar for the makeListXXX notation in my books; it is fundamentally more powerful. And, even if you could write enough methods to make them essentially equivalent, the time required to write all these methods makes Java, by definition, less powerful when it comes to varargs.
So? "Windows Commander" is not using "windows" in the pre-Microsoft meaning. They are specifically using the name to associate themselves with Microsoft's operating system. The distinction between that and brand confusion is a fine one indeed.
I don't think that example is very representative of the tougher problems.
I invite you to re-read the portion of my post you quoted:
In that time, if my estimate is accurate, the development time
for simple programs may have fallen by a factor of a hundred or more.
I'm not talking about tougher problems. However, now that you have brought that up, there is another thing I said that is relevant to tougher problems:
Software doesn't appear to have improved in that time simply because we keep trying to do more complex things.
So, to say it another way, we are always trying to handle more and more of the "jillions of factors that intersect in changing and unpredictable ways". The fact that our success rate has not improved is because the complexity of our problems have exactly kept pace with the power of our tools.
Indeed, the very fact that you consider the KWIC system to be merely a data structure problem indicates just how far tools have advanced. You don't need to consider any of the implementation details and engineering trade-offs that Parnas considered because your tools can do that. All that's left is the abstract datatypes. Parnas' problem has been reduced to practice, and that's precisely what I'm talking about. It's the first steps on the road toward true software engineering.
Software is a cerebral, etherial medium. There are just two things limiting it: your fingers, and your imagination. Tools can reduce keystrokes and make your fingers more efficient, but the human mind has not changed in the last 30 years. Thus, although we still have the same level of talent, we are able to accomlpish more complex tasks.
The KWIC index system accepts an ordered set of lines, each line is an ordered set of words, and each word is an ordered set of characters. Any line may be "circularly shifted" by repeatedly removing the first word and appending it at the end of the line. The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order.
This is a small system. Except under extreme circumstances (huge data base, no supporting software), such a system could be produced by a good programmer within a week or two.
Is there anyone in the crowd that doesn't think he could write a shell script/perl script/etc. to accomplish this in 30 minutes or less? I'd be willing to bet I could do it in Python in under 15 minutes.
This paper was written 30 years ago. It only pre-dated Brooks by 5 years. In that time, if my estimate is accurate, the development time for simple programs may have fallen by a factor of a hundred or more.
Software doesn't appear to have improved in that time simply because we keep trying to do more complex things.
Slashdot Mirror
Nevertheless, that's just one (moderately large) flaw in an otherwise very enjoyable movie. It was the execution of it that I liked so much. You can't beat lines like "if you were any other man, I would kill you where you stand!" when you know the characters enough to know that Warf was not exaggerating in the least.
IMHO the worst was definitely Generations, for three reasons:
-
The "plot dev^H^H^H nexus" was the most contrived thing I have ever seen. It was a construction whose sole purpose, it seems, was to allow the plot to unfold as it did.
-
They gratuitously wrecked practically every feature of the Star Trek universe they could get their hands on:
-
Data got emotions.
-
Geordi got eyes.
-
The Enterprise was destroyed.
-
Kirk was killed.
-
Lursa and Betor died.
-
et cetera...
-
Oh, and by the way, the plot sucked.
</SPOILERS>To go from that dreck to First Contact (IMHO the best movie of them all) was a triumph, and Jonathan Frakes deserves a lot of credit. (I think he also deserves credit for making the best odd-numbered movie, Insurrection. Yeah, it wasn't very good, but look at the other odd-numbered movies.)
I know, you gather the mob and I'll get the pitchforks.
Well, that would be health/safety/welfare then, wouldn't it?
It's called "Moore's Law" in the same sense as "power law": it is a trendline that matches the data.
You obviously weren't invited to their wedding.
That is the first time a "beowulf cluster" comment has ever almost made me laugh.
I was referring to your statement regarding "what I haven't yet seen used anywhere outside my own software and some programming languages internals...". I think this is more indicative of your lack of exposure, rather than the novelty of the idea. :-) It probably doesn't belong in the final HOWTO.
I think the HOWTO should have a reference to obstacks, rather than claiming data stacks are a new invention. (Hint: data stacks have been used many, many times in many, many projects. GNU obstacks are the only one for which I can find a URL at the moment.)
No offence intended, but you definitely need to have some knowledge of conservative GC before you write a C memory management HOWTO.
You have a good point, that refactoring mitigates the difficulty of creating OO components. To continue the already-strained pre-fab construction analogy: it's like discovering that certain parts of a building (like walls) are required over and over again, then designing pre-fab parts, and re-designing the buildings to use those parts. This does not require a tremendous amount of foresight; only pattern recognition. :-)
Incidentally, after being a long-time OO components advocate, I now believe it never works in practice the way we imagine it will. They simply require more foresight than human beings have, and more planning than they are worth. It's like expecting every new construction project not just to build a thing, but first to design pre-fabricated parts that can be used to build all kinds of things. We don't expect this kind of thinking from any industry except software, and I believe it's unrealistic there too.
When opportunities for good OO components present themselves, then go for it. However, making a specific effort to build software out of OO components is putting the cart before the horse.
Software is not special. It is just another human endeavor, and we are simply not very good at it yet because we have not done it for very long. The dot-com bubble was one piece of evidence for this: the mere presence of computers doesn't change all the rules of the free market.
I agree with Richard Gabriel's assessment that creativity is needed in software, to the extent that we don't know how to reduce it to practice yet.
I hereby declare any future posts on this topic to be redundant.
You and I wouldn't even recognize how software is built 1000 years from now. By then, I certainly hope most of it will have been reduced to practice, but even if it hasn't, I'm certain they won't do it the way we do it today.
OO components are cool and all, but they are not necessary or sufficient to run a successful company writing software.
Wow, that is sweet. Great idea.
Personally, I think of the "power" (ie. expressive power) of a language metaphorically as in physics: power = work / time. In this case, it's how much "work" a program can do divided by the amount of developer "time" it took to write the program.
I think it's likely that we are not even within an order of magnitude of the power that languages will eventually possess.
To me, syntactic sugar is an equivalent syntax for some construct that has no value but to save some finite number of keystrokes every time it is used. An example of this is infix operators in OO languages, where we write "3 + 4" rather than "3.plus(4)". (So, clearly, syntactic sugar can be important, since I don't think people would willingly use a language that mandated the latter notation.)
In contrast, working around the lack of varargs in Java the way your parent post described would require an infinite number of keystrokes every time you do it, because you need an infinite number of makeListXXX methods in order to be truly "equivalent". Therefore, varargs is not just syntactic sugar for the makeListXXX notation in my books; it is fundamentally more powerful. And, even if you could write enough methods to make them essentially equivalent, the time required to write all these methods makes Java, by definition, less powerful when it comes to varargs.
You have a point, though I think this kind of diversity may be less important in the sysadmin arena than in software development.
Note: the parent comment is a dupe of this one.
I think Microsoft has a point.
Those are some excellend points. I don't spend a lot of time writing business logic, so unfortunately I don't have much to say about that.
Indeed, the very fact that you consider the KWIC system to be merely a data structure problem indicates just how far tools have advanced. You don't need to consider any of the implementation details and engineering trade-offs that Parnas considered because your tools can do that. All that's left is the abstract datatypes. Parnas' problem has been reduced to practice, and that's precisely what I'm talking about. It's the first steps on the road toward true software engineering.
Software is a cerebral, etherial medium. There are just two things limiting it: your fingers, and your imagination. Tools can reduce keystrokes and make your fingers more efficient, but the human mind has not changed in the last 30 years. Thus, although we still have the same level of talent, we are able to accomlpish more complex tasks.
That's not a very good answer to the "How do you provide open source without escrow" question, now is it?
However, take a look at Parnas' classic paper on information hiding. In it, he makes the following statement (emphasis mine):
Is there anyone in the crowd that doesn't think he could write a shell script/perl script/etc. to accomplish this in 30 minutes or less? I'd be willing to bet I could do it in Python in under 15 minutes.This paper was written 30 years ago. It only pre-dated Brooks by 5 years. In that time, if my estimate is accurate, the development time for simple programs may have fallen by a factor of a hundred or more.
Software doesn't appear to have improved in that time simply because we keep trying to do more complex things.