Any time you are trying to explain something, you have to bridge the gap between what they already know and understand, and what they need to know and understand.
When a programmer first learns about data structures, s/he might learn about "trees". Imagine explaining a tree without the implicit metaphor of roots, branches, and leaves. Sure, you could do it, but not without a lot of pain. Maybe it would be a "pointer-based hierarchical polyfurcating network of arbitrary data nodes".
But it goes beyond just explaining the concept. If your analogy is any good, many items are, at a basic level, self-documenting. A debugger or profiler, for instance, uses the analogy of a VCR. You already know what the play, pause, and stop buttons are likely to do. You might consult the docs to see what exactly the difference is between pause and stop, but whatever it is it won't be a big surprise.
While your pyramid scheme analogy is fairly accurate (your stock sells for what someone else will pay for it, completely independent of the actual worth of the company), there are two flaws in your argument.
1. The economy is not necessarily a bounded system. The GNP grows, on average, about 3% per year. While it has always been a mystery to me why stock gains and GNP gains are not in the same ballpark, there is no evidence that there is a ceiling to GNP.
2. Even if an individual company does "max out" its profit potential, that just means it is time to convert from a growth stock to a dividend stock. If you are so inclined, you can think of non-dividend-paying stocks simply as stocks that could potentially pay dividends in the future, and those dividends will be roughly the size of their net profits. Thus, you're speculating on what those net profits will be in the future. This is only slightly riskier than speculating that a dividend-paying stock will continue to pay the same (or better) dividend in the future.
While the last thing I want to do is defend A.I. researchers, they have gotten a raw deal in one respect. Whenever a program performs a human-like endeavor (e.g. playing chess) at human-level-or-above ability, the first thing people ask is "How does it work?" The programmers then proudly explain their algorithms (e.g. adaptive n-ply search with a heuristic evaluation function emphasizing piece mobility blah blah blah).
Lo and behold, what first appeared to be intelligence is now just an elaborate sequence of if-then statements. Anyone could have done it. It's not intelligence at all. It's just following a blueprint. You call this intelligence?
In other words, the lay public expects A.I. to have creativity and strokes of genius, which is much more than they expect of most humans. Or they expect it to be furry with big eyes that makes cooing noises when you pet it. As soon as one realizes that A.I. consists of a computer program, any notion of intelligence evaporates.
My understanding of.NET is mostly based on water-cooler conversations and reading the introduction to an introduction, so don't take any of this as gospel. But here's my quick, undoubtedly incomplete summary:
.NET is a marketing term for a group of several vaguely related technologies.
The Common Language Runtime (CLR) is a virtual machine that runs intermediate code. Thus, you can write a program in Visual Basic, C#, or several other languages and compile them to the same intermediate code. The virtual machine throws in a bunch of java-inspired features, like garbage collection, absence of pointers, and a giant class library that exposes much of the harder-to-get-to aspects of Windows. Since the class library is available from any.NET programming language, the choice between using C#, VB, or something else is mostly just a matter of whether you like semi-colons or not.
The Visual Studio.NET IDE provides lots of tools to "simplify" programming and debugging. For instance, if you want to make a [Microsoft] standards-compliant web service, you can go through a wizard which generates the deployment descriptors and several pages of source code, including a big comment telling you were to put your logic. Similary, if your app manipulates a database, a wizard helps you make the SQL query or create a stored procedure. Of course, these wizards create lowest-common-denominator, bloated code that is nearly impossible to modify by hand without breaking it.
ASP.NET is a language and server for creating dynamic web pages. In theory, you can write an ASP.NET application and pretend you're just writing an ordinary client-side GUI, attaching event handlers to buttons and drop-down lists without thinking about the mechanics of HTTP Posting. In reality, this leads to constant round trips and page refreshes that are only practical on the developer's machine.
I'm sure there are several other technologies lumped in with.NET, but I can't think of them right now.
As far as why you should care about XML,.NET, etc., the goal (regardless of whether you think Microsoft helped move towards this goal) is to have programs that can interact with each other. Sure, XML is verbose, but it just might save me some time and heartache when I'm trying to parse through your data that's in a flat text file, or worse yet, locked up as a binary file inside your proprietary database.
Slashdot Mirror
When a programmer first learns about data structures, s/he might learn about "trees". Imagine explaining a tree without the implicit metaphor of roots, branches, and leaves. Sure, you could do it, but not without a lot of pain. Maybe it would be a "pointer-based hierarchical polyfurcating network of arbitrary data nodes".
But it goes beyond just explaining the concept. If your analogy is any good, many items are, at a basic level, self-documenting. A debugger or profiler, for instance, uses the analogy of a VCR. You already know what the play, pause, and stop buttons are likely to do. You might consult the docs to see what exactly the difference is between pause and stop, but whatever it is it won't be a big surprise.
While your pyramid scheme analogy is fairly accurate (your stock sells for what someone else will pay for it, completely independent of the actual worth of the company), there are two flaws in your argument.
1. The economy is not necessarily a bounded system. The GNP grows, on average, about 3% per year. While it has always been a mystery to me why stock gains and GNP gains are not in the same ballpark, there is no evidence that there is a ceiling to GNP.
2. Even if an individual company does "max out" its profit potential, that just means it is time to convert from a growth stock to a dividend stock. If you are so inclined, you can think of non-dividend-paying stocks simply as stocks that could potentially pay dividends in the future, and those dividends will be roughly the size of their net profits. Thus, you're speculating on what those net profits will be in the future. This is only slightly riskier than speculating that a dividend-paying stock will continue to pay the same (or better) dividend in the future.
Lo and behold, what first appeared to be intelligence is now just an elaborate sequence of if-then statements. Anyone could have done it. It's not intelligence at all. It's just following a blueprint. You call this intelligence?
In other words, the lay public expects A.I. to have creativity and strokes of genius, which is much more than they expect of most humans. Or they expect it to be furry with big eyes that makes cooing noises when you pet it. As soon as one realizes that A.I. consists of a computer program, any notion of intelligence evaporates.
- The Common Language Runtime (CLR) is a virtual machine that runs intermediate code. Thus, you can write a program in Visual Basic, C#, or several other languages and compile them to the same intermediate code. The virtual machine throws in a bunch of java-inspired features, like garbage collection, absence of pointers, and a giant class library that exposes much of the harder-to-get-to aspects of Windows. Since the class library is available from any
.NET programming language, the choice between using C#, VB, or something else is mostly just a matter of whether you like semi-colons or not.
- The Visual Studio
.NET IDE provides lots of tools to "simplify" programming and debugging. For instance, if you want to make a [Microsoft] standards-compliant web service, you can go through a wizard which generates the deployment descriptors and several pages of source code, including a big comment telling you were to put your logic. Similary, if your app manipulates a database, a wizard helps you make the SQL query or create a stored procedure. Of course, these wizards create lowest-common-denominator, bloated code that is nearly impossible to modify by hand without breaking it.
- ASP.NET is a language and server for creating dynamic web pages. In theory, you can write an ASP.NET application and pretend you're just writing an ordinary client-side GUI, attaching event handlers to buttons and drop-down lists without thinking about the mechanics of HTTP Posting. In reality, this leads to constant round trips and page refreshes that are only practical on the developer's machine.
I'm sure there are several other technologies lumped in withAs far as why you should care about XML, .NET, etc., the goal (regardless of whether you think Microsoft helped move towards this goal) is to have programs that can interact with each other. Sure, XML is verbose, but it just might save me some time and heartache when I'm trying to parse through your data that's in a flat text file, or worse yet, locked up as a binary file inside your proprietary database.