Re:Aptitude vs. Intelligence vs. Effectiveness
on
Bobby Fischer Online?
·
· Score: 1
And what, exactly, is 'intelligence'? You seem to indicate that it is quantifiable or measurable somehow. An IQ score only measures problem-solving under test conditions. There are more kinds of intelligence than you can shake a stick at.
Actually, such a match was recently completed between to human grandmasters using computers as an aid.
Advanced Chess Leon 2001
The Advanced Chess tournament was held in Leon (Spain) June 8th-11th 2001. This is the 3rd time the event has been held. This was originally the idea of Garry Kasparov. Players competed the help of a computer and a Database. There were 4 games per day and the event was a knockout. Timerate: 20 minutes per player, with 10 or 15 seconds increment after every move.
Official websites: http://www.elajedrezdelfuturo.com
and
http://www.advancedchessleon.com
"With C you can shoot yourself in the foot quite easily. With C++ it is harder, but if you do shoot yourself in the foot, you blow your whole leg off."
Well, I think a lot of the arguments between OODB and RDB camps echo here. Mapping the hierarchical data model of a set of classes (it's there, buried among all the methods) to a relational model has generally been a manual and tedious process. The big problem OODBs have had is their type systems do not map seamlessly with that of a given programming language, forcing post- or pre-processing of the codebase.
Where it gets interesting is where each language develops a type map to a common data model, such as one determined by XML Schema. All of a sudden, the mapping problems to be dealt with diminish in number.
There remains the problem of correlating hierarchical structures to relational ones, however. I'm not knowledgeable enough to proffer whether relational models are inherently superior to hierarchical models for a large realm of applications. What I do know is that relational databases will be around for a long time to come, so XML RDB mapping will remain an issue, as I think it's clear that no automated solution exists that will optimize performance in every case.
W3C is not a standards-setting body, so they say. A Recommendation is the highest level endorsement that W3C gives to a protocol proposal. It may become a standard if ISO or IETF picks it up and runs with it, like they already have done with a competing XML schema language called RELAX.
There's also several other competing schema proposals out there for XML, none of which seem to be getting much of a hearing at W3C: in addition to RELAX there's Schematron, TREX, SOX, Examplatron (sp?), and more. I think it's hard to say at this point which is better suited for most applications processing XML as data, which is why it is of concern to some people that W3C will be pushing to incorporate XML Schema support in other existing and proposed XML protocols.
There are aboud a dozen datatypes that DTD supports. There are 45 that XML Schema supports. That means that for XML documents used to transport large amounts of data, much tighter contraints can be imposed that can be checked up front in the document processor, without the application having to do so.
XML Schema also supports the ability to define your own datatypes through inheritance, so the type space for XML Schema is practically unlimited.
XML has needed a truly powerful schema language to enforce data constraints in data-heavy documents. This is very much akin to having database schema for databases. With a declarative language and a common processor enforcing primary constraints on data, you free each application from having to do their own consistency checks.
XML Schema has a lot of powerful features, including the separation of types from structure, two kinds of type inheritance, modularization, default values for attributes and simple elements, and the flexibility to be as strict or as lax as the situation dictates for validation.
Having said that, the big battle brewing is whether XML Schema is going to be shoehorned into all the other XML protocals that need a data model description before there's been a wide base of practical experience developed. There's already a divide between data modelers and application developers because of the specialized knowledge that SQL and relational database design imposes; I think XML Schema does nothing to narrow that gap, which is unfortunate since class hierarchies and the hierarchical data model of XML seem a natural fit.
There are several pull-based parsers out there, which might be useful for picking out sparse data subsets from an XML document. One such is kXML, out of the University of Dortmund. It's not a full XML parser, but handles what is known as Common XML.
I'm surprised nobody has yet pointed out that books are sold, but software is only licensed. That means that I'm not legally entitle to resell software I've used, since most software is sold as a non-transferable license (which, by the way, can be revoked at any time).
Are we going to start seeing media "licenses" down the road?
I think the other big factor besides SOAP and XML is XML-Schema. Providing a rich constraint language for data, XML-Schema will move a lot of the integrity enforcement from separate islands of code to a declaration that travels with, or it linked to the data. XML-Schema is also descriptive enough to all for the possibility of generating a set of validating classes.
The combination of the three technologies (XML, SOAP, XML-Schema) have been dubbed "The Poor Man's CORBA by some people.
This post should be moderated up. It explains precisely why defects in shipping code occur: almost nobody wants to wait or pay for perfection in software products today.
I would agree. I've never met a requirements document yet that wasn't out of date, wordsmithed to death, and still ambiguous as hell. The ONLY thing that is unambiguous is code. Coding is what drives the ambiguity out. Implementation also makes apparent what should have been in the requirements in the first place.
Insisting on a 'complete' requirements spec that's tossed over the fence to programmers gets you right back to the good ol' waterfall days, and that methodology has been amply proven in practice not to work.
Your only hope is to interact constantly with your customers, and the developers have to be involved. If you have your customer specify requirements without developer involvement, you'll wind up with a crappy system that emulates all the flaws of the the one it was intended to replace. If you beat your customers over the head with their original requirements document, you're not going to have happy customers, either.
>Microsoft has always been about COM and DCOM (which really aren't that bad, except for the whole cross-platform thing).
I've always felt that COM was largely hamstrung by its unstated design goal of making things easy for VB programmers at the cost of making things harder for C/C++/Java programmers. That's in addition to its not being cross-platform.
If VB compatibility was dumped, then COM would be a lot cleaner to work with, IMO.
You elected into the legislature a bunch of lawyers whose campaigns were financed by large contributions from large businesses. Now you complain about the resulting laws that enrich lawyers and big business!
Cause and effect.
Hey, great! Another way to pollute our environment
on
Disposable Cell Phones
·
· Score: 1
I think you're pretty naive. First of all, you seem to think that your government will always be looking out for your best interests. But your interests (and occasionally the majority of peoples' interests) will compete with those who have more money, more knowledge, and more power. Who's interests do you think will get served, and at who's expense?
The ability to monitor every electronic communication gives tremendous power to a very few individuals. Who are they, and what checks do they have on this power?
Do you think, for example, that a third political party has a chance against entrenched Democrat and Republican parties when a few members of those parties can monitor every communication of the third, and can counter their every plan? Those in power will naturally abuse this information to maintain their power, rationalizing that it's for your best interest. And since you won't know about it, what power do you have?
There are two classes of chess titles: those awarded by simple rating, and those awarded by an international executive body.
Rating titles (at least in the US) are as follows:
1200 and below: class E 1200+: class D 1400+: class C 1600+: class B 1800+: class A 2000+: Expert 2200+: Master 2400+: Senior Master (if rating is sustained)
For an international title, such as IM or GM, a you must achieve a "norm" in a tournament. The norm is the number of points you must win based on the relative strength of the other players (IM norms being lower than GM norms). You must achieve three of these norms in a fixed period (two years?) to get your title, which is awarded by an international organization at some future date.
Those who divide people into two kinds and those who don't.
Seriously, though, I think programming is more than mere 'mapping' vs. 'packing'. I'm a database programmer from way back, and one of the first things I do is identify all the data elements in the problem domain at hand (this would be the perjorative 'packing' as I understand it). Yet, having done this, it's much faster then to proceed with the mapping phase: identifying relationships, constraints, business procedures, UI elements, etc. As you go, you enhance your data model and validate your mappings against elements of the data model. Is this so strange?
It's almost like the dichotomy between top-down and bottom-up design. It's best not to do one or the other, but to approach a design from both ends (and the middle!). Any piece of hard-won knowledge about the problem domain that you come across has a place, even if its mapping isn't readily apparent... don't lose it!
You mean you actually read the spec? By the time the spec is written 1) all involved have work long and hard enough on it that they've memorized all of the requirements; 2) it doesn't reflect all the tacit agreements as to what the real requirements are; 3) no document, no matter how exhaustive, is going to be as detailed and unambiguous as real code; 4) what looked good on paper suffers on the computer screen.
Slashdot Mirror
And what, exactly, is 'intelligence'? You seem to indicate that it is quantifiable or measurable somehow. An IQ score only measures problem-solving under test conditions. There are more kinds of intelligence than you can shake a stick at.
I think it's Duncan Suttles they've been playing.
Actually, such a match was recently completed between to human grandmasters using computers as an aid.
Advanced Chess Leon 2001
The Advanced Chess tournament was held in Leon (Spain) June 8th-11th 2001. This is the 3rd time the event has been held. This was originally the idea of Garry Kasparov. Players competed the help of a computer and a Database. There were 4 games per day and the event was a knockout. Timerate: 20 minutes per player, with 10 or 15 seconds increment after every move.
Official websites: http://www.elajedrezdelfuturo.com
and
http://www.advancedchessleon.com
It's a metadatabase.
It was Bjarne Stroustroup himself that said:
"With C you can shoot yourself in the foot quite easily. With C++ it is harder, but if you do shoot yourself in the foot, you blow your whole leg off."
Quote:
"It completely destroys the aluminium. It leaves nothing behind."
So, the fungus splits the aluminum atoms or fuses them together? Aluminum is an element, it can't just "disappear".
Well, I think a lot of the arguments between OODB and RDB camps echo here. Mapping the hierarchical data model of a set of classes (it's there, buried among all the methods) to a relational model has generally been a manual and tedious process. The big problem OODBs have had is their type systems do not map seamlessly with that of a given programming language, forcing post- or pre-processing of the codebase.
Where it gets interesting is where each language develops a type map to a common data model, such as one determined by XML Schema. All of a sudden, the mapping problems to be dealt with diminish in number.
There remains the problem of correlating hierarchical structures to relational ones, however. I'm not knowledgeable enough to proffer whether relational models are inherently superior to hierarchical models for a large realm of applications. What I do know is that relational databases will be around for a long time to come, so XML RDB mapping will remain an issue, as I think it's clear that no automated solution exists that will optimize performance in every case.
W3C is not a standards-setting body, so they say. A Recommendation is the highest level endorsement that W3C gives to a protocol proposal. It may become a standard if ISO or IETF picks it up and runs with it, like they already have done with a competing XML schema language called RELAX.
There's also several other competing schema proposals out there for XML, none of which seem to be getting much of a hearing at W3C: in addition to RELAX there's Schematron, TREX, SOX, Examplatron (sp?), and more. I think it's hard to say at this point which is better suited for most applications processing XML as data, which is why it is of concern to some people that W3C will be pushing to incorporate XML Schema support in other existing and proposed XML protocols.
There are aboud a dozen datatypes that DTD supports. There are 45 that XML Schema supports. That means that for XML documents used to transport large amounts of data, much tighter contraints can be imposed that can be checked up front in the document processor, without the application having to do so.
XML Schema also supports the ability to define your own datatypes through inheritance, so the type space for XML Schema is practically unlimited.
XML has needed a truly powerful schema language to enforce data constraints in data-heavy documents. This is very much akin to having database schema for databases. With a declarative language and a common processor enforcing primary constraints on data, you free each application from having to do their own consistency checks.
XML Schema has a lot of powerful features, including the separation of types from structure, two kinds of type inheritance, modularization, default values for attributes and simple elements, and the flexibility to be as strict or as lax as the situation dictates for validation.
Having said that, the big battle brewing is whether XML Schema is going to be shoehorned into all the other XML protocals that need a data model description before there's been a wide base of practical experience developed. There's already a divide between data modelers and application developers because of the specialized knowledge that SQL and relational database design imposes; I think XML Schema does nothing to narrow that gap, which is unfortunate since class hierarchies and the hierarchical data model of XML seem a natural fit.
This should be moderated to 'funny'
This looks like a hoax. A crafty one, though.
There are several pull-based parsers out there, which might be useful for picking out sparse data subsets from an XML document. One such is kXML, out of the University of Dortmund. It's not a full XML parser, but handles what is known as Common XML.
http://www-ai.cs.uni-dortmund.de/SOFTWARE/KXML/
http://www.simonstl.com/articles/cxmlspec.txt
I'm surprised nobody has yet pointed out that books are sold, but software is only licensed. That means that I'm not legally entitle to resell software I've used, since most software is sold as a non-transferable license (which, by the way, can be revoked at any time).
Are we going to start seeing media "licenses" down the road?
I think the other big factor besides SOAP and XML is XML-Schema. Providing a rich constraint language for data, XML-Schema will move a lot of the integrity enforcement from separate islands of code to a declaration that travels with, or it linked to the data. XML-Schema is also descriptive enough to all for the possibility of generating a set of validating classes.
The combination of the three technologies (XML, SOAP, XML-Schema) have been dubbed "The Poor Man's CORBA by some people.
I think the main argument for going to Mars rather than the Moon is that Mars is far more likely to have significant amounts of water.
This post should be moderated up. It explains precisely why defects in shipping code occur: almost nobody wants to wait or pay for perfection in software products today.
I would agree. I've never met a requirements document yet that wasn't out of date, wordsmithed to death, and still ambiguous as hell. The ONLY thing that is unambiguous is code. Coding is what drives the ambiguity out. Implementation also makes apparent what should have been in the requirements in the first place.
Insisting on a 'complete' requirements spec that's tossed over the fence to programmers gets you right back to the good ol' waterfall days, and that methodology has been amply proven in practice not to work.
Your only hope is to interact constantly with your customers, and the developers have to be involved. If you have your customer specify requirements without developer involvement, you'll wind up with a crappy system that emulates all the flaws of the the one it was intended to replace. If you beat your customers over the head with their original requirements document, you're not going to have happy customers, either.
>Microsoft has always been about COM and DCOM (which really aren't that bad, except for the whole cross-platform thing).
I've always felt that COM was largely hamstrung by its unstated design goal of making things easy for VB programmers at the cost of making things harder for C/C++/Java programmers. That's in addition to its not being cross-platform.
If VB compatibility was dumped, then COM would be a lot cleaner to work with, IMO.
You elected into the legislature a bunch of lawyers whose campaigns were financed by large contributions from large businesses. Now you complain about the resulting laws that enrich lawyers and big business!
Cause and effect.
Does the world really need this?
I think you're pretty naive. First of all, you seem to think that your government will always be looking out for your best interests. But your interests (and occasionally the majority of peoples' interests) will compete with those who have more money, more knowledge, and more power. Who's interests do you think will get served, and at who's expense?
The ability to monitor every electronic communication gives tremendous power to a very few individuals. Who are they, and what checks do they have on this power?
Do you think, for example, that a third political party has a chance against entrenched Democrat and Republican parties when a few members of those parties can monitor every communication of the third, and can counter their every plan? Those in power will naturally abuse this information to maintain their power, rationalizing that it's for your best interest. And since you won't know about it, what power do you have?
There are two classes of chess titles: those awarded by simple rating, and those awarded by an international executive body.
Rating titles (at least in the US) are as follows:
1200 and below: class E
1200+: class D
1400+: class C
1600+: class B
1800+: class A
2000+: Expert
2200+: Master
2400+: Senior Master (if rating is sustained)
For an international title, such as IM or GM, a you must achieve a "norm" in a tournament. The norm is the number of points you must win based on the relative strength of the other players (IM norms being lower than GM norms). You must achieve three of these norms in a fixed period (two years?) to get your title, which is awarded by an international organization at some future date.
Those who divide people into two kinds and those who don't.
Seriously, though, I think programming is more than mere 'mapping' vs. 'packing'. I'm a database programmer from way back, and one of the first things I do is identify all the data elements in the problem domain at hand (this would be the perjorative 'packing' as I understand it). Yet, having done this, it's much faster then to proceed with the mapping phase: identifying relationships, constraints, business procedures, UI elements, etc. As you go, you enhance your data model and validate your mappings against elements of the data model. Is this so strange?
It's almost like the dichotomy between top-down and bottom-up design. It's best not to do one or the other, but to approach a design from both ends (and the middle!). Any piece of hard-won knowledge about the problem domain that you come across has a place, even if its mapping isn't readily apparent... don't lose it!
You mean you actually read the spec? By the time the spec is written 1) all involved have work long and hard enough on it that they've memorized all of the requirements; 2) it doesn't reflect all the tacit agreements as to what the real requirements are; 3) no document, no matter how exhaustive, is going to be as detailed and unambiguous as real code; 4) what looked good on paper suffers on the computer screen.
Just my embittered two cents worth...