Just goes to show that every algorithm, or theorem, or idea, was more influenced than influential. For Shannon I'd be tempted to create another honor for maximum influence per pages of manuscript. He had a profoundly useful idea and explained it as simply and clearly as possible.
Re:Sun may or may not get it
on
JavaOne report
·
· Score: 1
Good discussion. Some final points.
I don't use IBM's implementation because they never released a version of 1.2, not even on AIX. 1.2 was a huge step forward, not simply "moving the goalposts" or "bloat." (Sun did make Swing and the new Collections available as jars for those stuck on 1.1.)
I can't imagine using Microsoft's non-Java with compiled comment statements (shudder) that link unportable COM function pointers. MS supported 1.1 only after a court order, and will never support 1.2. In what way is J-- better than the JDK? Semantic's JIT is faster, so it can't be "performance."
I develop for five different OS's. I would like to have an alternative to Sun's JDK for 1.2, but nothing else comes close. So I use it on their terms. If the terms become onerous, then I'll go back to someone else's partial implementation of 1.1. I expect Sun to understand this. Sun has no monopoly on hardware or software that can force me to use their version of Java. The language specification and API cannot be made un-free. Anyone with the time and talent can reimplement it and improve on it. Sun threw some brilliant designers and a LOT of time at their version. So I accept their gift with gratitude. If they wanted money, I would pay for the privilege of using the JDK.
Sorry, I can't see the equivalence of Python with Java, but rather an excellent complement. I find JPython a wonderful way to script Java, for gluing together larger components, for on-site end-user customization, for an embedded command language, and for test code. (Like VBScript done right, with an actual grammar.) It's fine for smaller programs, but not for 100's of thousands of lines of code.
What about good old Huffman coding? Seems like all compression algorithms came from that first insight. Even better, it perfectly illustrates the entropy measure of information.
Re:Sun may or may not get it
on
JavaOne report
·
· Score: 1
You may not be grateful to Sun for designing Java, but I am. You say "We could have have done that quite well by ourselves, thank you." Are you serious? How many more brilliant languages are you planning to design and implement? I will become your biggest fan.
I can't imagine working on large distributed programs without Java. Nothing about it seems inevitable. In fact it seems downright inspired. Java, as currently available, makes my life as a programmer much easier than if I chose to do without it. So I use it. In spite of being one of Richard Stallman's biggest fans.
If you can reimplement Sun's JDK on your own, as you claim, then I would be truly grateful to you as well. Many organizations have tried, but Sun's JDK still seems to work better than the alternatives. It really is a lot of work. In the meantime, I am grateful to Sun for the productivity they have already given me. And I hope that my interests and Sun's will continue to coincide. But I do not feel than I am in a position to demand anything from them. What have I done for Sun lately? Nothing.
The licenses are clear. If I don't want the code under those terms, then I don't use it. I would like to use Jini for example, but I don't like the license. So I don't use it. I don't resent Sun for not giving Jini to me, just because I want it. I'm no worse off than I was before.
And I don't work on their source code because of the SCSL. That was their choice and mine. Nevertheless, it is THEIR CODE, and they can delete every last byte if they want.
Personally, I wouldn't give my code to the ISO either. Ever wonder why you can't download a copy of the final ISO C++ specification off the web?
Re:Sun still doesn't get it
on
JavaOne report
·
· Score: 2
Poor psychology. You aren't going to persuade Sun to make you a gift when you clearly will show no gratitude anyway. You evidently feel entitled to their code, and you're not. As Larry Wall said, those of leasurely moral development often confuse giving with taking. Since giving is good, some think taking must also be good. Are you grateful even to the FSF? Or did they only do their duty by giving you what you feel entitled to?
Re:ol gray slashdot... aint' what it used to be.
on
Is Pinball Dying?
·
· Score: 1
We all turn into old farts sooner than expected. Before we know it, our youth is out of fashion. Takes just a few years actually.
I particularly enjoyed the odd-numbered chapters of the paper copy of "Open Source Development with CVS," by Karl Fogel, from Coriolis OpenPress. These bonus chapters give an excellent feel for those devilish details that make an open-source project succeed or fail.
Dear "Director of Strategic Business Development,"
You might find a lighter tone more effective. So far I've read five comments by you, and all were laced with flame. Even though I saw no reason to disagree with your comments, your tone made me dislike you immediately. Show your responses to your "Director of Public Relations" and ask for advice next time.
I've heard that certain environments allow you to execute imported code in a "sandbox," with configurable access to the host's system. The default security policy does not allow new remote connections or touching the file system.
Actually, a "white" random process (a series of random variables) is defined as being "uncorrelated" to some order, usually second-order. If samples are non-Gaussian, then they can be "white" but still be statistically dependent. Compression would still be possible.
This is a great way to promote on-line sales for the holidays. You can't buy publicity like this. (Or maybe you can.)
The first comment attached to the article suggested that on-line browsing could actually boost sales in stores. Web pages could serve the purpose of a Sunday paper supplement. See the pictures and descriptions first, then go buy the thing that you can touch. (So should papers should ban URLs in paper ads?)
For learning Swing, I preferred "Core Java Foundation Classes" by Kim Topley, from Prentice Hall. It explains well the underlying design shared by all GUI elements. The Swing thread and synchronization finally make sense. It has the best single explanation of GridBagLayout that I've seen. No space is wasted merely listing javadoc information. Instead you learn how to make it all work together, in good style.
Most implementors of web sites using Java would use the Java on the backend where a database lives. Only the server needs to understand Java, not the client browser. I daresay that browser applet code is less than a percent of all existing Java code.
Ever been asked in the hallway for a "rough estimate" of how long it might take you to finish a particular bit of software? (Other phrases might be "wild guess" or "pull a number out of your...") Did you throw out a certain number of weeks or months? Did this number later appear on multiple versions of a development schedule? Were you later accused of missing a deadline because "you said you could do it in three weeks?" This is an example not of schedule negotiation, but of an ambush.
So that I can save time on long explanations in the hallway, here are some issues that must be discussed first.
According to Steve McConnel in "Rapid Development" and cited studies, your estimate of the product schedule is accurate within only a factor of four, AFTER you have an approved product definition. You drop to a factor of 1.5 only after you have a product design specification that details the implementation. In the hallway your estimate is worse. You aren't sure what you're being asked to build, and you don't know yet how you're going to build it.
Why do developers always underestimate development time? Because we are being asked to estimate the effort for one specific feature at a time. But features do not live in isolation. Features work together in a framework with many assumptions about what constitutes reasonable behavior. If you naively try to implement only features that are listed on paper, you will later hear questions like "Doesn't it dynamically update and save the results? Why can't I use this data in the other dialog? Of course that's required! Otherwise, what good is it?" We may be accurately estimating times for anticipated features, but we do not attempt to quantify times for unknown or implied features. Nor do we allow time to correct our original design. As soon as a feature is implemented, we realize the first specification was ambiguous and meant something different to everyone.
In short, the interaction between features increases your effort non-linearly as the number of features increases. Five interdependent features may need to be counted as fifteen new features, with extra work for each new interaction.
So let's assume we've figured out how to give a reasonable range of delivery times after having a product definition approved. We visualize all the known features. We try to quantify the magnitude of the implied features. We estimate a range of delivery dates within a factor of four, like 3-12 weeks or 2-8 months. We can't be more accurate at this point in our project without violating causality and other physical laws. We can imagine making the low estimate maybe 10% of the time. We can imagine making the high estimate 90% of the time. We're still in trouble.
According to "Death March" by Edward Yourdon, a typical software project now begins with a hard deadline and big expectations of what it can do. The deadline is the least flexible parameter. What about other parameters of features, staffing, and quality?
During early negotiations (and yes they are negotiations), your customers, management, and marketing are going to play hard-ball when it comes to features. Your product must do everything. No, they can't rank the features because they are all essential. So you put this parameter aside for the moment.
There might be some flexibility on the staffing. The company might be willing to throw money at your product manager. According to Yourdon, staffing follows some kind of inverse-square law. If you halve the amount of time for a project, you need to quadruple the number of programmers. The bigger the team, the longer it will take for them to work together well. Increasing staff shows diminishing returns. You can only add the developers early. According to "The Mythical Man Month" by Frederick Brooks, adding developers to a late project will delay the project further. Staffing is not easy to adjust, and staffing always has an upper limit.
Software quality, maintainability, robustness, stability, and usability, also can be degraded to improve your schedule -- to a point. If you overshoot your tolerance for poor software, you will also take too long to test and stabilize your product. Feature upgrades can be fatal. Better not push this parameter too far.
You can delude yourself. You can pretend that some magic silver-bullet technology will make you vastly more productive. You can pretend that your team walks on water, that 18-hour days can be sustained for months without burnout, that the project will never change scope again. But let's assume you're not on drugs.
You have the classic inflexibility matrix. The few parameters you can adjust, staffing and quality, are also the riskiest. Given all your hard constraints, you may find that the outer bound of your estimate well exceeds the acceptable delivery date of the project. What can you do? You can try to refuse the assignment, but you probably missed that opportunity. The rules changed when you were not paying attention.
Yourdon recommends triage of features, against the wishes of your sponsors. Divide features into "must have," "should have," and "could have." Don't let too much fall into the "must" category. If your users and managers wanted everything in the "must" category, then it's their lost opportunity. You'll have to prioritize for them. Give unequal scores to these features, such as 9 points for "must," 3 for "should," and 1 for "could."
Try to identify components that allow you to implement these features. Components should be parts of development that can proceed independently. The more you sub-divide your components, the better you can scale your productivity with more developers. Set the score of a component to the sum of scores of features it supports. Try to appraise the difficulty of implementing and testing each component. Don't worry about high scores that are easy to implement, or low scores that are hard to implement. These are casualties that will survive or die on their own.
When you start coding, begin with high scoring components that are hard to implement. These components represent the riskiest part of your development. Reduce your biggest risks quickly, and guarantee the most useful features. The last few panic-stricken weeks should be for easier components, not the riskiest ones. When you inevitably run out of time, you still might have something you can ship. Don't leave too much wasted code behind.
Start coding while your sponsors are waiting to launch the project, preparing slides and strategic documents. According to Steve McConnell, this "fuzzy front end" wastes the greatest opportunity to improve the delivery date.
Of course you still need sensible development practices such as described in "Dynamics of Software Development" by Jim McCarthy. Nightly builds, source/configuration management, risk monitoring, and benchmarks are still important. You won't speed up your project by abandoning previous good practices.
In short, you probably can't negotiate your development schedule. But you can prepare your sponsors for reality. Don't make it easy for them to ignore realistic schedules. You must find flexibility somewhere, so prioritize features for them. Those who set your constraints will have to make hard decisions eventually. Most likely they'll prefer having fewer features rather than nothing. Or they'll decide extra features are worth a delay, after all.
I may have missed your point. You mean that XML should be looked at with tools that graphically display the hierarchy. I agree. But sometimes you'll need to look at the file as well. Would you build a web page without ever looking at the HTML? I hope not. And I would never design and use an XML data structure without looking, sooner or later, at the raw ascii file. The XML format makes this as readable as possible. Otherwise, why bother to make it ASCII in the first place? I personally love LISP. Programs have exactly the same format as data. You can't say that about dialects like Tcl. But the big drawback for LISP data structures is that they are hard to parse with the naked eye. If you only look at your data structures with interpretive graphical tools, then who cares what the persistent file looks like?
No I personally would use emacs with color highlighting. But sometimes, cat/more/less is enough. To look at deep nesting delimited by parentheses, you must trust the indentation scheme, or test every pair yourself. A closing XML tag is always immediately obvious. Readability often requires extra keystrokes. For example you can name a variable "tableRowIndex", which is tedious to type, or you can name it "i1", which is tedious to read.
I agree that XML datastructures could be filtered by a perl script into an equivalent LISP structures. In XML, however, you can see the equivalent of the closing parenthesis with your naked eye, without a browser designed specifically for LISP. Tcl is another dialect of LISP, but with brackets and braces and newlines to break the monotony.
LaTeX is really a typesetting language, not a word processor. It is still widely used for scientific papers because standard word processors have very poor support for equations. Equations need to be typed symbolically, with many macro definitions. A WYSIWYG system only sees equations as a collection of graphical elements. I use LaTeX all the time, even for overhead/slide shows. My ten-year old documents are still editable, and small.
I've given away dozens of programming books, but here is a list of books still on the shelf. Used bookstores are better off without a computer section.
You'd think that Numerical Recipes would be an ideal argument for giving away code and selling the documentation. That's the way it worked with the first edition. But someone must have convinced the authors to make the second edition more restrictive, to make money directly from the code. The subsection "License Information" in the section "Legal Matters" explains "We want to make it easy for you to use the programs in this book on your computer. But to do so legally, you will need a license." I found the details fascinating. The authors list six different ways to get the code. 1) Buy the book and you can make one copy of each program for personal and non-commercial use. 2) You can use the code on one machine for each diskette purchased directly from Cambridge University Press. 3) Commercial licenses are negotiated, with discounts for universities. 4) Licenses can be requested for incorporation into products, with some restrictions, at nominal cost. (Like ObjectSpace, they sell the privilege of looking at the code, not compiling it.) 5) An instructor can mail $5 per student per license, if the software is used in a course. 6) A one-time license can be obtained for $50 for use on a single workstation at a not-for-profit organization. Obsessively wrongheaded, isn't it?
Dover makes my favorite softcover bindings. Their books use sewn signatures and acid-free paper and still cost less than anything else on the shelf. They last forever. Okay, Dover must be a charitable organization supported by a shy philanthropist. But I do wonder why more publishers aren't tempted to make their works equally immortal.
Slashdot Mirror
Just goes to show that every algorithm, or theorem, or idea, was more influenced than influential. For Shannon I'd be tempted to create another honor for maximum influence per pages of manuscript. He had a profoundly useful idea and explained it as simply and clearly as possible.
I don't use IBM's implementation because they never released a version of 1.2, not even on AIX. 1.2 was a huge step forward, not simply "moving the goalposts" or "bloat." (Sun did make Swing and the new Collections available as jars for those stuck on 1.1.)
I can't imagine using Microsoft's non-Java with compiled comment statements (shudder) that link unportable COM function pointers. MS supported 1.1 only after a court order, and will never support 1.2. In what way is J-- better than the JDK? Semantic's JIT is faster, so it can't be "performance."
I develop for five different OS's. I would like to have an alternative to Sun's JDK for 1.2, but nothing else comes close. So I use it on their terms. If the terms become onerous, then I'll go back to someone else's partial implementation of 1.1. I expect Sun to understand this. Sun has no monopoly on hardware or software that can force me to use their version of Java. The language specification and API cannot be made un-free. Anyone with the time and talent can reimplement it and improve on it. Sun threw some brilliant designers and a LOT of time at their version. So I accept their gift with gratitude. If they wanted money, I would pay for the privilege of using the JDK.
Sorry, I can't see the equivalence of Python with Java, but rather an excellent complement. I find JPython a wonderful way to script Java, for gluing together larger components, for on-site end-user customization, for an embedded command language, and for test code. (Like VBScript done right, with an actual grammar.) It's fine for smaller programs, but not for 100's of thousands of lines of code.
What about good old Huffman coding? Seems like all compression algorithms came from that first insight. Even better, it perfectly illustrates the entropy measure of information.
I can't imagine working on large distributed programs without Java. Nothing about it seems inevitable. In fact it seems downright inspired. Java, as currently available, makes my life as a programmer much easier than if I chose to do without it. So I use it. In spite of being one of Richard Stallman's biggest fans.
If you can reimplement Sun's JDK on your own, as you claim, then I would be truly grateful to you as well. Many organizations have tried, but Sun's JDK still seems to work better than the alternatives. It really is a lot of work. In the meantime, I am grateful to Sun for the productivity they have already given me. And I hope that my interests and Sun's will continue to coincide. But I do not feel than I am in a position to demand anything from them. What have I done for Sun lately? Nothing.
The licenses are clear. If I don't want the code under those terms, then I don't use it. I would like to use Jini for example, but I don't like the license. So I don't use it. I don't resent Sun for not giving Jini to me, just because I want it. I'm no worse off than I was before.
And I don't work on their source code because of the SCSL. That was their choice and mine. Nevertheless, it is THEIR CODE, and they can delete every last byte if they want.
Personally, I wouldn't give my code to the ISO either. Ever wonder why you can't download a copy of the final ISO C++ specification off the web?
Poor psychology. You aren't going to persuade Sun to make you a gift when you clearly will show no gratitude anyway. You evidently feel entitled to their code, and you're not. As Larry Wall said, those of leasurely moral development often confuse giving with taking. Since giving is good, some think taking must also be good. Are you grateful even to the FSF? Or did they only do their duty by giving you what you feel entitled to?
We all turn into old farts sooner than expected. Before we know it, our youth is out of fashion. Takes just a few years actually.
I read slashdot for information AND entertainment. Without both, I would not be in the mood half the time.
I don't plan to see the movie, but a truly horrible movie is fun to ridicule. That's why we like MST3000.
I'm reading the comments of this article for entertaining sarcasm. Let's have some already!
I particularly enjoyed the odd-numbered chapters of the paper copy of "Open Source Development with CVS," by Karl Fogel, from Coriolis OpenPress. These bonus chapters give an excellent feel for those devilish details that make an open-source project succeed or fail.
Dear "Director of Strategic Business Development,"
You might find a lighter tone more effective. So far I've read five comments by you, and all were laced with flame. Even though I saw no reason to disagree with your comments, your tone made me dislike you immediately. Show your responses to your "Director of Public Relations" and ask for advice next time.
I understand that unicode cannot be properly supported without breaking some existing code.
1. Enforce indentation rules to make code readable.
2. Braces are now redundant, so get rid of them.
Permissions are like everything else
in Windows -- all or nothing. NT will
drive you crazy unless you run as an
Administrator all the time.
I've heard that certain environments allow
you to execute imported code in a "sandbox,"
with configurable access to the host's system.
The default security policy does not
allow new remote connections or touching
the file system.
Oh, I remember. It's called a Java applet.
Actually, a "white" random process (a series of random variables) is defined as being "uncorrelated" to some order, usually second-order. If samples are non-Gaussian, then they can be "white" but still be statistically dependent. Compression would still be possible.
This is a great way to promote on-line sales for the holidays. You can't buy publicity like this. (Or maybe you can.)
The first comment attached to the article suggested that on-line browsing could actually boost sales in stores. Web pages could serve the purpose of a Sunday paper supplement. See the pictures and descriptions first, then go buy the thing that you can touch. (So should papers should ban URLs in paper ads?)
For learning Swing, I preferred "Core Java Foundation Classes" by Kim Topley, from Prentice Hall. It explains well the underlying design shared by all GUI elements. The Swing thread and synchronization finally make sense. It has the best single explanation of GridBagLayout that I've seen. No space is wasted merely listing javadoc information. Instead you learn how to make it all work together, in good style.
Most implementors of web sites using Java would use the Java on the backend where a database lives. Only the server needs to understand Java, not the client browser. I daresay that browser applet code is less than a percent of all existing Java code.
Ever been asked in the hallway for a "rough estimate" of how long it might take you to finish a particular bit of software? (Other phrases might be "wild guess" or "pull a number out of your ...") Did you throw out a certain number of weeks or months? Did this number later appear on multiple versions of a development schedule? Were you later accused of missing a deadline because "you said you could do it in three weeks?" This is an example not of schedule negotiation, but of an ambush.
So that I can save time on long explanations in the hallway, here are some issues that must be discussed first.
According to Steve McConnel in "Rapid Development" and cited studies, your estimate of the product schedule is accurate within only a factor of four, AFTER you have an approved product definition. You drop to a factor of 1.5 only after you have a product design specification that details the implementation. In the hallway your estimate is worse. You aren't sure what you're being asked to build, and you don't know yet how you're going to build it.
Why do developers always underestimate development time? Because we are being asked to estimate the effort for one specific feature at a time. But features do not live in isolation. Features work together in a framework with many assumptions about what constitutes reasonable behavior. If you naively try to implement only features that are listed on paper, you will later hear questions like "Doesn't it dynamically update and save the results? Why can't I use this data in the other dialog? Of course that's required! Otherwise, what good is it?" We may be accurately estimating times for anticipated features, but we do not attempt to quantify times for unknown or implied features. Nor do we allow time to correct our original design. As soon as a feature is implemented, we realize the first specification was ambiguous and meant something different to everyone.
In short, the interaction between features increases your effort non-linearly as the number of features increases. Five interdependent features may need to be counted as fifteen new features, with extra work for each new interaction.
So let's assume we've figured out how to give a reasonable range of delivery times after having a product definition approved. We visualize all the known features. We try to quantify the magnitude of the implied features. We estimate a range of delivery dates within a factor of four, like 3-12 weeks or 2-8 months. We can't be more accurate at this point in our project without violating causality and other physical laws. We can imagine making the low estimate maybe 10% of the time. We can imagine making the high estimate 90% of the time. We're still in trouble.
According to "Death March" by Edward Yourdon, a typical software project now begins with a hard deadline and big expectations of what it can do. The deadline is the least flexible parameter. What about other parameters of features, staffing, and quality?
During early negotiations (and yes they are negotiations), your customers, management, and marketing are going to play hard-ball when it comes to features. Your product must do everything. No, they can't rank the features because they are all essential. So you put this parameter aside for the moment.
There might be some flexibility on the staffing. The company might be willing to throw money at your product manager. According to Yourdon, staffing follows some kind of inverse-square law. If you halve the amount of time for a project, you need to quadruple the number of programmers. The bigger the team, the longer it will take for them to work together well. Increasing staff shows diminishing returns. You can only add the developers early. According to "The Mythical Man Month" by Frederick Brooks, adding developers to a late project will delay the project further. Staffing is not easy to adjust, and staffing always has an upper limit.
Software quality, maintainability, robustness, stability, and usability, also can be degraded to improve your schedule -- to a point. If you overshoot your tolerance for poor software, you will also take too long to test and stabilize your product. Feature upgrades can be fatal. Better not push this parameter too far.
You can delude yourself. You can pretend that some magic silver-bullet technology will make you vastly more productive. You can pretend that your team walks on water, that 18-hour days can be sustained for months without burnout, that the project will never change scope again. But let's assume you're not on drugs.
You have the classic inflexibility matrix. The few parameters you can adjust, staffing and quality, are also the riskiest. Given all your hard constraints, you may find that the outer bound of your estimate well exceeds the acceptable delivery date of the project. What can you do? You can try to refuse the assignment, but you probably missed that opportunity. The rules changed when you were not paying attention.
Yourdon recommends triage of features, against the wishes of your sponsors. Divide features into "must have," "should have," and "could have." Don't let too much fall into the "must" category. If your users and managers wanted everything in the "must" category, then it's their lost opportunity. You'll have to prioritize for them. Give unequal scores to these features, such as 9 points for "must," 3 for "should," and 1 for "could."
Try to identify components that allow you to implement these features. Components should be parts of development that can proceed independently. The more you sub-divide your components, the better you can scale your productivity with more developers. Set the score of a component to the sum of scores of features it supports. Try to appraise the difficulty of implementing and testing each component. Don't worry about high scores that are easy to implement, or low scores that are hard to implement. These are casualties that will survive or die on their own.
When you start coding, begin with high scoring components that are hard to implement. These components represent the riskiest part of your development. Reduce your biggest risks quickly, and guarantee the most useful features. The last few panic-stricken weeks should be for easier components, not the riskiest ones. When you inevitably run out of time, you still might have something you can ship. Don't leave too much wasted code behind.
Start coding while your sponsors are waiting to launch the project, preparing slides and strategic documents. According to Steve McConnell, this "fuzzy front end" wastes the greatest opportunity to improve the delivery date.
Of course you still need sensible development practices such as described in "Dynamics of Software Development" by Jim McCarthy. Nightly builds, source/configuration management, risk monitoring, and benchmarks are still important. You won't speed up your project by abandoning previous good practices.
In short, you probably can't negotiate your development schedule. But you can prepare your sponsors for reality. Don't make it easy for them to ignore realistic schedules. You must find flexibility somewhere, so prioritize features for them. Those who set your constraints will have to make hard decisions eventually. Most likely they'll prefer having fewer features rather than nothing. Or they'll decide extra features are worth a delay, after all.
I may have missed your point. You mean that XML should be looked at with tools that graphically display the hierarchy. I agree. But sometimes you'll need to look at the file as well. Would you build a web page without ever looking at the HTML? I hope not. And I would never design and use an XML data structure without looking, sooner or later, at the raw ascii file. The XML format makes this as readable as possible. Otherwise, why bother to make it ASCII in the first place?
I personally love LISP. Programs have exactly the same format as data. You can't say that about dialects like Tcl. But the big drawback for LISP data structures is that they are hard to parse with the naked eye. If you only look at your data structures with interpretive graphical tools, then who cares what the persistent file looks like?
No I personally would use emacs with color highlighting. But sometimes, cat/more/less is enough. To look at deep nesting delimited by parentheses, you must trust the indentation scheme, or test every pair yourself. A closing XML tag is always immediately obvious. Readability often requires extra keystrokes. For example you can name a variable "tableRowIndex", which is tedious to type, or you can name it "i1", which is tedious to read.
I agree that XML datastructures could be filtered by a perl script into an equivalent LISP structures. In XML, however, you can see the equivalent of the closing parenthesis with your naked eye, without a browser designed specifically for LISP. Tcl is another dialect of LISP, but with brackets and braces and newlines to break the monotony.
LaTeX is really a typesetting language, not a word processor. It is still widely used for scientific papers because standard word processors have very poor support for equations. Equations need to be typed symbolically, with many macro definitions. A WYSIWYG system only sees equations as a collection of graphical elements. I use LaTeX all the time, even for overhead/slide shows. My ten-year old documents are still editable, and small.
I've given away dozens of programming books, but here is a list of books still on the shelf. Used bookstores are better off without a computer section.
You'd think that Numerical Recipes would be an ideal argument for giving away code and selling the documentation. That's the way it worked with the first edition. But someone must have convinced the authors to make the second edition more restrictive, to make money directly from the code. The subsection "License Information" in the section "Legal Matters" explains "We want to make it easy for you to use the programs in this book on your computer. But to do so legally, you will need a license." I found the details fascinating. The authors list six different ways to get the code. 1) Buy the book and you can make one copy of each program for personal and non-commercial use. 2) You can use the code on one machine for each diskette purchased directly from Cambridge University Press. 3) Commercial licenses are negotiated, with discounts for universities. 4) Licenses can be requested for incorporation into products, with some restrictions, at nominal cost. (Like ObjectSpace, they sell the privilege of looking at the code, not compiling it.) 5) An instructor can mail $5 per student per license, if the software is used in a course. 6) A one-time license can be obtained for $50 for use on a single workstation at a not-for-profit organization. Obsessively wrongheaded, isn't it?
Dover makes my favorite softcover bindings. Their books use sewn signatures and acid-free paper and still cost less than anything else on the shelf. They last forever. Okay, Dover must be a charitable organization supported by a shy philanthropist. But I do wonder why more publishers aren't tempted to make their works equally immortal.