This reminds me of an old statement by Steve Jobs on the topic of Bill Gates, Microsoft, and Windows. He said something to the effect of "They write okay software, but they've got no sense of aesthetics or presentation. It's really unpleasant to experience."
I've discovered an interesting correlation: developers that write visually unpleasant GUIs rarely write aesthetically pleasing code. I think the same attention to detail (or same detailed attention) and same soul of artist is required in both cases.
I had an argument with a co-worker not too long ago about whether developers fuse engineering and art (much like architects,) or whether we're just twiddling lines of machine instructions. He argued (well) that we're not artists and no real creativity is required to write software. I went back, looked at his code, and decided it wasn't all that great.
Very impressive! You've managed to throw logic and reason out the window and get modded up for it. Let's bask for a moment in your apparent disregard for common sense...
...and now, let's move on to reason.
You're right about one thing: Darl McBride is provably an ambitiousyoungtwit. In fact, looking at his photo, I'd say he's likely a mega-twit. Why, then, do you insist that he needs help from Microsoft (or anyone else) to do his dirty deeds?
This is a case of a few men's greed, pure and simple.
As others have said, library quality is an issue: very few reusable libraries are as mature as (for example) Berkeley DB.
But even after I've located a mature library, I still feel those jitters that make me want to do things myself. Why? Because my concept of how the problem should be solved, and how the solution should be exposed, rarely aligns well with how the library author exposed it. More importantly, I typically have a pre-conceived notion of how i'll use the exposed solution to build my software.
When I reach this point, I step back and take a deep breath. If I'm looking at a mature library, chances are the conceptual misalignment stems from the fact that the library author understands the problem space far better than I do.
Berkeley DB provides a good example of a difficult problem space exposed intelligently. Shortly after the jitters, I realized that my understanding of databases was sorely lacking; diving into the documentation helped me understand how to structure my thinking about my application's design.
In summary: I think that developers turn back in disgust from new APIs because the API factoring doesn't match the developers' pre-conceived notions.
Not sure how useful this would be, but it seems as though there is opportunity here to build a VinylDB much like the CDDB. Of course, the problem is a little more interesting than simply thumbprinting based on number of tracks/length of tracks, since track detection depends on user preferences.
But suppose there were a standard cutoff (say, -45dB) and standard length of time (say, 1.5 seconds) that were used to detect tracks for the purposes of thumbprinting. You'd have to perform detection after RMS normalization of the audio (probably to -16dB). You'd have to detect and skip noise at the beginning. Finally, you'd have to tolerate error in matched track lengths.
In theory, I think these are surmountable problems. I just hope someone does this before I open my collection and start ripping!
You make a very insightful analogy and I think it is quite revealing.
You state that we won't have Software Engineering until "someone can figure out a way to prove that a given piece of software will perform as it's supposed to."
Alas, this is known to be an impossible task in the general case: this is Turing's halting problem. There's no Newton-caliber breakthrough waiting in the wings here.
Unit testing works because testers know their software systems intimately and can specialize testing code to work in a narrower number of cases. State modeling languages such as ASML can help improve the situation, but seasoned testers know that no tool will help them achieve 100% block and arc coverage of their code.
I'll throw this out for discussion, then: the underlying principals of a software system's design dictate its fundamental physics. It is difficult (sometimes impossible?) to make distinctions between a software's functionality and its substrate.
In an ideal world, developers would find a technique by which they could _always_ separate the two and hence categorize a common physics. The choice of language is part of the physics, but it isn't the sum total: C++ apps can have radically different underlying structures.
The absolute worst is people who think Microsoft making their UI more 'soft' was a direct response to OS X. These UI changes don't get dreamed up at the last minute -- they're part of an evolution that takes years.
Nope.
In fact, Microsoft was working on a rather sophisticated theme feature for XP; along with this feature came a really slick new theme. Alas, theming was cut (as I understand it, the feature required kernel-level work and wasn't stable enough to ship) and the company had to act quickly to pick up the pieces.
XP's softness was indeed a last minute effort. Whether it was a direct response to Aqua is anybody's guess. It seems unlikely to me;/.ers would do good to remember that Microsoft employees have brains capable of thinking original thoughts.
Have you ever stopped to consider what percentage of the browser market Opera represents? Nothing! It's a fraction of a fraction of a percent of the market.
Microsoft doesn't need to cater to Opera users. It needs to ensure quality for its users: namely, the 90+% of the world that uses IE and doesn't mind doing so.
Glowing Purple Rope Of Light
on
Columbia Coverage
·
· Score: 0, Redundant
As reported in SF Gate, an amateur astronomer and shuttle buff happened to capture an amazing photograph of a glowing purple rope of light descending down toward the shuttle. Don't know how authentic this story is, but it sure is interesting:
I agree that a successful commercial browser must be a sledgehammer. However, I think that open-source developers have a valuable opportunity to provide a large number of browsers, including lightweight browsers, to the general public. Agreed, no such browser will satisfy all the users all the time, but with a reasonable selection, most users will find something that satisfies them.
Of course, even given a detailed set of requirements, it is often difficult to discover software that meets those requirements. I've found this doubly true for open source software as the number of potential choices is often large, and it is hard to prune these choices without rolling up the sleeves and trying things out.
I would argue that some additions to persistence format are easily implemented by other vendors, but that in general this is not the case.
Specific additions may be based on design criterion or feature considerations applicable only to one app; documented or not, it is often not practical for others to keep feature parity. Whether the persistence format can generically contain such extensions becomes immaterial if apps can't easily use these extensions. That is, after all, what interoperability means.
I agree with you that it is often possible to resolve these issues, but my experience has been that resolution -- by its political nature -- often arrives far later than divergent implementation.
One of Sincere Choice's principals is Choice Through Interoperability. At first, the idea that "competing products should interoperate with each other through open standards" may appear completely sensible. Interoperability can be (and has been) used as a strike against Microsoft, king of embrace-and-extend.
But buried deep in this particular notion of interoperability is the following thought: a single format should be sufficient for all applications written for a specific domain. This thought suffers in two important ways:
To differentiate their product, corporations must add new features; new features very often impose new requirements on persistence format and hence break interoperability.
Standards bodies move far slower than the companies implementing said standards, often making true interoperability difficult.
I'm not really sure how to avoid these problems. For example, it is not sufficient to add (as has been suggested) a "generic app-specific XML container" to a given standard format. To properly reproduce a document, knowledge of the content in said container might be required.
And as for problems with standards bodies: is it any wonder that Microsoft embraces and extends? Look, for example, at the current disaster of XML Schema, a standard wrought at the hands of academics. Anyone who has used XML Schema in a sophisticated manner can report that the standard lacks a coherent notion of cardinality. Should a company wait until this is repaired by committee, or should it simply embrace what has been done and extend it to meet current needs?
I love xxx.lanl.gov. Sure, the papers are preprints, but I have access to knowledge (in my case, of mathematics) that I can't get access to now that I'm no longer a college student.
The only problem is filtering through the good, the bad, and the ugly. When I saw Paul Ginsparg (the guy who started xxx) speak about five years ago, he mentioned that he fully expected other interested parties to create "virtual journals" -- peer-reviewed, if desired -- by simply commenting on and providing links to the best of the massive xxx database at lanl. I haven't seen this happen yet, which I find strange and sad.
So it seems to me that a slashdot-style discussion board/web-log would perhaps be the most effective tool for locating the best papers. In effect, a carefully tuned version of Slashdot could act as the ultimate virtual journal, using xxx as its database.
Slashdot Mirror
I've discovered an interesting correlation: developers that write visually unpleasant GUIs rarely write aesthetically pleasing code. I think the same attention to detail (or same detailed attention) and same soul of artist is required in both cases.
I had an argument with a co-worker not too long ago about whether developers fuse engineering and art (much like architects,) or whether we're just twiddling lines of machine instructions. He argued (well) that we're not artists and no real creativity is required to write software. I went back, looked at his code, and decided it wasn't all that great.
You're right about one thing: Darl McBride is provably an ambitious young twit. In fact, looking at his photo, I'd say he's likely a mega-twit. Why, then, do you insist that he needs help from Microsoft (or anyone else) to do his dirty deeds?
This is a case of a few men's greed, pure and simple.
But even after I've located a mature library, I still feel those jitters that make me want to do things myself. Why? Because my concept of how the problem should be solved, and how the solution should be exposed, rarely aligns well with how the library author exposed it. More importantly, I typically have a pre-conceived notion of how i'll use the exposed solution to build my software.
When I reach this point, I step back and take a deep breath. If I'm looking at a mature library, chances are the conceptual misalignment stems from the fact that the library author understands the problem space far better than I do.
Berkeley DB provides a good example of a difficult problem space exposed intelligently. Shortly after the jitters, I realized that my understanding of databases was sorely lacking; diving into the documentation helped me understand how to structure my thinking about my application's design.
In summary: I think that developers turn back in disgust from new APIs because the API factoring doesn't match the developers' pre-conceived notions.
But suppose there were a standard cutoff (say, -45dB) and standard length of time (say, 1.5 seconds) that were used to detect tracks for the purposes of thumbprinting. You'd have to perform detection after RMS normalization of the audio (probably to -16dB). You'd have to detect and skip noise at the beginning. Finally, you'd have to tolerate error in matched track lengths.
In theory, I think these are surmountable problems. I just hope someone does this before I open my collection and start ripping!
You state that we won't have Software Engineering until "someone can figure out a way to prove that a given piece of software will perform as it's supposed to."
Alas, this is known to be an impossible task in the general case: this is Turing's halting problem. There's no Newton-caliber breakthrough waiting in the wings here.
Unit testing works because testers know their software systems intimately and can specialize testing code to work in a narrower number of cases. State modeling languages such as ASML can help improve the situation, but seasoned testers know that no tool will help them achieve 100% block and arc coverage of their code.
I'll throw this out for discussion, then: the underlying principals of a software system's design dictate its fundamental physics. It is difficult (sometimes impossible?) to make distinctions between a software's functionality and its substrate.
In an ideal world, developers would find a technique by which they could _always_ separate the two and hence categorize a common physics. The choice of language is part of the physics, but it isn't the sum total: C++ apps can have radically different underlying structures.
Thoughts?
Nope.
In fact, Microsoft was working on a rather sophisticated theme feature for XP; along with this feature came a really slick new theme. Alas, theming was cut (as I understand it, the feature required kernel-level work and wasn't stable enough to ship) and the company had to act quickly to pick up the pieces.
XP's softness was indeed a last minute effort. Whether it was a direct response to Aqua is anybody's guess. It seems unlikely to me; /.ers would do good to remember that Microsoft employees have brains capable of thinking original thoughts.
...are you people insane?
Have you ever stopped to consider what percentage of the browser market Opera represents? Nothing! It's a fraction of a fraction of a percent of the market.
Microsoft doesn't need to cater to Opera users. It needs to ensure quality for its users: namely, the 90+% of the world that uses IE and doesn't mind doing so.
http://www.sfgate.com/cgi-bin/article.cgi?file=/c/ a/2003/02/05/MN192153.DTL
-ThreeToe
-(two killed in battle with raging typhoon)
I'm confused... I get the impression from these reviews that Shelob isn't included in LOTR:TTT. How could that be?
I figured Shelob would be one of the more exciting sequences in the movie, but now I find I may have to wait until next year?
Lord have mercy on my soul!
Of course, even given a detailed set of requirements, it is often difficult to discover software that meets those requirements. I've found this doubly true for open source software as the number of potential choices is often large, and it is hard to prune these choices without rolling up the sleeves and trying things out.
-ThreeToe
-Two Lost In Struggle With Calamari
Behold The Second Power Of The Slashdot Effect.
Wired can take the heat, but the sites linked to by the Wired article are (indrectly) Slashdotted. Can we one day push it to three?
-Three Toe
-(Two Lost In Struggle With Calamari)
Specific additions may be based on design criterion or feature considerations applicable only to one app; documented or not, it is often not practical for others to keep feature parity. Whether the persistence format can generically contain such extensions becomes immaterial if apps can't easily use these extensions. That is, after all, what interoperability means.
I agree with you that it is often possible to resolve these issues, but my experience has been that resolution -- by its political nature -- often arrives far later than divergent implementation.
But buried deep in this particular notion of interoperability is the following thought: a single format should be sufficient for all applications written for a specific domain. This thought suffers in two important ways:
- To differentiate their product, corporations must add new features; new features very often impose new requirements on persistence format and hence break interoperability.
- Standards bodies move far slower than the companies implementing said standards, often making true interoperability difficult.
I'm not really sure how to avoid these problems. For example, it is not sufficient to add (as has been suggested) a "generic app-specific XML container" to a given standard format. To properly reproduce a document, knowledge of the content in said container might be required.And as for problems with standards bodies: is it any wonder that Microsoft embraces and extends? Look, for example, at the current disaster of XML Schema, a standard wrought at the hands of academics. Anyone who has used XML Schema in a sophisticated manner can report that the standard lacks a coherent notion of cardinality. Should a company wait until this is repaired by committee, or should it simply embrace what has been done and extend it to meet current needs?
I think the hackers at MIT have just perpetrated a new hack... but this time it is on the slashdot community! Funny nonetheless...
Fusion is the power source of the future... and always will be.
I love xxx.lanl.gov. Sure, the papers are preprints, but I have access to knowledge (in my case, of mathematics) that I can't get access to now that I'm no longer a college student.
The only problem is filtering through the good, the bad, and the ugly. When I saw Paul Ginsparg (the guy who started xxx) speak about five years ago, he mentioned that he fully expected other interested parties to create "virtual journals" -- peer-reviewed, if desired -- by simply commenting on and providing links to the best of the massive xxx database at lanl. I haven't seen this happen yet, which I find strange and sad.
So it seems to me that a slashdot-style discussion board/web-log would perhaps be the most effective tool for locating the best papers. In effect, a carefully tuned version of Slashdot could act as the ultimate virtual journal, using xxx as its database.
What thinks you all out there?
-ThreeToe
-(Two Lost In Struggle With Calamari)