For that matter, you can embed ActiveX components in HTML pages rendered by IE. But may you rot in hell if you do. I've worked for months trying to automate (via screen-scraping) a web front-end for a third-party application that's built using embedded ActiveX controls *and* an out-of-process server on the client to store state, and it's the biggest heap of bloated crap you ever saw. "Thin client" my ass.
OK, but suppose I still use decimate to mean "reduce by a tenth". Is the meaning of the word defined by my usage, or the usage of people who use it to mean (roughly) "reduce to a tenth"? What if I've been using it for twenty years to mean "promote to the status of chairperson"? Is that usage valid?
I'm assuming that nobody, outside of some very specialised contexts (the Celtic Military Re-Enactment Society, perhaps) uses "car" to refer to a chariot (although if you want to make sense of some bits of Shelley, for instance, you need to be aware that that's what he meant). On the other hand, there are people who know what "decimate" means, and use it correctly, and people who don't know what it means and use it incorrectly - just as I would be using it incorrectly if I used it to mean "promote to the status of chairperson".
That the meanings of words are defined over time by common and accepted usage does not imply that there are no mistaken usages, or that it is impossible for anybody to be wrong about the meaning of a word. I'll give you "hopefully", as I use it the same way as everybody else nowadays, but I'll keep my sense of "decimate" thank you - and "refute", while we're at it.
Don't get me wrong, I find the abuse of marginal features of a language to get it to behave in ways entirely unimagined by the language's original designers a highly worthwhile activity - but not in a production environment. In production, you should stick as far as possible to the best documented and most easily supported and understood features of whatever language your PHB has decided you're using; unless you want whoever has to maintain your code to curse you for eternity...
Alan Sondheim is the author of a lengthy meditation on the poetry and philosophy of cyberspace, The Internet Text, amongst (many) other things. He has used shell scripts and other techniques to generate texts. He writes about sex, death, the body, desire, trauma, capital, terror, etc.; technology and its implications remain an important theme throughout.
I am a Safari subscriber, and find it invaluable for reference searching on things like the MySQL API.
Recently, however, I've started teaching myself Haskell, and I've noticed that there is next to nothing in the range of books - which includes books by publishers other than O'Reilly - on Safari that deals with Functional Programming in general or Haskell in particular.
Mind you, most people doing FP probably have access to very good university libraries, so I guess the market isn't that huge...
If you're programming in VBA (or Guile / Scheme, say), you're programming, not just using. To the extent that you program, even in VBA, you're a programmer (although if you program in VBA, you're also a weenie). It remains the case that a programmer is something that, if you don't program, you are not.
But yay, obviously, for more open architectures. I'm all for an OS that works like Squeak but looks like less of a toy.
Here's a prediction: the moment you succeed in making the distinction between "user" and "programmer" disappear, most of your potential users will disappear with it. Almost all of them who are not also programmers (in the old, pre-disappearance-of-the-distinction-between-users -and-programmers, sense), in fact.
Configurable desktops give users choices, and users like choices provided they're easy to make and easy to undo. Programming is about making decisions which are often hard to make and hard to undo. Unlike selecting a theme for a desktop, which is a matter of taste and the whim of the moment, programmers have to try to get lots of complicatedly interdependent things right in ways that matter.
I look forward to the first release of Tunes - hopefully some time before my retirement - with great anticipation, but at best such "entirely new software architectures" will empower some users do some things that they used to need to be programmers to do.
I went to an independent (non-, or in my case partially-, state-funded; not the same as public school) boys' school in the UK. I was a precocious, introverted, abrasive, blurting, somewhat arrogant and somewhat unhappy teenager, and I rejoiced in a small number of friends whose characters were composed of much the same qualities and defects in varying measure.
I looked down on other teenagers for a variety of reasons, not altogether to do with "intelligence". I felt at the time that there was a choice to be made between being - or at least trying to be - clever, and being considered fully decent and acceptable by other people. The struggle to be considered decent and acceptable by other people was fairly universal in my school. I think it very unlikely that I had it the worst of all. If I had been clever, and Jewish, and homosexual: then, maybe.
It infuriates me even now when people declare that the purpose of schooling is to socialize people: socialize them into what? I learned the most valuable lessons of my youth about how to live and work with other people outside of my school, and picked up the most damaging emotional habits - snobbery, deviousness, paranoia, coldness and defensiveness - inside it. Why on earth would anybody construct an institution like a school (well, OK, YMMV: like my school; or my sister's, or the comprehensive some my friends went to) for purposes of socialization? What kind of society can they possibly have been dreaming of?
It seems that PHP will certainly replace other language (
sic) like Perl or CGI for web services in the future. This is due to its simplicity of use and many developers known (sic) about this and has (sic)already developed software that run with PHP on a web server. When you need to add some popular web service to your web server, you will inevitably find that PHP is required and that you need to install it with Apache.
Three things:
Didn't anyone edit this?
Does the author know what "web services" are? It doesn't sound it...
No, I don't think PHP will "certainly" replace Perl or CGI for web applications; AxKit is one good reason why not, and Perl::Mason is another. And CGI isn't a language.
Note that I use, and like, PHP and have no axe to grind against the language or its enthusiasts. But this kind of vague, misinformed fluff doesn't give me a lot of confidence in the rest of the article...
Re:xml turns 5...
on
XML Turns 5
·
· Score: 2, Interesting
Quite so; a recent attempt at preserving old media is noted here.
With this in mind, may I direct the attention of budding geek archivists and antiquarians to Bruce Sterling's (and others') Dead Media Project, which seeks to document and analyse the conditions surrounding the life and death of media?
Re:xml turns 5...
on
XML Turns 5
·
· Score: 5, Interesting
It will probably be another 5, or 50, years before we know to what extent XML was the answer to the problem of data obsolescence and the degradation of old formats (like "bit rot", this is a handy but misleading way of framing the problem, which is not that the formats themselves degrade but that the supporting software infrastructure fragments, evolves or falls into disuse. The question with XML is then whether XML-encoded data will prove recoverable and intelligible after SAX, DOM, SOAP and all the rest have fallen into obscurity).
XML's self-description is one layer deep: data and metadata are packaged together. This layer can be seen as one layer of insulation against obsolescence: so long as the metadata remains meaningful, the meaning of the data can be ascertained and recovered. But the metadata is itself data, and if it too loses its meaning then it will be of no help at all.
For any data at all to have a semantic value it must have a context, and contexts change over time. XML is meant to ease the translation of data between contexts, but it cannot preserve meaning for all time.
XXML - Extensible extensible markup language. Allows you to extend and redefine the EBNF productions which define the XML syntax. Roll your own roll-your-own markup language. Compatible parsers are few and far between, but an experimental application called YACC is rumoured to have some of the required capabilities.
XXXML, or extensible extensible extensible markup language, is expected to undergo widespread early adoption by pr0n sites, as it permits a hitherto unimaginable flexibility in permutations and combinations of content...
I went to school in the UK. I even had (well, my Dad had) an Acorn Risc PC at home. My nostalgia for it has dribbled away over the years, but it was a genuinely exciting piece of kit at the time - I even did some ARM Assembler coding on it, which was an education in itself.
Castle ripping off Linux, if true, is both sad and - I hope, not being a lawyer - actionable. They should be forced to come clean about it, forced to make suitable reparations, and prevented from doing anything of the sort again.
The saddest thing is that if done legitimately, the incorporation of Linux source code into an alternative OS would be a further vindication of the free software credo - proof that keeping software free promotes innovation, diversity and a healthy commons. I guess that the main problem in this instance is the proprietory nature of parts of RISC OS, which would have prevented such a legitimate use of GPL'd code; otherwise, there'd be no incentive to steal.
If RISC OS itself were free software, it might have evolved to a far greater degree following Acorn's abandonment of the platform. There were enough enthusiasts around for this to happen, including some very gifted coders (I'm thinking especially of the guy who coded a Quake engine for the platform - forget his name). Instead the OS has fallen into stagnation, irrelevancy and - it would seem - the use of unscrupulous practices by some of its last surviving advocates. This is a dismal shame.
Re:"Where we're going, we don't need roads..."
on
Gnome 2.2 Released
·
· Score: 1
Put me disturbingly in mind of:
You won't need eyes to see where
we're going
- gurgled by deranged Sam Neill scientist character in gothic-shockfest-in-space Event Horizon...
Five years ago I was at a friend's house and his friend brought over an ancient C64 and a box full of tapes, and we plugged everything into everything else and tried to load up "Monty on the Run" (which has some of the best music of any game ever) and it worked and this was very cool and impressive and made us think for a moment about the simple pleasures (and general unbearable tedium, as we waited for the thing to load) of our mis-spent youth. We then unplugged everything and put it back into the box and got on with our lives. If, in five years time, someone comes over to my house with a still-working C64 and we can do the same thing all over again, that will be great. Meanwhile, I can't honestly say that I give that much of a monkey's.
I love the fact that there is always more to learn. In the past year I've learnt more than at the start of the year I even imagined there was to learn. If this coming year is likely to be the same, then welcome to it.
The one feeling I've had all the time during my short (two year) career so far as a programmer is a feeling of profound dissatisfaction with the way I'm doing whatever I'm doing at the moment. How can a year of being dissatisfied be a fulfilling one? The answer is that next time around, next spin of the wheel, I know I will try to do it better, and I am already beginning to learn what "better" means.
Right now I'm building a business objects layer for a client-server application, and confronting for the first time in practice the issues involved in mapping an "object model" made up of classes and contracts to a relational database. It's a fascinating and difficult area - grandiose schemas like EJB attest to the complexity of the problem domain. What I build today has to work reliably and hang together sensibly, and if it does that then everyone I work with and for will be satisfied. But the process of learning how to do it will affect the way I tackle the next problem, and the one after.
I believe that learning to be a good programmer means having this dual perspective: doing what you have to do today, as best you can, so that you deliver what your bosses are paying you to deliver, and at the same time seeing it as a stepping stone, something where just dumbly applying what you know already will result not only in inferior code but also in inferior understanding.
The older I get the more I appreciate social skills over raw intelligence or mathematical/logical ability. If it all comes in one package, jolly good. However, if I had to choose between a budding physics genius with a highly abrasive personality and a slightly well performing person with good social skills, I'd choose the latter. No question about it.
"Good social skills" is a bit broad. I know some fairly brilliant people whose social style is unconventional, and rubs some people up the wrong way. They don't have what you would call good social skills, in the sense of being able to make just anybody feel at ease with them on first acquaintance. They take some getting to know. And once you get to know them, they're great: great to work with, often hilariously funny, and still just as brilliant.
Think of it this way (for a moment, if you will...). Good teamwork requires trust. People with good social skills build up a superficial level of trust quickly, and deeper levels of trust over time. Good people with less good social skills are not as adept at building up that superficial level of trust, but once a trust-relationship has been established will often tend to be extremely loyal and "other-orientated". It often turns out with very brilliant and somewhat idiosyncratic individuals that they have a few absolutely sustaining relationships with a few very trusted other people.
In the right circumstances, these people are dynamite: and a lot of them go into the sciences looking for that kind of social dynamic (as well as truth, intellectual adventure and the advancement of human knowledge, of course). If "good social skills" are a prerequisite for advancement everywhere and all the time, then these people are going to find it almost impossibly hard to make an entry. That's actually what a lot of them are afraid of.
Prima donnas are another matter, and I've met one or two of those as well; but those are people with positively malignant social skills, rather than people who are simply awkward or retiring. You don't want those people anywhere near your team because they will drive everyone else crazy; and in that case, I agree with the above poster, it really doesn't matter how brilliant they are.
Re:Absolutely the best Java book I've read
on
Effective Java
·
· Score: 1
Agreed; I found it useful as a Java newbie, because it gave me a view of the language "from the other side", a sense of where its complexities lay. It is a fine example of how to think about design issues in the context of a set of linguistic constraints, and for this reason has something of value even for non-Java coders (as the Scott Meyers series has much of value for non-C++ coders).
Funnily enough, I always find math a whole lot easier to understand myself once I've explained it to a computer.
I find it a lot harder to hold a mathematical idea in my head without some sort of procedural definition of what's going on, step by step, to link it to.
My computing hobby over the past twenty years has probably been the sole factor preventing what little mathematical literacy I gained at school from decaying completely...
Correction: C and C++ compiled with a compiler targetted at the same architecture compile to the same machine code.
Then again, it's surely not impossible to come up with a C# compiler that compiles to something other than MS IL - Java bytecodes, for instance, or native machine code...
Why use perl.NET if the only difference between it and VB.NET is the way you for a "for" loop?
The answer, I think, is that that's not the only difference. C and C++ compile to the same assembly language, but are sufficiently different for there to be good reasons for wanting to code in the one rather than the other. I believe Perl's new VM, "Parrot", is intended to support bytecodes from other languages besides Perl.
Microsoft's IL is not 100% generic - it's reputedly difficult to compile a language like Python to it sensibly, for reasons largely to do with typing if I understand aright - but it's generic enough to support multiple programming idioms that are different enough for programmers to have reasons to choose one over another, and those reasons will be the usual ones to do with familiarity, expressiveness, appropriateness to the problem domain, corporate politics and blind zealotry.
For my purposes, as a coder already locked into the MS world in my day job, MS's redesign of their fundamental API for Windows programming is the strongest "draw" in.NET; that and the XML/SOAP support, which is integrated into the.NET languages and tools to an extent that is unprecedented in the MS world, and probably elsewhere too. Maybe JAXP comes close: I wouldn't know.
It looks to me as if.NET comprises some of the best development work MS has done for ages - certainly some of the most ambitious. That doesn't mean it will, or should, rock your world if your world revolves around Java, or Perl, or Common Lisp or whatever. But for those of us who are already in that dismal place known as MS platform lock-in, it's a ray of light to say the least.
I want a better Zope very much, having toyed with Zope 2 and found it a bit of an uncomfortable fit. As a developer, I'd like to try Zope for applications above all, but I also want to be able to handle the "content" side of things with a minimum of fuss, so more orthogonality with regard to logic and presentation is a Good Thing for my purposes.
One thing I think Zope could really use is some pattern-based documentation, a wide-angle-lens overview with an emphasis on architectural idioms and good practice. The material available at the moment is by no means poor, but it leans towards the How-To rather than the Why-, When- or Whether-To. This is a fairly unavoidable characteristic of a software project in development, unless it's driven from the outset by a powerfully articulated vision, but as it comes out of the other end of a major refactoring Zope must by now have a whole load of users, developers and advocates with a pretty clear idea of what the Zope Thing is all about, and it's this that needs to be communicated to those of us who've tinkered a bit but not really managed to see how it all fits together.
Slashdot Mirror
For that matter, you can embed ActiveX components in HTML pages rendered by IE. But may you rot in hell if you do. I've worked for months trying to automate (via screen-scraping) a web front-end for a third-party application that's built using embedded ActiveX controls *and* an out-of-process server on the client to store state, and it's the biggest heap of bloated crap you ever saw. "Thin client" my ass.
OK, but suppose I still use decimate to mean "reduce by a tenth". Is the meaning of the word defined by my usage, or the usage of people who use it to mean (roughly) "reduce to a tenth"? What if I've been using it for twenty years to mean "promote to the status of chairperson"? Is that usage valid?
I'm assuming that nobody, outside of some very specialised contexts (the Celtic Military Re-Enactment Society, perhaps) uses "car" to refer to a chariot (although if you want to make sense of some bits of Shelley, for instance, you need to be aware that that's what he meant). On the other hand, there are people who know what "decimate" means, and use it correctly, and people who don't know what it means and use it incorrectly - just as I would be using it incorrectly if I used it to mean "promote to the status of chairperson".
That the meanings of words are defined over time by common and accepted usage does not imply that there are no mistaken usages, or that it is impossible for anybody to be wrong about the meaning of a word. I'll give you "hopefully", as I use it the same way as everybody else nowadays, but I'll keep my sense of "decimate" thank you - and "refute", while we're at it.
...this thread on Lambda the Ultimate for a recent discussion of issues related to Bray's article.
...or you could program in Scheme.
Don't get me wrong, I find the abuse of marginal features of a language to get it to behave in ways entirely unimagined by the language's original designers a highly worthwhile activity - but not in a production environment. In production, you should stick as far as possible to the best documented and most easily supported and understood features of whatever language your PHB has decided you're using; unless you want whoever has to maintain your code to curse you for eternity...
Alan Sondheim is the author of a lengthy meditation on the poetry and philosophy of cyberspace, The Internet Text, amongst (many) other things. He has used shell scripts and other techniques to generate texts. He writes about sex, death, the body, desire, trauma, capital, terror, etc.; technology and its implications remain an important theme throughout.
You almost certainly don't mean Functional Programming...;)
I am a Safari subscriber, and find it invaluable for reference searching on things like the MySQL API.
Recently, however, I've started teaching myself Haskell, and I've noticed that there is next to nothing in the range of books - which includes books by publishers other than O'Reilly - on Safari that deals with Functional Programming in general or Haskell in particular.
Mind you, most people doing FP probably have access to very good university libraries, so I guess the market isn't that huge...
If you're programming in VBA (or Guile / Scheme, say), you're programming, not just using. To the extent that you program, even in VBA, you're a programmer (although if you program in VBA, you're also a weenie). It remains the case that a programmer is something that, if you don't program, you are not.
But yay, obviously, for more open architectures. I'm all for an OS that works like Squeak but looks like less of a toy.
Here's a prediction: the moment you succeed in making the distinction between "user" and "programmer" disappear, most of your potential users will disappear with it. Almost all of them who are not also programmers (in the old, pre-disappearance-of-the-distinction-between-users -and-programmers, sense), in fact.
Configurable desktops give users choices, and users like choices provided they're easy to make and easy to undo. Programming is about making decisions which are often hard to make and hard to undo. Unlike selecting a theme for a desktop, which is a matter of taste and the whim of the moment, programmers have to try to get lots of complicatedly interdependent things right in ways that matter.
I look forward to the first release of Tunes - hopefully some time before my retirement - with great anticipation, but at best such "entirely new software architectures" will empower some users do some things that they used to need to be programmers to do.
I went to an independent (non-, or in my case partially-, state-funded; not the same as public school) boys' school in the UK. I was a precocious, introverted, abrasive, blurting, somewhat arrogant and somewhat unhappy teenager, and I rejoiced in a small number of friends whose characters were composed of much the same qualities and defects in varying measure.
I looked down on other teenagers for a variety of reasons, not altogether to do with "intelligence". I felt at the time that there was a choice to be made between being - or at least trying to be - clever, and being considered fully decent and acceptable by other people. The struggle to be considered decent and acceptable by other people was fairly universal in my school. I think it very unlikely that I had it the worst of all. If I had been clever, and Jewish, and homosexual: then, maybe.
It infuriates me even now when people declare that the purpose of schooling is to socialize people: socialize them into what? I learned the most valuable lessons of my youth about how to live and work with other people outside of my school, and picked up the most damaging emotional habits - snobbery, deviousness, paranoia, coldness and defensiveness - inside it. Why on earth would anybody construct an institution like a school (well, OK, YMMV: like my school; or my sister's, or the comprehensive some my friends went to) for purposes of socialization? What kind of society can they possibly have been dreaming of?
From the article:
Three things:
Note that I use, and like, PHP and have no axe to grind against the language or its enthusiasts. But this kind of vague, misinformed fluff doesn't give me a lot of confidence in the rest of the article...
Quite so; a recent attempt at preserving old media is noted here.
With this in mind, may I direct the attention of budding geek archivists and antiquarians to Bruce Sterling's (and others') Dead Media Project, which seeks to document and analyse the conditions surrounding the life and death of media?
It will probably be another 5, or 50, years before we know to what extent XML was the answer to the problem of data obsolescence and the degradation of old formats (like "bit rot", this is a handy but misleading way of framing the problem, which is not that the formats themselves degrade but that the supporting software infrastructure fragments, evolves or falls into disuse. The question with XML is then whether XML-encoded data will prove recoverable and intelligible after SAX, DOM, SOAP and all the rest have fallen into obscurity).
XML's self-description is one layer deep: data and metadata are packaged together. This layer can be seen as one layer of insulation against obsolescence: so long as the metadata remains meaningful, the meaning of the data can be ascertained and recovered. But the metadata is itself data, and if it too loses its meaning then it will be of no help at all.
For any data at all to have a semantic value it must have a context, and contexts change over time. XML is meant to ease the translation of data between contexts, but it cannot preserve meaning for all time.
XXML - Extensible extensible markup language. Allows you to extend and redefine the EBNF productions which define the XML syntax. Roll your own roll-your-own markup language. Compatible parsers are few and far between, but an experimental application called YACC is rumoured to have some of the required capabilities.
XXXML, or extensible extensible extensible markup language, is expected to undergo widespread early adoption by pr0n sites, as it permits a hitherto unimaginable flexibility in permutations and combinations of content...
I went to school in the UK. I even had (well, my Dad had) an Acorn Risc PC at home. My nostalgia for it has dribbled away over the years, but it was a genuinely exciting piece of kit at the time - I even did some ARM Assembler coding on it, which was an education in itself.
Castle ripping off Linux, if true, is both sad and - I hope, not being a lawyer - actionable. They should be forced to come clean about it, forced to make suitable reparations, and prevented from doing anything of the sort again.
The saddest thing is that if done legitimately, the incorporation of Linux source code into an alternative OS would be a further vindication of the free software credo - proof that keeping software free promotes innovation, diversity and a healthy commons. I guess that the main problem in this instance is the proprietory nature of parts of RISC OS, which would have prevented such a legitimate use of GPL'd code; otherwise, there'd be no incentive to steal.
If RISC OS itself were free software, it might have evolved to a far greater degree following Acorn's abandonment of the platform. There were enough enthusiasts around for this to happen, including some very gifted coders (I'm thinking especially of the guy who coded a Quake engine for the platform - forget his name). Instead the OS has fallen into stagnation, irrelevancy and - it would seem - the use of unscrupulous practices by some of its last surviving advocates. This is a dismal shame.
Put me disturbingly in mind of:
- gurgled by deranged Sam Neill scientist character in gothic-shockfest-in-space Event Horizon...
Five years ago I was at a friend's house and his friend brought over an ancient C64 and a box full of tapes, and we plugged everything into everything else and tried to load up "Monty on the Run" (which has some of the best music of any game ever) and it worked and this was very cool and impressive and made us think for a moment about the simple pleasures (and general unbearable tedium, as we waited for the thing to load) of our mis-spent youth. We then unplugged everything and put it back into the box and got on with our lives. If, in five years time, someone comes over to my house with a still-working C64 and we can do the same thing all over again, that will be great. Meanwhile, I can't honestly say that I give that much of a monkey's.
I love the fact that there is always more to learn. In the past year I've learnt more than at the start of the year I even imagined there was to learn. If this coming year is likely to be the same, then welcome to it.
The one feeling I've had all the time during my short (two year) career so far as a programmer is a feeling of profound dissatisfaction with the way I'm doing whatever I'm doing at the moment. How can a year of being dissatisfied be a fulfilling one? The answer is that next time around, next spin of the wheel, I know I will try to do it better, and I am already beginning to learn what "better" means.
Right now I'm building a business objects layer for a client-server application, and confronting for the first time in practice the issues involved in mapping an "object model" made up of classes and contracts to a relational database. It's a fascinating and difficult area - grandiose schemas like EJB attest to the complexity of the problem domain. What I build today has to work reliably and hang together sensibly, and if it does that then everyone I work with and for will be satisfied. But the process of learning how to do it will affect the way I tackle the next problem, and the one after.
I believe that learning to be a good programmer means having this dual perspective: doing what you have to do today, as best you can, so that you deliver what your bosses are paying you to deliver, and at the same time seeing it as a stepping stone, something where just dumbly applying what you know already will result not only in inferior code but also in inferior understanding.
"Good social skills" is a bit broad. I know some fairly brilliant people whose social style is unconventional, and rubs some people up the wrong way. They don't have what you would call good social skills, in the sense of being able to make just anybody feel at ease with them on first acquaintance. They take some getting to know. And once you get to know them, they're great: great to work with, often hilariously funny, and still just as brilliant.
Think of it this way (for a moment, if you will...). Good teamwork requires trust. People with good social skills build up a superficial level of trust quickly, and deeper levels of trust over time. Good people with less good social skills are not as adept at building up that superficial level of trust, but once a trust-relationship has been established will often tend to be extremely loyal and "other-orientated". It often turns out with very brilliant and somewhat idiosyncratic individuals that they have a few absolutely sustaining relationships with a few very trusted other people.
In the right circumstances, these people are dynamite: and a lot of them go into the sciences looking for that kind of social dynamic (as well as truth, intellectual adventure and the advancement of human knowledge, of course). If "good social skills" are a prerequisite for advancement everywhere and all the time, then these people are going to find it almost impossibly hard to make an entry. That's actually what a lot of them are afraid of.
Prima donnas are another matter, and I've met one or two of those as well; but those are people with positively malignant social skills, rather than people who are simply awkward or retiring. You don't want those people anywhere near your team because they will drive everyone else crazy; and in that case, I agree with the above poster, it really doesn't matter how brilliant they are.
Agreed; I found it useful as a Java newbie, because it gave me a view of the language "from the other side", a sense of where its complexities lay. It is a fine example of how to think about design issues in the context of a set of linguistic constraints, and for this reason has something of value even for non-Java coders (as the Scott Meyers series has much of value for non-C++ coders).
Try also HaXml, Haskell's answer to the same question. David Mertz has an article on it here.
Funnily enough, I always find math a whole lot easier to understand myself once I've explained it to a computer.
I find it a lot harder to hold a mathematical idea in my head without some sort of procedural definition of what's going on, step by step, to link it to.
My computing hobby over the past twenty years has probably been the sole factor preventing what little mathematical literacy I gained at school from decaying completely...
Correction: C and C++ compiled with a compiler targetted at the same architecture compile to the same machine code.
Then again, it's surely not impossible to come up with a C# compiler that compiles to something other than MS IL - Java bytecodes, for instance, or native machine code...
Quoth AC, above:
The answer, I think, is that that's not the only difference. C and C++ compile to the same assembly language, but are sufficiently different for there to be good reasons for wanting to code in the one rather than the other. I believe Perl's new VM, "Parrot", is intended to support bytecodes from other languages besides Perl.
Microsoft's IL is not 100% generic - it's reputedly difficult to compile a language like Python to it sensibly, for reasons largely to do with typing if I understand aright - but it's generic enough to support multiple programming idioms that are different enough for programmers to have reasons to choose one over another, and those reasons will be the usual ones to do with familiarity, expressiveness, appropriateness to the problem domain, corporate politics and blind zealotry.
For my purposes, as a coder already locked into the MS world in my day job, MS's redesign of their fundamental API for Windows programming is the strongest "draw" in .NET; that and the XML/SOAP support, which is integrated into the .NET languages and tools to an extent that is unprecedented in the MS world, and probably elsewhere too. Maybe JAXP comes close: I wouldn't know.
It looks to me as if .NET comprises some of the best development work MS has done for ages - certainly some of the most ambitious. That doesn't mean it will, or should, rock your world if your world revolves around Java, or Perl, or Common Lisp or whatever. But for those of us who are already in that dismal place known as MS platform lock-in, it's a ray of light to say the least.
I want a better Zope very much, having toyed with Zope 2 and found it a bit of an uncomfortable fit. As a developer, I'd like to try Zope for applications above all, but I also want to be able to handle the "content" side of things with a minimum of fuss, so more orthogonality with regard to logic and presentation is a Good Thing for my purposes.
One thing I think Zope could really use is some pattern-based documentation, a wide-angle-lens overview with an emphasis on architectural idioms and good practice. The material available at the moment is by no means poor, but it leans towards the How-To rather than the Why-, When- or Whether-To. This is a fairly unavoidable characteristic of a software project in development, unless it's driven from the outset by a powerfully articulated vision, but as it comes out of the other end of a major refactoring Zope must by now have a whole load of users, developers and advocates with a pretty clear idea of what the Zope Thing is all about, and it's this that needs to be communicated to those of us who've tinkered a bit but not really managed to see how it all fits together.