Re:What's this "DynamicProxy" class?
on
Hardcore Java
·
· Score: 1
Thanks for the erratum. I had just been working with the mockobjects framework and I was thinking of their DynamicProxy mechanism. I should have followed my own advice and had someone give the article a tech edit.:)
I think this is an insightful comment. I don't have TiVo, so I can't claim the same view, but I think your experience is interesting and I'm glad you shared it.
SXML & SXLT. It's Scheme with XML. True, it's not procedural, but it's a programming language. Oleg Kiselov wrote it.
http://okmij.org/ftp/Scheme/SXML.html
It doesn't just use constraints. It's simply possible to constrain variables over values. However, you don't need to specify a constraining range. The thing that lots of people find strange about variables in Oz is that they are single assignment. Once you've assigned to a variable, it's an error to attempt to reassign it. It's not such a big deal if you're used to working with functional (Lisp, Haskell) or logic languages (Prolog, Godel) but it takes some getting used to if you're from the side-effect side of the street.
The other strange thing is the representation of strings as lists of characters. Weird.
One of the cool things about Oz is that you can solve the eight queens problem in a declarative fashion in about a dozen lines of code. You simply specify the constraints and let Oz figure it out.
TED: This is what it's all about, a fine port, beautiful surroundings and intelligent company! OLDER PRIEST: Did you not have all that at your last parish? TED: (bitterly) No. OLDER PRIEST: Dublin seems to suit you though, you've got a new-found gleam in your eye. TED: Ah yes! I shall be staying here for a good while. As long as I don't mess it up for myself by doing something stupid. PARISH ACCOUNTANT: Most of these accountants seem in order Father Smith. But I wonder could I ask Father Crilly about one or two of these things that he's put down under expenses.
I agree about the predicate function, but I understood the intention being whatever was passed in, the symbol scheme was returned. Which I then interpreted as meaning that scheme is the primordial language and every language is scheme under the covers. And then I thought that it's probably more accurate to say that Scheme is like Zelazny's Amber and that all the other programming languages are just shadows that differ in some flawed way. (C being somewhere down by the Courts of Chaos). And then I realised that I was out of new Mountain Dew LiveWire(tm) and should get my fifth bottle of the day. Oh, sweet nectar!
There are a fair number of posts talking about how XP is a methodology or a workflow, and not actually a programming paradigm. To a large degree I agree with these posters, and it could very well be the case that it was the intent of the writer of the article to present XP as such. However, there are aspects of XP that are nearly "paradigmatic".
XP is heavily influenced by TDD -- Test Driven Development. The idea is that you only write code when you have a failing test. You write the test, it fails, you write the code to make the test pass. Then you go back to the requirements, write another test specified by the requirements, run it, it fails, so you write the code to fix it. Repeat until all tests (unit and functional) pass. When all your functional tests pass, you've met the requirements for the app (because the functional tests represent the use cases) and you're done.
Coding in this fashion does two things. It ensures that you've got a safety net at all times, and it forces your code to be loosely coupled and modular. Because you have 100% coverage, you're not afraid to change the code, because if you break something, you'll get a failing test. If you make a change and all your tests pass, you have the confidence that you didn't inadvertently break something in your code.
Additionally, your code needs to be modular and loosely coupled because it's tough to test if it isn't. If you have a God Class with lots of dependencies, you won't be able to unit test it because of all the dependencies. That's to say, you won't be able to test it as a unit. If you have a method that's doing lots of things, you'll have to write lots of tests to verify every path of execution. So instead, you're strongly encouraged to write simple methods that do one thing well for ease of testing.
A real OO guru knows all sorts of things about coupling and cohesion and patterns and when to use composition and when to use inheritance. They always obey the Law of Demeter and consistently separate the implementation from the interface. And to be able to do this, they've got a dog's life of OO experience under their belt. Here's the kicker. The XP evangelists say that using XP and TDD, in particular, gives you the benefits of all this experience as an emergent property of the methodology.
You obey the Law of Demeter because testing a class that breaks it isn't a unit test -- it's a subsystem test. You use interfaces because it allows you to substitute mock objects for the objects that your object under test interacts with. You use composition and inheritance appropriately because your tests will fail if you don't. Oh, and by the way, if you start with inheritance and move to composition, it's not a problem because all your tests will insure you don't leave something broken.
The point is that a programmer really only needs to learn how to write good tests in order to be a good programmer. TDD gives you all the stuff that you would normally have to have gained through experience.
So, that's why I think it's similar to AOP. They both produce higher quality and more maintainable software. However, TDD is a social solution, while AOP is a technical one. And, as long as I'm on my soapbox, I'll just mention that many patterns are compensations for things that more powerful languages do easily. For example, lisp's map procedure is an example of Visitor. Generally, languages that support higher order functions, or that treat functions as first class types, don't require as much pattern silly-walking. Also, AOP is old. Lisp has had it for a long time. In fact, the main architect of AspectJ, Gregor Kiczales, worked on the Common Lisp Object System (CLOS) with Richard Gabriel. Plus ca change, plus ca meme chose, innit. Here's a link to some thoughtful writings on the subject.
One other point -- for those inclined towards genetic programming. I think that the XP TDD way of programming suffers from the same problems as the hill climbing algorithm. It tends to produce quality, but I think it's easy to get stuck at a local minimum.
Gregor Kiczales, the lead on the AspectJ project, wrote "The Art of the Metaobject Protocol", which was a description of how to do metaobjects in Lisp (metaobjects, and particularly generic functions, are closely related to AOP). A description that Gabriel and Steele put together can be found in The Common Lisp Object System: An Overview
I just sent in a submission to Ask Slashdot a couple days ago asking what happened to Katz, but it was rejected. His last post was on April 23rd and his last article was posted on July 10th. Maybe this book review will bring him back from the dead.
Re:Guidelines for world building?
on
Ask Larry Niven
·
· Score: 1
I suggest that you find a copy of Murasaki. You can read the reviews & summary on Amazon, but I'll mention that it has an appendix that details the world creation process. It's a collaborative effort by leading SF authors including Pohl, Brin, Bedford, and Bear. All in all, an excellent read.
You might be thinking of the archaic use where it referred to a complete set, rather than just "alotta something", but that's no longer the standard use. Or maybe you just confused it with "panopeas", which, I agree, makes no sense in this context.
HACKMEM is a document from the Elder Days at the MIT AI lab. It's not about optimisation, like Hacker's Delight, but it's full of lots of cool math/comp sci tidbits. I first discovered it back in the 80s when I was a script kiddie looking for cracking info (I hadn't understood the distinction between hacking and cracking at the time) and discarded it as lame. I revisited it about five years later after spending some time in the CS department and realised what a gem it really is.
Here's a sample:
ITEM 63 (Schroeppel, etc.): The joys of 239 are as follows:
* pi = 16 arctan (1/5) - 4 arctan(1/239), * which is related to the fact that 2 * 13^4 - 1 = 239^2, * which is why 239/169 is an approximant (the 7th) of sqrt(2). * arctan(1/239) = arctan(1/70) - arctan(1/99) = arctan(1/408) + arctan(1/577) * 239 needs 4 squares (the maximum) to express it. * 239 needs 9 cubes (the maximum, shared only with 23) to express it. * 239 needs 19 fourth powers (the maximum) to express it. * (Although 239 doesn't need the maximum number of fifth powers.) * 1/239 =.00418410041841..., which is related to the fact that * 1,111,111 = 239 * 4,649. * The 239th Mersenne number, 2^239 - 1, is known composite, but no factors are known. * 239 = 11101111 base 2. * 239 = 22212 base 3. * 239 = 3233 base 4. * There are 239 primes < 1500. * K239 is Mozart's only work for 2 orchestras. * Guess what memo this is. * And 239 is prime, of course.
That's true. One of the factors why the ruby book sells in print, though, is because there's a lack of good Ruby books. However, let's say there was a better ruby book that wasn't available on the web. I'd bet that you would buy the better book, but still use the free version for your online needs -- grepping, cutting-n-pasting, etc. Given competition, the only way the free online version will sell print copies is if it's the best.
The reason it worked for Bruce Eckel is because he is an extremely talented writer/teacher who invests considerable time into his writing. He has chosen a career as a educational consultant and by ensuring that his books are the highest quality possible helps provide him with consulting gigs.
The thing about having a book available for free in addition to a dead-trees version is that it requires your book to be the best. If your book is merely useful, people will just download it. If you're going to sell it, you need to demonstrate utility far beyond what someone would get from simply downloading it.
You're ignoring the difference between technical books and recreational books.
Recreational books are cheap and pleasure-oriented. They're also end-to-end. With any one of the Baen books, you outlay about six bucks and you've got 15-30 hours of reading pleasure ahead of you. Generally speaking, the book isn't random-access. You need to read the whole thing to derive pleasure from it (or, at least, pleasure is maximised by reading the entire book in sequential order).
Technical books are expensive and solution-oriented and (generally) random-access. For example, maybe you work for a company that stores a bunch of information in a database that's shared across divisions. You're getting sick of being unable to make changes to the schema because everyone in the company is touching your data. You decide to wrap the whole thing up in a web service and allow people to access the database that way. So, you buy O'Reilly's web services book, learn a bit about SOAP, install Tomcat, and expose your data through a web services interface. Now, if the O'Reilly WS book were on line, you'd probably go in, look up the stuff you need, print out the appropriate pages, and write your interface. Once the job is done, you wouldn't go down to B&N and buy a copy of the book for your bookshelf.
So, what you're comparing is a cheap book that needs to be entirely consumed versus an expensive book that can be used in small portions. For that reason, I don't think that you can generalise and say that because sci-fi sells well even when available for free, then the same relationship holds for technical books.
Writing a book is not equivalent to dumping your brain. Writing a book requires the author to determine a vision for the book, identify an audience, determine what needs to go in the book in order to fulfill the vision and what needs to be left out so as not to obscure the vision, and how to present the material in a clear and coherent manner.
Writing a book is (in many ways) akin to developing a large software project. It requires the skill to work in the trenches as well as at 1E4 feet and still see how everything hangs together. The difference between developing software and writing a book is that in the latter case, everyone reads your source code. If you're writing a spreadsheet application and it passes all the unit and functional tests, it doesn't matter if it's pure spaghetti code (ignoring factors like maintainability, scalability, cost-of-ownership, etc.) The purpose of the app is number-crunching. The purpose of a book is to transmit information. However, the clarity of the "code" is integral to fulfilling this function. A book doesn't have unit tests and functional tests to validate its success. It only has usability tests.
My experience comes from both sides of the fence. I've been a software architect for a Fortune 500 corporation and I was the acquisitions editor (and part-time developmental editor) for a technical publishing company. As an acquisitions editor I realised pretty soon that a large percentage of technical people look at writing as a brain dump. These are people who would never dream of sitting down to code without, at the very least, sketching out some designs on an index card. But they feel perfectly comfortable sitting down to write chapter one with a blank page and no notes and expecting to finish 450 pages later. As you might expect, most of these books were either never completed or were unpublishable. (This is probably what you'd expect if a software project were managed the same way.)
My question for you, Bruce, is this -- what kind of editorial support will PH be offering? Is this just going to be documentation that is bound and offered for sale? Or will there be an editorial process that help prevent these books from being more than a brain dump (which, IMHO, is about as intelligible as a core dump).
It's actually called StarLogo because the original version was written in *Lisp (star-lisp) on massively parallel computer system. At some point Resnick ported it over to Java.
Incidentally, StarLogo has a resemblance to Logo, but it's primarily superficial. StarLogo is all about exploring emergent behaviours in decentralised systems. While you can do regular turtle graphics in StarLogo, if you do it, you're kind of missing the point.
StarLogo uses thousands of turtles, instead of just a couple. StarLogo also allows the turtles to interact with their environment by doing things like creating pheromone trails. This makes it easy to do things like build an ant colony and watch it explore for food and create trails to the food for other ants to follow.
Incidentally, the ant colony code only uses thirteen procedures, each one no more than five or six lines of code. Here's a sample:
to find-food-demon if (not carrying-food?) and ask patch-here [food > 0] [set-carrying-food? true ask patch-here [set-food food - 1] set-drop-size 35 right 180 forward 1] end
This defines the way an ant finds food. Essentially, if it's not carrying food it checks the ground to see if there's any food there (ask patch-here). If there is, it sets itself to carry it and reduces the amount of food on the ground by one unit. The line set-drop-size sets the initial magnitude of the pheremone drop. There's another demon (return-to-nest-demon) that takes over once the ant gets food. It's responsible for following the pheremone gradient back to the nest and to mark the trail to the food by decreasing the food pheremone with each step back to the nest. That way the food pheremone will be strongest near the food, causing the hungry ants to go in that direction.
One of the other interesting parts of the book, Turtles, Termites, and Traffic Jams is the author's descriptions of the kids that he works with. He takes StarLogo into grade schools and gives the kids problems (like the ant problem, or a traffic jam modeling problem) and watches them solve it. All in all, it's an excellent book and I highly recommend it.
Actually, it was completeness and consistency that Godel tackled, and he proved it (rather than implied it). Complete = all true statements have a proof. Consistent = p & ~p is not a theorem of the system. This is for all systems strong enough to support the Peano axioms (and some weaker systems, I believe). However, 1st order logic is both complete and consistent.
Is this the book you're referring to? If so, the author is Eric Temple Bell and it is a fabulous book. I didn't see any books on Amazon written by a Carl Brooks that dealt with math.
Slashdot Mirror
Thanks for the erratum. I had just been working with the mockobjects framework and I was thinking of their DynamicProxy mechanism. I should have followed my own advice and had someone give the article a tech edit. :)
Actually, what they do is use the same captcha on three people. If one of the three doesn't match up, instead of pr0n, they get the goatse.cx guy.
I imagine it's only a matter of time.
I think this is an insightful comment. I don't have TiVo, so I can't claim the same view, but I think your experience is interesting and I'm glad you shared it.
SXML & SXLT. It's Scheme with XML. True, it's not procedural, but it's a programming language. Oleg Kiselov wrote it. http://okmij.org/ftp/Scheme/SXML.html
On Lisp and ANSI Common Lisp are pretty advanced. I'd probably recommend the Winston and Horn book, instead.
One of the cool things about Oz is that you can solve the eight queens problem in a declarative fashion in about a dozen lines of code. You simply specify the constraints and let Oz figure it out.
Point well taken.
Jargon File entry: http://www.hack.gr/jargon/html/sections/a-portrait -of-j-random-hacker.html
I agree about the predicate function, but I understood the intention being whatever was passed in, the symbol scheme was returned. Which I then interpreted as meaning that scheme is the primordial language and every language is scheme under the covers. And then I thought that it's probably more accurate to say that Scheme is like Zelazny's Amber and that all the other programming languages are just shadows that differ in some flawed way. (C being somewhere down by the Courts of Chaos). And then I realised that I was out of new Mountain Dew LiveWire(tm) and should get my fifth bottle of the day. Oh, sweet nectar!
XP is heavily influenced by TDD -- Test Driven Development. The idea is that you only write code when you have a failing test. You write the test, it fails, you write the code to make the test pass. Then you go back to the requirements, write another test specified by the requirements, run it, it fails, so you write the code to fix it. Repeat until all tests (unit and functional) pass. When all your functional tests pass, you've met the requirements for the app (because the functional tests represent the use cases) and you're done.
Coding in this fashion does two things. It ensures that you've got a safety net at all times, and it forces your code to be loosely coupled and modular. Because you have 100% coverage, you're not afraid to change the code, because if you break something, you'll get a failing test. If you make a change and all your tests pass, you have the confidence that you didn't inadvertently break something in your code.
Additionally, your code needs to be modular and loosely coupled because it's tough to test if it isn't. If you have a God Class with lots of dependencies, you won't be able to unit test it because of all the dependencies. That's to say, you won't be able to test it as a unit. If you have a method that's doing lots of things, you'll have to write lots of tests to verify every path of execution. So instead, you're strongly encouraged to write simple methods that do one thing well for ease of testing.
A real OO guru knows all sorts of things about coupling and cohesion and patterns and when to use composition and when to use inheritance. They always obey the Law of Demeter and consistently separate the implementation from the interface. And to be able to do this, they've got a dog's life of OO experience under their belt. Here's the kicker. The XP evangelists say that using XP and TDD, in particular, gives you the benefits of all this experience as an emergent property of the methodology.
You obey the Law of Demeter because testing a class that breaks it isn't a unit test -- it's a subsystem test. You use interfaces because it allows you to substitute mock objects for the objects that your object under test interacts with. You use composition and inheritance appropriately because your tests will fail if you don't. Oh, and by the way, if you start with inheritance and move to composition, it's not a problem because all your tests will insure you don't leave something broken.
The point is that a programmer really only needs to learn how to write good tests in order to be a good programmer. TDD gives you all the stuff that you would normally have to have gained through experience.
So, that's why I think it's similar to AOP. They both produce higher quality and more maintainable software. However, TDD is a social solution, while AOP is a technical one. And, as long as I'm on my soapbox, I'll just mention that many patterns are compensations for things that more powerful languages do easily. For example, lisp's map procedure is an example of Visitor. Generally, languages that support higher order functions, or that treat functions as first class types, don't require as much pattern silly-walking. Also, AOP is old. Lisp has had it for a long time. In fact, the main architect of AspectJ, Gregor Kiczales, worked on the Common Lisp Object System (CLOS) with Richard Gabriel. Plus ca change, plus ca meme chose, innit. Here's a link to some thoughtful writings on the subject.
One other point -- for those inclined towards genetic programming. I think that the XP TDD way of programming suffers from the same problems as the hill climbing algorithm. It tends to produce quality, but I think it's easy to get stuck at a local minimum.
Gregor Kiczales, the lead on the AspectJ project, wrote "The Art of the Metaobject Protocol", which was a description of how to do metaobjects in Lisp (metaobjects, and particularly generic functions, are closely related to AOP). A description that Gabriel and Steele put together can be found in The Common Lisp Object System: An Overview
I just sent in a submission to Ask Slashdot a couple days ago asking what happened to Katz, but it was rejected. His last post was on April 23rd and his last article was posted on July 10th. Maybe this book review will bring him back from the dead.
I suggest that you find a copy of Murasaki. You can read the reviews & summary on Amazon, but I'll mention that it has an appendix that details the world creation process. It's a collaborative effort by leading SF authors including Pohl, Brin, Bedford, and Bear. All in all, an excellent read.
You might be thinking of the archaic use where it referred to a complete set, rather than just "alotta something", but that's no longer the standard use. Or maybe you just confused it with "panopeas", which, I agree, makes no sense in this context.
Judge: I'm sorry, Mr. Mouse, but the State of California doesn't grant divorce on grounds of insanity.
MM: I didn't say she was insane -- I said she was fucking Goofy! ha HA! (drumroll)
Here's a sample:
HACKMEMThat's true. One of the factors why the ruby book sells in print, though, is because there's a lack of good Ruby books. However, let's say there was a better ruby book that wasn't available on the web. I'd bet that you would buy the better book, but still use the free version for your online needs -- grepping, cutting-n-pasting, etc. Given competition, the only way the free online version will sell print copies is if it's the best.
The thing about having a book available for free in addition to a dead-trees version is that it requires your book to be the best. If your book is merely useful, people will just download it. If you're going to sell it, you need to demonstrate utility far beyond what someone would get from simply downloading it.
Recreational books are cheap and pleasure-oriented. They're also end-to-end. With any one of the Baen books, you outlay about six bucks and you've got 15-30 hours of reading pleasure ahead of you. Generally speaking, the book isn't random-access. You need to read the whole thing to derive pleasure from it (or, at least, pleasure is maximised by reading the entire book in sequential order).
Technical books are expensive and solution-oriented and (generally) random-access. For example, maybe you work for a company that stores a bunch of information in a database that's shared across divisions. You're getting sick of being unable to make changes to the schema because everyone in the company is touching your data. You decide to wrap the whole thing up in a web service and allow people to access the database that way. So, you buy O'Reilly's web services book, learn a bit about SOAP, install Tomcat, and expose your data through a web services interface. Now, if the O'Reilly WS book were on line, you'd probably go in, look up the stuff you need, print out the appropriate pages, and write your interface. Once the job is done, you wouldn't go down to B&N and buy a copy of the book for your bookshelf.
So, what you're comparing is a cheap book that needs to be entirely consumed versus an expensive book that can be used in small portions. For that reason, I don't think that you can generalise and say that because sci-fi sells well even when available for free, then the same relationship holds for technical books.
Writing a book is (in many ways) akin to developing a large software project. It requires the skill to work in the trenches as well as at 1E4 feet and still see how everything hangs together. The difference between developing software and writing a book is that in the latter case, everyone reads your source code. If you're writing a spreadsheet application and it passes all the unit and functional tests, it doesn't matter if it's pure spaghetti code (ignoring factors like maintainability, scalability, cost-of-ownership, etc.) The purpose of the app is number-crunching. The purpose of a book is to transmit information. However, the clarity of the "code" is integral to fulfilling this function. A book doesn't have unit tests and functional tests to validate its success. It only has usability tests.
My experience comes from both sides of the fence. I've been a software architect for a Fortune 500 corporation and I was the acquisitions editor (and part-time developmental editor) for a technical publishing company. As an acquisitions editor I realised pretty soon that a large percentage of technical people look at writing as a brain dump. These are people who would never dream of sitting down to code without, at the very least, sketching out some designs on an index card. But they feel perfectly comfortable sitting down to write chapter one with a blank page and no notes and expecting to finish 450 pages later. As you might expect, most of these books were either never completed or were unpublishable. (This is probably what you'd expect if a software project were managed the same way.)
My question for you, Bruce, is this -- what kind of editorial support will PH be offering? Is this just going to be documentation that is bound and offered for sale? Or will there be an editorial process that help prevent these books from being more than a brain dump (which, IMHO, is about as intelligible as a core dump).
Cheers,
Alex
Incidentally, StarLogo has a resemblance to Logo, but it's primarily superficial. StarLogo is all about exploring emergent behaviours in decentralised systems. While you can do regular turtle graphics in StarLogo, if you do it, you're kind of missing the point.
StarLogo uses thousands of turtles, instead of just a couple. StarLogo also allows the turtles to interact with their environment by doing things like creating pheromone trails. This makes it easy to do things like build an ant colony and watch it explore for food and create trails to the food for other ants to follow.
Incidentally, the ant colony code only uses thirteen procedures, each one no more than five or six lines of code. Here's a sample:
This defines the way an ant finds food. Essentially, if it's not carrying food it checks the ground to see if there's any food there (ask patch-here). If there is, it sets itself to carry it and reduces the amount of food on the ground by one unit. The line set-drop-size sets the initial magnitude of the pheremone drop. There's another demon (return-to-nest-demon) that takes over once the ant gets food. It's responsible for following the pheremone gradient back to the nest and to mark the trail to the food by decreasing the food pheremone with each step back to the nest. That way the food pheremone will be strongest near the food, causing the hungry ants to go in that direction.One of the other interesting parts of the book, Turtles, Termites, and Traffic Jams is the author's descriptions of the kids that he works with. He takes StarLogo into grade schools and gives the kids problems (like the ant problem, or a traffic jam modeling problem) and watches them solve it. All in all, it's an excellent book and I highly recommend it.
Actually, it was completeness and consistency that Godel tackled, and he proved it (rather than implied it). Complete = all true statements have a proof. Consistent = p & ~p is not a theorem of the system. This is for all systems strong enough to support the Peano axioms (and some weaker systems, I believe). However, 1st order logic is both complete and consistent.
Is this the book you're referring to? If so, the author is Eric Temple Bell and it is a fabulous book. I didn't see any books on Amazon written by a Carl Brooks that dealt with math.