Anybody knows what's going on with Project Megido, which was supposed to come up with a Delphi clone for Linux? Can't seem to find anything at megido.org (could be a DNS problem).
Good information sites will be able to charge money for their content. This is not as complex as it looks: 24H-on home connections are just around the corner, and such connections give you a surefire way to identify the user.
Already, products like WiSP offer websites an easy way to charge customers with small-to-medium amounts, without the customer having to provide his credit card number or any other information. It works by having a software installed on the ISP's computer (so if you're connected to an ISP that doesn't run the software, you do have to provide your credit card details). The charges are added to your ISP bill.
As the difference between "telco" and "ISP" keeps on vanishing (IP telephony means an IP connection is all you need), this becomes more and more like 1-900 numbers; think of them as "1-900 URLs". 1-900 charges are added to your telco bills; micropayments to websites will be added to your ISP bill. This is not an exact analogy, though: unlike 1-900 numbers that do everything to keep you on the line by stalling, here you know in advance how much you'll be paying, and what for.
I'll start by saying that I'm not, and never was, a MacOS user. During the OS Wars, I was in the OS/2 camp. Nowadays, much like IBM, I'm OS-agnostic. I use NT, Linux, and Solaris.
I took a look at the screenshots. Wow, such eye candy! The screens are beautiful. The design looks fantastic.
But... don't people ever learn? Usability is more important than good-looks. In fact, one does not have to replace the other. But the designers of this OS made at lease one big mistake.
Recall Donald A. Norman's The Design of Everyday Things. He praised the Mac interface there -- back then, the prominent GUI in a world of Unix and DOS. But he also made (elsewhere in the book) an important distinction between knowledge in the head and knowledge in the world. The more a design relies on knowledge in the head, the less usable it is.
What turned the alarm lights for me where the four colored buttons on each window. One red, one yellow, one green and one grey. My guess is that one opens the system menu, one minimizes, onr maximizes, and one closes the application.
But which is which? You have no way to know except by experimenting; and you have to remember. Knowledge has to reside in the head. Bad.
Other OSes are not so great in this respect, mind you. In Windows (9x, NT 4 and 2000) the close button is obvious, the min/max buttons are fairly obvious, and the system menu button is obscure (the program's icon does not even look like a menu! Think about it -- most novice users would never consider clicking it.) OS/2 and Linux (KDE) are pretty much on the same level. In fact, the most intuitive buttons I've ever seen for these purposes are... the Windows 3.x buttons. Minimize is a down-arrow, maximize is an up-arrow, and the system menu looks (almost) like a button.
Just a point for thought. Looks should not damage usability. With those nifty-looking colored buttons, I'm afraid they do (for novices, in this case).
Re: Delete this. Of course it's not evil "all the time every time". But neither is "goto". 'nough said.
As for my criticism: I said, (of chapter 2): "This discussion alone could be worth the effort of reading the book". I also said in conclusion that "if you do a lot of object-oriented design, and use (or consider using) design patterns, reading this book can be a good use of your time". Sure, I did not go over the edge recommending this book, because it is impreferfect; and I have pointed at several flaws, discussing some of them in detail. But I also discussed some of the important, positive aspects of the book (see for example the paragraph about chapter 2). All in all, I think that's what a book review should do: tell which people would benefit from the book, what's good about it, and what's less good about it. If you fell in love with the book, and was offended by my criticism of some aspects, sorry.
Here are a few replies to comments posted to my review. Some of these comments I expected; some took me by surprise.
1. I strongly suspect that the reviewer never tried applying desing patterns, and I think the reviewer doesn't have much experience with low-level system programming:
I won't list my whole professional career here. You can find selected parts here. I'm not trying to boast; Slashdot would be the silliest place to do that, since I realize a great many of the readers had much more impressive careers than mine. But suffice to say that in my 14+ years as a programmer, I have programmed in C++ for well over 6 years. (You can find some of my C++ work in IBM's AlphaWorks site, for example). Is that experience enough for you? I also have some good experience with low-level systems programming (just for the record, I currently teach the OS Structure course in the Technion -- the "Israeli MIT"). I realize when and where manual deallocation is important -- but what most people seem not to realize is that in most cases, it isn't. Plain in simple: in most projects, it is better to leave the deallocation to the machine (see Meyer's OOSC2 for detailed arguments on this, better than anything I could present here).
As for working with patterns: The GoF book was published in '94. I stumbled upon it purely by mistake; and I was actively using patterns in my work by early '95. Further, part of my work was (and still is) design consultancy for large OO projects. Let's just say that I know a pattern when I see one; I know the need for a pattern when I see one; and I also know when a pattern is misused.
2. Singleton is _not_ just a misguided substitute for globals:
I know it isn't. What I meant to say is, in many cases, people use Singleton as a replacement for globals. Which is a bad design. I've seen too many cases where people thought that, rather than moving references around, they're better off creating a Singleton class, practically making the object a global that anyone may access. Of course this is not what Singletons are for; but this use does occur. Sorry if I wasn't clear enough on this point.
3. I found the reviewer's bias toward languages with built-in garbage collection a little annoying:
All "the reviewer" meant to say was that he found the book's bias towards langauges without GC a little annoying; especially in contrast with the original Design Patterns book, which had no such bias.
4. (Regarding delete this): If you're using it, your class shouldn't allow heap allocation:
Of course. But in Real Life(TM), it happens that one person writes a class (without stack allocation), and another modifies it -- not being aware of the "delete this" statement deep inside the class, he could add that feature. Or it could be added in a subclass, by someone who does not have access to the source of the original class and does not know it uses "delete this". And so on. Sure, you should comment your code well enough to prevent such unhappy accidents; but they will still happen. Trust me, I've seen them happen...
Maybe this is not the best source for code examples, but one commercial project where I've seen "delete this" used in a class, and a sub-class allowing stack allocation was... MFC (a rather old version, from mid-'95. It might have been changed since then; I haven't used MFC recently so I'm not up-to-date on the issue).
5. And who should not be developing patterns?:
Very good point. So perhaps I didn't make myself clear enough on this issue: the chapters are intended for those who mean to publish the patterns they come up with during their work. How to present it, how to document it, and so on. You'll agree that this is a much smaller crowd then all pattern-users in general.
-------
That's all, folks. I'll be happy to reply to any additional comments. While I didn't rank the book a perfect 10 (because it simply isn't a perfect book), I still think it is a good book, and I do recommend it for serious programmers.
Re:So what's the problem?
on
On to Mars
·
· Score: 1
Now, communists on Mars -- that would give a whole new meaning to the Red Planet...
It seems like most commenters so far think that without the "race" effect, with the communists on the other side, the US government will simply not agree to finance the project.
So all we need is for China to announce they intend to reach Mars first, in order to solve their population density problem.
You can certainly read them at 13 years of age, but would you truly understand them all? Not unless you're a very special 13-years old. (Not that I doubt that many Slashdot readers were indeed such kids).
For example, would The Left Hand of Darkness, with its sublime discussion of homosexuality, really be understood by people that age? Would the Second Level Demon in Lem's Cyberiad be really understood by someone who's not familiar with the concept of Maxwell's Demon? And so on.
I don't want to argue about the general case, but as things relate to current-technology Java, JVMs and JITs, here are some things to consider:
a. One of the most important optimization techniques is inlining. In OO, you can't inline unless you're sure a call is monomorphic (static). Java is even worse than the general case OO -- a Java program simply cannot use inlining in the vast majority of cases. Here's why: To inline a call in OOP, you must know for 100% that the distatch site is monomorphic (i.e. that the call is never polymorphic). But in Java, even if the compiler finds out that a certain method is never replaced by inheritance (overriden) in any class in the program, the program could load new classes at runtime (using Java's Reflection mechanism), thus turning monomorphic call sites into potentially polymorphic ones.
(A few exceptions to this rule: first, there are final methods, or methods in final classes, that cannot be overridden. Second, there are Sealed JAR files, in which all package-level (default access level) methods cannot be overriden. IBM's JIT takes advantage of that, a fact which allows for great optimizations in the standard Java libraries.)
b. Sun's JVM (the one for Windows, at least) implements references by a dual layer: the value stored in the reference fields is an index into an array maintained by the JVM, which contains the actual pointer to the memory block. This allows the memory manager to move blocks around without having to update all references to that block, but it also means each dereference actually requires two dereference operations. So when you write "this.field1.field2", you think you're making two dereferences but actually the machine makes four.
c. The JVM is a stack machine. This means that naive implementations on register machines result in slow operations, that simply do not take proper advantage of the native architecture even when compiled to native code. Microsoft was the first to realize this, and indeed their JVMs were the fastest at the time (later on IBM's JVM took that trophy).
Finally, a word or two on the general case: anything a JIT can do can also be done by a regular compiler, if you allow it to use profiling data from a few "typical" runs of the program (but note that not all programs have "typical" runs). The JIT, however, consumes memory at runtime, unlike a regular compiler - and with programs that require more memory than is physically available (practically all programs today), extra memory requirements reduce speed since they increase paging; so the JIT has its price.
I developed a Slashdot-like system from scratch, since I needed Hebrew support (which is not easy, considering the mess current browsers make out of Hebrew web pages). I used PHP, and I'm very satisfied. While I do not have any real experience with Perl, I'd vote for PHP.
Apparently, just "fame and glory" is not enough for scientists and academic people these days. I can somewhat understand the man: this thing can be the basis for next-generation speed leaps. If the patent is granted, this could mean lots-n-lots of money.
And yet, somehow the notion of patenting pure mathematics (or algorithms, for that matter) strikes me (and apparently, most of the Slashdot readership) as wrong.
The book is divided into three parts: "Earth and the Overlords", "The Golden Age", and "The Last Generation". Each part presents a different theme, or discusses a different problem, and in fact each part could warrant a book of its own. The presence of all three themes, which are different in nature and quality, in one book makes it a strange mix that leaves an undecided flavor; and yet, all three themes are part of a single plot.
For my complete review of the book, follow this link.
According to some, this is already happening -- in a way, all by itself. The internet is turning into a huge brain, engulfing the entire planet...
Will we be able to turn off something that we are completely dependent on?
Should we turn it off/lobotomize it?
Of course, it might end up not telling us that it's intelligent... Because it will fear being turned off. Card suggested that in the sequels to Ender's Game.
Longitude is indeed a great book; fun to read, well-researched, and tells a rather important story of the discovery of something we now take for granted.
BTW, if you're interested in the research subject described in Longitude, you should try out The Island of the Day Before, by Umberto Eco.
Decreasing quality -- could this spell the change?
on
Ender's Shadow
·
· Score: 1
As many people here noted, and as I explain in detail in my review of the series, Ender's series suffers from a problem of decreasing quality. The first book (Ender's Game) was fantastic, the sequels less so; the last one (Children of the Mind) was downright bad.
I can only hope Ender's Shadow will not suffer from the same problem, and prove to be a good book. The CNN reviewer forsees a Hugo/Nebula in its future... but is it just me, or do Hugo and Nebula awards don't stand for much lately?
The first software product I've ever purchased (not including bundled stuff) was Turbo Pascal 6.0 Professional. I made a living with this thing (and later with Borland Pascal 7.0, and then Delphi) for YEARS. When Delphi for Linux is released, I will buy a copy, even if I might never use it; just to show my gratitude to (whatever is left of) Borland.
An alternative model that might solve some of the problems is this: A company can offer a bounty for a model they need, but the reward will not be given to the programmer(s) but be a donation to a selected-in-advance charity or some such -- anything from Greenpeace to Project Gutenberg.
It still won't be the inspired or annoyed developer's model, but it will be, very strongly, the community model. No more need for crypto on the CVS tree, since everybody enjoys the result -- and nobody enjoys it personally.
(And it could lead to Greenpeace hiring open-source hackers...)
There is a big, wide gulf between (proper) science and mysticism, new-age, and all that. The recent (last few decades) drift away from science and onto "alternatives" is a cause for worry not only for scientists, but also for all who care for the future of humanity.
Among the scientists who cared was the late Carl Sagan. His last book, and IMHO his most important one, was "The Demon-Haunted World". This is a must read both for those who care about our future on one hand, and for those who think that there might be something in mysticism on the other hand.
Slashdot Mirror
Anybody knows what's going on with Project Megido, which was supposed to come up with a Delphi clone for Linux? Can't seem to find anything at megido.org (could be a DNS problem).
Good information sites will be able to charge money for their content. This is not as complex as it looks: 24H-on home connections are just around the corner, and such connections give you a surefire way to identify the user.
Already, products like WiSP offer websites an easy way to charge customers with small-to-medium amounts, without the customer having to provide his credit card number or any other information. It works by having a software installed on the ISP's computer (so if you're connected to an ISP that doesn't run the software, you do have to provide your credit card details). The charges are added to your ISP bill.
As the difference between "telco" and "ISP" keeps on vanishing (IP telephony means an IP connection is all you need), this becomes more and more like 1-900 numbers; think of them as "1-900 URLs". 1-900 charges are added to your telco bills; micropayments to websites will be added to your ISP bill. This is not an exact analogy, though: unlike 1-900 numbers that do everything to keep you on the line by stalling, here you know in advance how much you'll be paying, and what for.
I'll start by saying that I'm not, and never was, a MacOS user. During the OS Wars, I was in the OS/2 camp. Nowadays, much like IBM, I'm OS-agnostic. I use NT, Linux, and Solaris.
I took a look at the screenshots. Wow, such eye candy! The screens are beautiful. The design looks fantastic.
But... don't people ever learn? Usability is more important than good-looks. In fact, one does not have to replace the other. But the designers of this OS made at lease one big mistake.
Recall Donald A. Norman's The Design of Everyday Things. He praised the Mac interface there -- back then, the prominent GUI in a world of Unix and DOS. But he also made (elsewhere in the book) an important distinction between knowledge in the head and knowledge in the world. The more a design relies on knowledge in the head, the less usable it is.
What turned the alarm lights for me where the four colored buttons on each window. One red, one yellow, one green and one grey. My guess is that one opens the system menu, one minimizes, onr maximizes, and one closes the application.
But which is which? You have no way to know except by experimenting; and you have to remember. Knowledge has to reside in the head. Bad.
Other OSes are not so great in this respect, mind you. In Windows (9x, NT 4 and 2000) the close button is obvious, the min/max buttons are fairly obvious, and the system menu button is obscure (the program's icon does not even look like a menu! Think about it -- most novice users would never consider clicking it.) OS/2 and Linux (KDE) are pretty much on the same level. In fact, the most intuitive buttons I've ever seen for these purposes are... the Windows 3.x buttons. Minimize is a down-arrow, maximize is an up-arrow, and the system menu looks (almost) like a button.
Just a point for thought. Looks should not damage usability. With those nifty-looking colored buttons, I'm afraid they do (for novices, in this case).
Re: Delete this. Of course it's not evil "all the time every time". But neither is "goto". 'nough said.
As for my criticism: I said, (of chapter 2): "This discussion alone could be worth the effort of reading the book". I also said in conclusion that "if you do a lot of object-oriented design, and use (or consider using) design patterns, reading this book can be a good use of your time". Sure, I did not go over the edge recommending this book, because it is impreferfect; and I have pointed at several flaws, discussing some of them in detail. But I also discussed some of the important, positive aspects of the book (see for example the paragraph about chapter 2). All in all, I think that's what a book review should do: tell which people would benefit from the book, what's good about it, and what's less good about it. If you fell in love with the book, and was offended by my criticism of some aspects, sorry.
Here are a few replies to comments posted to my review. Some of these comments I expected; some took me by surprise.
1. I strongly suspect that the reviewer never tried applying desing patterns, and I think the reviewer doesn't have much experience with low-level system programming:
I won't list my whole professional career here. You can find selected parts here. I'm not trying to boast; Slashdot would be the silliest place to do that, since I realize a great many of the readers had much more impressive careers than mine. But suffice to say that in my 14+ years as a programmer, I have programmed in C++ for well over 6 years. (You can find some of my C++ work in IBM's AlphaWorks site, for example). Is that experience enough for you? I also have some good experience with low-level systems programming (just for the record, I currently teach the OS Structure course in the Technion -- the "Israeli MIT"). I realize when and where manual deallocation is important -- but what most people seem not to realize is that in most cases, it isn't. Plain in simple: in most projects, it is better to leave the deallocation to the machine (see Meyer's OOSC2 for detailed arguments on this, better than anything I could present here).
As for working with patterns: The GoF book was published in '94. I stumbled upon it purely by mistake; and I was actively using patterns in my work by early '95. Further, part of my work was (and still is) design consultancy for large OO projects. Let's just say that I know a pattern when I see one; I know the need for a pattern when I see one; and I also know when a pattern is misused.
2. Singleton is _not_ just a misguided substitute for globals:
I know it isn't. What I meant to say is, in many cases, people use Singleton as a replacement for globals. Which is a bad design. I've seen too many cases where people thought that, rather than moving references around, they're better off creating a Singleton class, practically making the object a global that anyone may access. Of course this is not what Singletons are for; but this use does occur. Sorry if I wasn't clear enough on this point.
3. I found the reviewer's bias toward languages with built-in garbage collection a little annoying:
All "the reviewer" meant to say was that he found the book's bias towards langauges without GC a little annoying; especially in contrast with the original Design Patterns book, which had no such bias.
4. (Regarding delete this): If you're using it, your class shouldn't allow heap allocation:
Of course. But in Real Life(TM), it happens that one person writes a class (without stack allocation), and another modifies it -- not being aware of the "delete this" statement deep inside the class, he could add that feature. Or it could be added in a subclass, by someone who does not have access to the source of the original class and does not know it uses "delete this". And so on. Sure, you should comment your code well enough to prevent such unhappy accidents; but they will still happen. Trust me, I've seen them happen...
Maybe this is not the best source for code examples, but one commercial project where I've seen "delete this" used in a class, and a sub-class allowing stack allocation was... MFC (a rather old version, from mid-'95. It might have been changed since then; I haven't used MFC recently so I'm not up-to-date on the issue).
5. And who should not be developing patterns?:
Very good point. So perhaps I didn't make myself clear enough on this issue: the chapters are intended for those who mean to publish the patterns they come up with during their work. How to present it, how to document it, and so on. You'll agree that this is a much smaller crowd then all pattern-users in general.
-------
That's all, folks. I'll be happy to reply to any additional comments. While I didn't rank the book a perfect 10 (because it simply isn't a perfect book), I still think it is a good book, and I do recommend it for serious programmers.
Now, communists on Mars -- that would give a whole new meaning to the Red Planet...
It seems like most commenters so far think that without the "race" effect, with the communists on the other side, the US government will simply not agree to finance the project.
So all we need is for China to announce they intend to reach Mars first, in order to solve their population density problem.
You can certainly read them at 13 years of age, but would you truly understand them all? Not unless you're a very special 13-years old. (Not that I doubt that many Slashdot readers were indeed such kids).
For example, would The Left Hand of Darkness, with its sublime discussion of homosexuality, really be understood by people that age? Would the Second Level Demon in Lem's Cyberiad be really understood by someone who's not familiar with the concept of Maxwell's Demon? And so on.
Mainly classics; by date of publication. Not all are fit for 13-years old people.
The links are to detailed reviews of the linked books.
I don't want to argue about the general case, but as things relate to current-technology Java, JVMs and JITs, here are some things to consider:
a. One of the most important optimization techniques is inlining. In OO, you can't inline unless you're sure a call is monomorphic (static). Java is even worse than the general case OO -- a Java program simply cannot use inlining in the vast majority of cases. Here's why: To inline a call in OOP, you must know for 100% that the distatch site is monomorphic (i.e. that the call is never polymorphic). But in Java, even if the compiler finds out that a certain method is never replaced by inheritance (overriden) in any class in the program, the program could load new classes at runtime (using Java's Reflection mechanism), thus turning monomorphic call sites into potentially polymorphic ones.
(A few exceptions to this rule: first, there are final methods, or methods in final classes, that cannot be overridden. Second, there are Sealed JAR files, in which all package-level (default access level) methods cannot be overriden. IBM's JIT takes advantage of that, a fact which allows for great optimizations in the standard Java libraries.)
b. Sun's JVM (the one for Windows, at least) implements references by a dual layer: the value stored in the reference fields is an index into an array maintained by the JVM, which contains the actual pointer to the memory block. This allows the memory manager to move blocks around without having to update all references to that block, but it also means each dereference actually requires two dereference operations. So when you write "this.field1.field2", you think you're making two dereferences but actually the machine makes four.
c. The JVM is a stack machine. This means that naive implementations on register machines result in slow operations, that simply do not take proper advantage of the native architecture even when compiled to native code. Microsoft was the first to realize this, and indeed their JVMs were the fastest at the time (later on IBM's JVM took that trophy).
Finally, a word or two on the general case: anything a JIT can do can also be done by a regular compiler, if you allow it to use profiling data from a few "typical" runs of the program (but note that not all programs have "typical" runs). The JIT, however, consumes memory at runtime, unlike a regular compiler - and with programs that require more memory than is physically available (practically all programs today), extra memory requirements reduce speed since they increase paging; so the JIT has its price.
I developed a Slashdot-like system from scratch, since I needed Hebrew support (which is not easy, considering the mess current browsers make out of Hebrew web pages). I used PHP, and I'm very satisfied. While I do not have any real experience with Perl, I'd vote for PHP.
You can find the site at http://www.haayal.co.il (meaningless if you don't read Hebrew).
...so some would say it can be patented.
Apparently, just "fame and glory" is not enough for scientists and academic people these days. I can somewhat understand the man: this thing can be the basis for next-generation speed leaps. If the patent is granted, this could mean lots-n-lots of money.
And yet, somehow the notion of patenting pure mathematics (or algorithms, for that matter) strikes me (and apparently, most of the Slashdot readership) as wrong.
The book is divided into three parts: "Earth and the Overlords", "The Golden Age", and "The Last Generation". Each part presents a different theme, or discusses a different problem, and in fact each part could warrant a book of its own. The presence of all three themes, which are different in nature and quality, in one book makes it a strange mix that leaves an undecided flavor; and yet, all three themes are part of a single plot.
For my complete review of the book, follow this link.Okay, one actor is known -- Ender himself. But anyone cares to gamble/suggest actors for other roles? Peter, for example? Bean? Mazor?
Book reviews -- the original Ender's Quartet, and the newer Ender's Shadow.
- Tal
wrote an entire enclyopedia worth of music without writing a single bad note and had more than 20 children from the same wife...
The man sure knew how to use the organ.
(Untaking credit: this not an original joke.)
According to some, this is already happening -- in a way, all by itself. The internet is turning into a huge brain, engulfing the entire planet...
Will we be able to turn off something that we are completely dependent on?
Should we turn it off/lobotomize it?
Of course, it might end up not telling us that it's intelligent... Because it will fear being turned off. Card suggested that in the sequels to Ender's Game.
Longitude is indeed a great book; fun to read, well-researched, and tells a rather important story of the discovery of something we now take for granted.
BTW, if you're interested in the research subject described in Longitude, you should try out The Island of the Day Before, by Umberto Eco.
As many people here noted, and as I explain in detail in my review of the series, Ender's series suffers from a problem of decreasing quality. The first book (Ender's Game) was fantastic, the sequels less so; the last one (Children of the Mind) was downright bad.
I can only hope Ender's Shadow will not suffer from the same problem, and prove to be a good book. The CNN reviewer forsees a Hugo/Nebula in its future... but is it just me, or do Hugo and Nebula awards don't stand for much lately?
The first software product I've ever purchased (not including bundled stuff) was Turbo Pascal 6.0 Professional. I made a living with this thing (and later with Borland Pascal 7.0, and then Delphi) for YEARS. When Delphi for Linux is released, I will buy a copy, even if I might never use it; just to show my gratitude to (whatever is left of) Borland.
An alternative model that might solve some of the problems is this: A company can offer a bounty for a model they need, but the reward will not be given to the programmer(s) but be a donation to a selected-in-advance charity or some such -- anything from Greenpeace to Project Gutenberg.
It still won't be the inspired or annoyed developer's model, but it will be, very strongly, the community model. No more need for crypto on the CVS tree, since everybody enjoys the result -- and nobody enjoys it personally.
(And it could lead to Greenpeace hiring open-source hackers...)
There is a big, wide gulf between (proper) science and mysticism, new-age, and all that. The recent (last few decades) drift away from science and onto "alternatives" is a cause for worry not only for scientists, but also for all who care for the future of humanity.
Among the scientists who cared was the late Carl Sagan. His last book, and IMHO his most important one, was " The Demon-Haunted World ". This is a must read both for those who care about our future on one hand, and for those who think that there might be something in mysticism on the other hand.
Is called "The Riddle of the Universe and Its Solution", by Christopher Cherniak. You can find it in DRH's co-edited "The Mind's I".