* I'm really sorry everyone. I want you all to know that this was really intended as a satire piece, but the editors didn't realise and have published it as fact.
It was really hard to keep a straight face while writing it, and I was obviously hoping for the same reaction from my readers.
Oh, the ads here are satire too. Have you read the M$ TCO one? It's a hoot!"
I first read the title as "Alan Cox is writing better software", and thought that finally he's doing that:-) Then I realized my mistake and was disappointed.
I think this whole dispute is not necessary. It's just a simple case of conflicting goals. One side wants "efficiency" and another wants "extensibility". What both sides miss is that real systems can't afford to choose just one of these, you have to get both. So you have to have just enough extensibility to allow reasonable extensions, and still attain reasonable levels of efficiency. But trying to get all of either thing will totally lose the game. So the XML camp is wrong to think that extensibility is everything (ever tried parsing XML in a real-time system?). And the "binary transfer format" camp is wrong to think efficiency is everything (ever tried to make two versions of your protocols to interoperate?).
I think the article missed a subtle point. Open source is a developer-created phenomenon. Open source software is normally written for some real use. That is, we need the software we write. Sometimes it's only written to be able to understand how software engineering works [students]. Now that's the reason there are a gazillion of different IRC clients/bots, for some reason, many students seem to like IRC and want to understand how such "cool" technology works, so they write IRC clients/bots or whatever is the latest fad. Sometimes we write software because we hate the existing alternatives and want to improve the situation, and the current state of affairs is causing headache. This is why most open source software is intended for developer use only, it's developers writing software for ourselves. Sometimes the reason is that there is no alternative available, but you need it. But more often, the reason is convenience. It's often easier to write some small utility yourself than try to use any existing solution or commercial package for it [not to mention it costs less]. I would view this as a failure of the commercial marketplace for handling commodity software.
Now, of course, the article makes the correct point that usually we don't get any money from the software, even if we use lots of time writing it. Why is that? The reason is, it's not possible to distribute software commercially that doesn't have the critical mass, which would allow all the participants in the distribution chain to recover their costs, which means generating a steady revenue stream for a very long time. This is highly improbable for the kinds of software where open source is most successful. This means that if your software is not "good enough" for the commercial market, then you have only three choices:
1) Not distribute it at all beyond your friends
2) Start a company to sell it, and improve the software to "commercial grade" by using various funding mechanisms available in the marketplace.
3) Open source it
From this point of view, open sourcing those is the least risky way to approach the problem. Starting a company for your 1000 line utility isn't a good choice. Starting a company doesn't work, if you already have a job. Open sourcing is one way of getting access to a large pool of people who are willing to try your software out, and find problems in it before you cause yourself problems due to those bugs. Once your software reaches the critical mass, it's already been open source for so much time that it's not possible to revert it back [and it would be counter-productive]. Also, keeping the software for yourself has no point, if you know you can't finish it by yourself. And most people are not willing to contribute for a cause that doesn't help them [e.g. if your licensing only allows you to benefit from it].
I think this might change if there were ways to commercially publish, reuse and distribute small pieces of software without huge distribution costs. But this doesn't exist. Long time ago, shareware was thought to be a solution, but it proved not to work, because people are not willing to send money for some random software for which there is no way it could ever evolve past its primitive state due to the licensing hurdle needed to get the money. Open source really solves this problem well, this allows everyone to benefit, even if it's not in monetary units. Just having the software is more valuable than the money you could ever make from it.
Well of course, they are not trying to send light to that interstellar travel. To make your spaceship move faster than light, I guess the best bet is to try to slow the light to reasonable speeds, so that you can then more easily exceed that speed! And if exceeding the speed of light is the silver bullet of interstellar travel, I would say they're doing exactly the right thing!
There is no silver bullet, no magical solution, no instantaneous makes-my-problem-go-away widget that is all things to all problems.
But silver bullets do exist. Or what do you think they used to kill all those werewolves? But granted, it was a magical solution to a non-existent problem. I guess many solutions in the software industry follow this pattern. On the other hand, this is exactly what many people expect software to do.
It's much easier to sell magical solutions than those that actually work. Not many people get excited about software that just silently performs all the work. You need those small problems to ensure that the people in charge find out your product exists, so you can also sell them the next version.:-)
1) Too much color. 2) Broken links 3) Empty popups for collecting two clicks per user for advertisers. 4) IE-only pages as corporate intranet 5) Wiki pages that anyone can delete (and has!) 6) Wiki pages that nobody could change since 1998 7) Menus that take you to the same information you already saw on the main page 8) Frames 9) Unidirectional links (auto-refresh!) 10) Input fields with one line of text for entering your problem report
...for one thing, the model of selling a product doesn't work in the software development industry.
What? You had better share that insight with all of the commercial software vendors out there quickly before they go out of business! Make sure to include Microsoft, Oracle, IBM, etc...!
But Microsoft does not sell products. Microsoft sells licenses to products. The fact is that you cannot sell products in any business whose cost-structure is based primarily on R&D costs, since the market does not understand R&D costs. The market knows unit costs and tries to make products cost close to an ideal unit cost. Now for all R&D dominated businesses, this ideal unit cost is zero. This failure of the market, combined with a standard requirement for mass-market products, i.e. that your unit production time is less than 2 years, is a disaster for software. This time is intended to only cover the time it takes to find customers.
This is why most software businesses have to either sell licenses (which is a bad substitute) or build hardware whose unit costs are not zero, then bundle the software with the hardware. It's also the reason for the problems so many small software companies are having. The market is just not designed to be used in situations where you have to spend considerable amount of time for developing a product before you can sell anything. It assumes you can sell your product from day one, and that most costs are associated with making copies of the same simple design.
Ok, everyone knew it but I claim that backward time travel is possible (in a sense) but cannot be observed. It is really simple to prove.
First, we have to understand time itself. My hypothesis is that time is an observation of irreversible processes. If a process is not irreversible, then going through that process will not get you forward in time [nor backward for that matter].
Obviously, it is possible to create a loop using just reversible processes [any two 'instances' of the same part of a reversible process are indistinguishable]. This means that any such loop would be confined in the same time. [Physicists actually observe such loops, a pair creation followed by annihilation is one such loop]. Note that this implies that time travel is really possible. What you do is you use pair creation to build two exactly similar objects, one from matter, another from antimatter. The antimatter version travels backwards in time [as observed by external observers made of ordinary matter], and the matter version travels forward. As long as you do not use irreversible processes, you can at some point annihilate those two versions, and have provided such a loop. However, to ensure that, you cannot observe that object (observation is irreversible!). You can however observe *parts* of such object, and all such observations will influence both 'copies' of the object [since it's actually the same object just observed from different locations!].
Now consider photons. How would you *ever* observe the 'same' photon at two different times? I would say you cannot have done that, because time doesn't pass for a photon! So if you consider a single photon, its creation (some atom emits the photon) and its destruction (absorption) occur at two adjacent units of time [from the point of view of the photon!]. The reason that the external world observes light to travel at high speed is because there are many irreversible processes in the observers, and those processes bring those observers away from (or towards) the stationary photon!
In contrast, consider the reversible process of a photon creating a electron-positron pair. A photon and the electron-positron pair are obviously interchangeable [since the process is reversible]. If you now observe the created electron, the electron has transformed into something that you cannot any more transform back to the original photon. Therefore, the positron that was left must also have changed 'at the same moment' [otherwise the process would be reversible]. So the 'next unit of time' for the positron must have been when the positron is destroyed (or observed), and this must occur at the same time as when the electron was destroyed. From this, you can determine that the directions and speed that the electron-positron pair start to travel on pair creation must be such that the destruction of the components of the pair occur 'simultaneously' [at next unit of time from the points of views of both the electron and the positron!].
This model also explains why time can pass in different speeds in different parts of the universe [some parts of universe just happen to be more suspectible for initiating irreversible processes]. So measuring time is a way of measuring the rate of change of entropy. In particular, any processes that only use reversible processes are observed to move at the speed of light. In effect, "moving at the speed of light" is the (only) way to not change at all. [Here, 'change' means that there is a state reachable from the initial state through a series of irreversible processes; obviously, you cannot refer to time when defining 'change'].
Then, according to this model, what is gravity? Acceleration of the gravity would be an artifact from the way that objects interact. In particular, it would be caused by (causal) interaction of objects whose time passes in different rate and the structure of those interactions. The difference in elapsed time between two interactions of the same pair of objects would be directly translated to corresponding observed acceleration between those objects [the conversion ratio is obviously the speed of light]. This explains why there is an approximate correlation between decay rate of particles and their mass.
Now, consider backward time travel in a way that you would actually be able to observe it. That would mean that your irreversible processes used to observe the information would start to reverse themselves! That is a contradiction.
Most patent (applications) I know are written in an obscure variation of english, probably only known by lawyers. In particular, it seems that any applications are obscured by the lawyers to point where the experts in the area can hardly understand what's going on [or anyway, it's made unnecessarily hard to understand]. I'm wondering what is the reason for this, and what you think should be done to prevent it?
You cannot be an architect unless you also implement, since it's impossible to design the architecture
unless you know what happens inside the software. And you cannot get this knowledge without participating in the implementation.
Therefore, there is no problem. The only thing is, there are higher hopes for you (in addition to the ordinary requirements for coders, you are also expected to actually design the system!) It's just more responsibility. Nothing else changes!.
See the Architect also implements (http://www.bell-labs.com/user/cope/Patterns/Proce ss/section16.html) software process pattern for a detailed overview.
> That all depends on if He planned for
> the universe to ever exit().
> We will need to consult the prophets
> to find the answer.
But the profets cannot do that. Since the type of exit is "integer -> _|_", and you cannot ever have objects of type _|_ unless the universe is inconsistent, you can never observe an invocation to exit. Since it is also impossible to determine whether an arbitrary creation is semantically equivalent to a given another creation, you cannot even reliably find a valid example of exit. Therefore, there are no means which the profets could use to determine whether the universe incorporates the exit semantics.
Of course, this is fine. If the profets could find an implementation of exit, this would immediately reduce the universe to an instance of _|_ (not least due to the profets just accidentally using the button labelled "BEWARE, IN NO SITATION SHOULD THIS BUTTON BE PRESSED, OR THIS UNIVERSE WILL CEASE TO EXIST. PROCEED ONLY AT YOUR OWN PERIL. THE MANUFACTURER OF THIS BUTTON CANNOT BE HELD RESPONSIBLE FOR ANY ACTIONS TAKEN BY USERS OF THIS BUTTON, EVEN IF IT WOULD RESULT IN LOSS OF THE CONSISTENCY OF THE UNIVERSE, OR EVEN IF THIS STATEMENT WAS FALSE."), which would have very unfortunate consequences. This would be a major security breach, and would surpass even the threat of the DMCA, the MPAA, and even Microsoft.
Unfortunately, being inconsistent means that any outcome can follow. Therefore, being inconsistent is the only viable course of action from the business point of view. It is therefore actually likely that the profets could be right, whatever they say. This is just one of the paradoxes of the universe.
--
rec x.x -> _|_.
That article is very funny. First, it presents many alleged myths of OOP. Sure, these are very well myths from 70's, I guess there have once been people with such beliefs.
The author seems to confuse OO with some other programming techniques. What does OOP have to do with garbage collection, multimedia, OODBMS, visual programming, or even taxonomies or modelling the real world? These are all part of what programmers need to deal with, but none of them are OOP. So at minimum, blaming OOP for this is seriously misplaced.
The article also confuses and mixes object oriented _modelling_, object oriented _analysis_ and object oriented _programming_ with implementation mechanisms used commonly in major programming languages (e.g. C++). Look at some differently designed programming languages (e.g. Haskell), and you see that none of the assumptions made in that article are valid.
There is the concept of modelling the real world in object oriented _analysis_ (OOA), but even there, the article fails to reveal any insight on the problems people are having with modelling. In reality, no analysis method currently available does adequate job in modelling the real world. Nor are they intended to attain the impossible.
The concepts that programmers are modelling are more complex than many people think. However, mostly all the analysis machinery is exactly the same whether one uses OO methods or any other modelling technology. All analysis methods focus on finding the relevant pieces of information, and creating a simplified model that reflects it. Different modeling techniques make different simplifications. Then the software is written to assume this idealized reality.
The most common problem with modelling is that there are too many things that are simply *unknown*. Good software designers can identify concepts or constraints that are not well known, and reflect this uncertainty in the model by introducing flexibility. How this flexibility is provided is not important. Polymorphism (and not inheritance) is one tool provided by OO to doing this. Asking for user input for the unknown things is another (non-OO way).
In contrast, the article attacks inheritance because it uses a hierarchy. This is just silly. I was not surprised at the references to communism.
A protection process for a technology, product, service, device, component or part thereof, that comprises the steps of:
a) circumventing a technological measure that effectively controls access to a protected work,
b) limiting the commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a protected work,
c) marketing the technological measure for use in circumventing a technological measure that effectively controls access to a protected work
I think Guillaume's nice discussion about some of the drawbacks of Gtk-- mixed memory management policy is fine as far as it goes, but I would like to add some points.
First, there are really many alternatives to choose to decide what kind of memory management to use for a C++ program. Telling is that the C++ standardization committee could only agree on one memory management class (auto_ptr<>). It uses gross hacks for ensuring the type checker does the right thing (And I'm not convinced it's right as it is).
Ok, to get to my real point, here is a list of all memory management policies I could remember having seen used in C++:
1) explicit deallocation (programmer responsible for deleting; e.g. C++ plain pointers)
2) strict ownership (e.g. a creation function returning a smart pointer )
3) transferrable ownership (e.g. auto_ptr)
4) Stack (objects created first are deleted last)
5) Static allocation (memory for object always exists)
6) no deallocation (sometimes you just can leave memory as leaks)
7) garbage collection (The garbage collector takes care of deallocation)
8) Cluster allocator (see "Ruminations on C++" by Andrew Koenig; basically objects are deallocated in clusters, and whenever the cluster is deallocated, all the objects in it are deallocated as well).
9) reference counting with explicit ref/unref.
10) Intrusive reference counting (the objects being pointed to contain a reference count)
11) Non-intrusive reference counting (the reference count is separate from the object, e.g. like boost shared_ptr template)
12) Handle-Body idiom (you write a specialized handle for managing memory for your class)
13) Container-managed (like Gtk-- manage())
14) Containment (like Gtk-- containment based solution)
15) Library-owned objects (library only returns references without ownership to users)
16) Distributed garbage collection
17) Evictor (the objects are maintained in a fixed size array, and the least used objects are deleted when new objects are created that would o verflow the array When the object is next needed after being deleted, it's re-created).
18) Copy semantics (you always do a copy)
19) Lazy copy semantics (you make a copy when you have to)
20) Reaper (The memory is scanned at fixed intervals for freed-up objects, and any objects marked to be deleted are freed).
21) Shared memory allocation
22) Persistent allocation (You mmap() some disk space for your objects, and leave it there to allow it to be used on subsequent invocations of your program)
23) Class allocator (overloading operator new and operator delete for allocating small objects efficiently)
24) Self-managed allocation (the object deallocates itself)
25) Singleton (The object is allocated when it's first used, and deallocated at the end of the program)
26) Mixture of several of the above policies
The design space for memory allocation of C++ objects is really HUGE. So it's no wonder there is some disagreement on what is the preferred way to handle memory management, especially as many of these alternatives are actually contradictory in that it is hard to combine many of these strategies.
I personally prefer auto_ptr combined with a non-intrusive reference counted pointer class and creation functions that return memory wrapped in auto_ptr. You do need some solution for putting references to objects in containers, plain auto_ptr doesn't work for that.
One good way of minimizing vendors blaming each other is making sure your product works with components from at least two vendors. Then you can always substitute the faulty component of the package, and tell the vendor whose software faulted that "when I replace this with , the problem does not occur". Sometimes it's enough that you support several versions of the same vendor's product, but for best results, you need to support different vendors' products.
For some reason, it seems that when you tell a vendor that you are readily able to replace their software with someone else's, they respond much better to requests for support.
The same works other way around too. If you have vendors blaming each other, you just need to replace one of the components with something else, and you are able to say the problem was or was not corrected by replacing that component.
If none of this is possible for your product, then the only real alternative is to prove your point by producing a test driver that only uses one of the products [again replacing other products with something else], but is still able to reproduce the problem.
I think when BBoM says: "[Foote&Yoder 1998a] went so far as to observe that inscrutable code, in fact, have a survival advantage over good code, by virtue of being difficult to comprehend and change."
This must be the reason for all the crap code in the world. But it also assumes _great_ code does not exist. Great code probably has even better survival advantage, by virtue of not needing any change. I once thought that all code needed to change, if the requirements for that portion of code change. But that is *not* true, great code does not need to change, even after your requirements change. Great code may be phased out of use after significant changes in requirements, but it does not need to change.
Now then the Dilbert-style managers enter the picture, and all hope is lost. They take the great code, look at how long it has taken to develop the thing, and decide it must be crap since the last project used a lot of time to develop and enhance it. Then they discard it and REWRITE it in the inscrutable way.
Then someone says software is not doomed to failure. How many organisations do you know that had both the great management and the great architects?
Now, the *obvious* solution is to get rid of managers. Then you have already solved half the problem, and only need to find good architects.:-). Now consider open source. The success of open source is directly related to whether you find good architects to write the code. The difficulties in marketing open source are due to its greatest virtue, not having managers and strict time schedules to keep. However, the managers are needed to make the software work in commercial setting. Now, how to solve the software crisis then? Well, you can't give all the answers in one slashdot posting, now can you?
Slashdot Mirror
It seems even Maureen O'Gara thinks the article was not true:
( http://www.linuxworld.com/story/46800_f.htm)
"Maureen O'Gara commented on 23 October 2004:
* I'm really sorry everyone. I want you all to know that this was really intended as a satire piece, but the editors didn't realise and have published it as fact.
It was really hard to keep a straight face while writing it, and I was obviously hoping for the same reaction from my readers.
Oh, the ads here are satire too. Have you read the M$ TCO one? It's a hoot!"
So I think there is nothing to see here.
I first read the title as "Alan Cox is writing better software", and thought that finally he's doing that :-) Then I realized my mistake and was disappointed.
I can't believe nobody mentioned Tron.
I think this whole dispute is not necessary. It's just a simple case of conflicting goals. One side wants "efficiency" and another wants "extensibility". What both sides miss is that real systems can't afford to choose just one of these, you have to get both. So you have to have just enough extensibility to allow reasonable extensions, and still attain reasonable levels of efficiency. But trying to get all of either thing will totally lose the game. So the XML camp is wrong to think that extensibility is everything (ever tried parsing XML in a real-time system?). And the "binary transfer format" camp is wrong to think efficiency is everything (ever tried to make two versions of your protocols to interoperate?).
I think the article missed a subtle point. Open source is a developer-created phenomenon. Open source software is normally written for some real use. That is, we need the software we write. Sometimes it's only written to be able to understand how software engineering works [students]. Now that's the reason there are a gazillion of different IRC clients/bots, for some reason, many students seem to like IRC and want to understand how such "cool" technology works, so they write IRC clients/bots or whatever is the latest fad. Sometimes we write software because we hate the existing alternatives and want to improve the situation, and the current state of affairs is causing headache. This is why most open source software is intended for developer use only, it's developers writing software for ourselves.
Sometimes the reason is that there is no alternative available, but you need it. But more often, the reason is convenience. It's often easier to write some small utility yourself than try to use any existing solution or commercial package for it [not to mention it costs less]. I would view this as a failure of the commercial marketplace for handling commodity software.
Now, of course, the article makes the correct point that usually we don't get any money from the software, even if we use lots of time writing it. Why is that? The reason is, it's not possible to distribute software commercially that doesn't have the critical mass, which would allow all the participants in the distribution chain to recover their costs, which means generating a steady revenue stream for a very long time. This is highly improbable for the kinds of software where open source is most successful. This means that if your software is not "good enough" for the commercial market, then you have only three choices:
1) Not distribute it at all beyond your friends
2) Start a company to sell it, and improve the software to "commercial grade" by using various funding mechanisms available in the marketplace.
3) Open source it
From this point of view, open sourcing those is the least risky way to approach the problem. Starting a company for your 1000 line utility isn't a good choice. Starting a company doesn't work, if you already have a job. Open sourcing is one way of getting access to a large pool of people who are willing to try your software out, and find problems in it before you cause yourself problems due to those bugs. Once your software reaches the critical mass, it's already been open source for so much time that it's not possible to revert it back [and it would be counter-productive]. Also, keeping the software for yourself has no point, if you know you can't finish it by yourself. And most people are not willing to contribute for a cause that doesn't help them [e.g. if your licensing only allows you to benefit from it].
I think this might change if there were ways to commercially publish, reuse and distribute small pieces of software without huge distribution costs. But this doesn't exist. Long time ago, shareware was thought to be a solution, but it proved not to work, because people are not willing to send money for some random software for which there is no way it could ever evolve past its primitive state due to the licensing hurdle needed to get the money. Open source really solves this problem well, this allows everyone to benefit, even if it's not in monetary units. Just having the software is more valuable than the money you could ever make from it.
Well of course, they are not trying to send light to that interstellar travel. To make your spaceship move faster than light, I guess the best bet is to try to slow the light to reasonable speeds, so that you can then more easily exceed that speed! And if exceeding the speed of light is the silver bullet of interstellar travel, I would say they're doing exactly the right thing!
1. You cannot apply a technological solution to a sociological problem (Edward's law) [everyone does this, consider the people who wrote MS Word]
e ationCommand()'?]
2. OO represents "real world"
[When did the real world start using 'CommandContainerFacade.getEventProducerFactoryCr
3. There is a magic product out there that solves all problems.
[yeah sure, maybe in million years!]
4. Methodology X is panacea. [see Usenet]
Also see Anti-patterns catalog for other examples.
There is no silver bullet, no magical solution, no instantaneous makes-my-problem-go-away widget that is all things to all problems.
:-)
But silver bullets do exist. Or what do you think they used to kill all those werewolves? But granted, it was a magical solution to a non-existent problem. I guess many solutions in the software industry follow this pattern. On the other hand, this is exactly what many people expect software to do.
It's much easier to sell magical solutions than those that actually work. Not many people get excited about software that just silently performs all the work. You need those small problems to ensure that the people in charge find out your product exists, so you can also sell them the next version.
1) Too much color.
2) Broken links
3) Empty popups for collecting two clicks per
user for advertisers.
4) IE-only pages as corporate intranet
5) Wiki pages that anyone can delete (and has!)
6) Wiki pages that nobody could change since 1998
7) Menus that take you to the same information you already saw on the main page
8) Frames
9) Unidirectional links (auto-refresh!)
10) Input fields with one line of text for entering your problem report
What? You had better share that insight with all of the commercial software vendors out there quickly before they go out of business! Make sure to include Microsoft, Oracle, IBM, etc...!
But Microsoft does not sell products. Microsoft sells licenses to products. The fact is that you cannot sell products in any business whose cost-structure is based primarily on R&D costs, since the market does not understand R&D costs. The market knows unit costs and tries to make products cost close to an ideal unit cost. Now for all R&D dominated businesses, this ideal unit cost is zero. This failure of the market, combined with a standard requirement for mass-market products, i.e. that your unit production time is less than 2 years, is a disaster for software. This time is intended to only cover the time it takes to find customers.
This is why most software businesses have to either sell licenses (which is a bad substitute) or build hardware whose unit costs are not zero, then bundle the software with the hardware. It's also the reason for the problems so many small software companies are having. The market is just not designed to be used in situations where you have to spend considerable amount of time for developing a product before you can sell anything. It assumes you can sell your product from day one, and that most costs are associated with making copies of the same simple design.
I would suggest everyone to run filters on the picture. In particular, you should run edge detect and sharpen filter on it. Gets nice detail on it.
Ok, everyone knew it but I claim that backward time travel is possible (in a sense) but cannot be observed. It is really simple to prove.
:-]
First, we have to understand time itself. My hypothesis is that time is an observation of irreversible processes. If a process is not irreversible, then going through that process will not get you forward in time [nor backward for that matter].
Obviously, it is possible to create a loop using just reversible processes [any two 'instances' of the same part of a reversible process are indistinguishable]. This means that any such loop would be confined in the same time. [Physicists actually observe such loops, a pair creation followed by annihilation is one such loop]. Note that this implies that time travel is really possible. What you do is you use pair creation to build two exactly similar objects, one from matter, another from antimatter. The antimatter version travels backwards in time [as observed by external observers made of ordinary matter], and the matter version travels forward. As long as you do not use irreversible processes, you can at some point annihilate those two versions, and have provided such a loop. However, to ensure that, you cannot observe that object (observation is irreversible!). You can however observe *parts* of such object, and all such observations will influence both 'copies' of the object [since it's actually the same object just observed from different locations!].
Now consider photons. How would you *ever* observe the 'same' photon at two different times? I would say you cannot have done that, because time doesn't pass for a photon! So if you consider a single photon, its creation (some atom emits the photon) and its destruction (absorption) occur at two adjacent units of time [from the point of view of the photon!]. The reason that the external world observes light to travel at high speed is because there are many irreversible processes in the observers, and those processes bring those observers away from (or towards) the stationary photon!
In contrast, consider the reversible process of a photon creating a electron-positron pair. A photon and the electron-positron pair are obviously interchangeable [since the process is reversible].
If you now observe the created electron, the electron has transformed into something that you cannot any more transform back to the original photon. Therefore, the positron that was left must also have changed 'at the same moment' [otherwise the process would be reversible]. So the 'next unit of time' for the positron must have been when the positron is destroyed (or observed), and this must occur at the same time as when the electron was destroyed. From this, you can determine that the directions and speed that the electron-positron pair start to travel on pair creation must be such that the destruction of the components of the pair occur 'simultaneously' [at next unit of time from the points of views of both the electron and the positron!].
This model also explains why time can pass in different speeds in different parts of the universe [some parts of universe just happen to be more suspectible for initiating irreversible processes]. So measuring time is a way of measuring the rate of change of entropy. In particular, any processes that only use reversible processes are observed to move at the speed of light. In effect, "moving at the speed of light" is the (only) way to not change at all. [Here, 'change' means that there is a state reachable from the initial state through a series of irreversible processes; obviously, you cannot refer to time when defining 'change'].
Then, according to this model, what is gravity? Acceleration of the gravity would be an artifact from the way that objects interact. In particular, it would be caused by (causal) interaction of objects whose time passes in different rate and the structure of those interactions. The difference in elapsed time between two interactions of the same pair of objects would be directly translated to corresponding observed acceleration between those objects [the conversion ratio is obviously the speed of light]. This explains why there is an approximate correlation between decay rate of particles and their mass.
Now, consider backward time travel in a way that you would actually be able to observe it. That would mean that your irreversible processes used to observe the information would start to reverse themselves! That is a contradiction.
[I hope nobody actually believes this
Most patent (applications) I know are written in an obscure variation of english, probably only known by lawyers. In particular, it seems that any applications are obscured by the lawyers to point where the experts in the area can hardly understand what's going on [or anyway, it's made unnecessarily hard to understand]. I'm wondering what is the reason for this, and what you think should be done to prevent it?
Hofstadter: Gödel, Escher, Bach, an Eternal golden braid
Gamma et. al: Design Patterns, Elements of Reusable OO software.
Abelson, Sussman: Structure and Interpretation of computer programs.
Lakos: Large scale C++ software design.
Barendregt: Lambda calculi with types. http://citeseer.nj.nec.com/barendregt92lambda.html
Sorensen: Lectures on the Curry-Howard isomorphism. http://citeseer.nj.nec.com/519604.html
Knuth: The art of computer programming. (all volumes)
Rumbaugh et. al: Object oriented modeling and design
Brown et. al: Antipatterns, Refactoring software, architectures and projects in crisis.
Hopcroft, Ullman: Introduction to automata theory, languages and computation.
Henning, Vinoski: Advanced CORBA Programming with C++.
McConnell: Code complete, A practical handbook of software construction
McConnell: Rapid developement, taming wild software schedules
Brooks: The mythical man-month.
Meyer: Object oriented software construction
Andrews: Concurrent programming, principles and practice.
Russel, Norvik: Artificial intelligence, a modern approach
Meyers: Effective C++, 50 specific ways to improve your programs and designs.
Meyers: More effective C++, 35 new ways to improve your programs and designs.
These were selected from about 60 different books.
See: http://www.nccusl.org/nccusl/UCITA-2001-comm-fin.h tm.
It has a report that discusses many aspects of UCITA.
You cannot be an architect unless you also implement, since it's impossible to design the architecture unless you know what happens inside the software. And you cannot get this knowledge without participating in the implementation. Therefore, there is no problem. The only thing is, there are higher hopes for you (in addition to the ordinary requirements for coders, you are also expected to actually design the system!) It's just more responsibility. Nothing else changes!. See the Architect also implements (http://www.bell-labs.com/user/cope/Patterns/Proce ss/section16.html) software process pattern for a detailed overview.
> That all depends on if He planned for
> the universe to ever exit().
> We will need to consult the prophets
> to find the answer.
But the profets cannot do that. Since the type of exit is "integer -> _|_", and you cannot ever have objects of type _|_ unless the universe is inconsistent, you can never observe an invocation to exit. Since it is also impossible to determine whether an arbitrary creation is semantically equivalent to a given another creation, you cannot even reliably find a valid example of exit. Therefore, there are no means which the profets could use to determine whether the universe incorporates the exit semantics.
Of course, this is fine. If the profets could find an implementation of exit, this would immediately reduce the universe to an instance of _|_ (not least due to the profets just accidentally using the button labelled "BEWARE, IN NO SITATION SHOULD THIS BUTTON BE PRESSED, OR THIS UNIVERSE WILL CEASE TO EXIST. PROCEED ONLY AT YOUR OWN PERIL. THE MANUFACTURER OF THIS BUTTON CANNOT BE HELD RESPONSIBLE FOR ANY ACTIONS TAKEN BY USERS OF THIS BUTTON, EVEN IF IT WOULD RESULT IN LOSS OF THE CONSISTENCY OF THE UNIVERSE, OR EVEN IF THIS STATEMENT WAS FALSE."), which would have very unfortunate consequences. This would be a major security breach, and would surpass even the threat of the DMCA, the MPAA, and even Microsoft.
Unfortunately, being inconsistent means that any outcome can follow. Therefore, being inconsistent is the only viable course of action from the business point of view. It is therefore actually likely that the profets could be right, whatever they say. This is just one of the paradoxes of the universe.
--
rec x.x -> _|_.
That article is very funny. First, it presents many alleged myths of OOP. Sure, these are very well myths from 70's, I guess there have once been people with such beliefs.
The author seems to confuse OO with some other programming techniques. What does OOP have to do with garbage collection, multimedia, OODBMS, visual programming, or even taxonomies or modelling the real world? These are all part of what programmers need to deal with, but none of them are OOP. So at minimum, blaming OOP for this is seriously misplaced.
The article also confuses and mixes object oriented _modelling_, object oriented _analysis_ and object oriented _programming_ with implementation mechanisms used commonly in major programming languages (e.g. C++). Look at some differently designed programming languages (e.g. Haskell), and you see that none of the assumptions made in that article are valid.
There is the concept of modelling the real world in object oriented _analysis_ (OOA), but even there, the article fails to reveal any insight on the problems people are having with modelling. In reality, no analysis method currently available does adequate job in modelling the real world. Nor are they intended to attain the impossible.
The concepts that programmers are modelling are more complex than many people think. However, mostly all the analysis machinery is exactly the same whether one uses OO methods or any other modelling technology. All analysis methods focus on finding the relevant pieces of information, and creating a simplified model that reflects it. Different modeling techniques make different simplifications. Then the software is written to assume this idealized reality.
The most common problem with modelling is that there are too many things that are simply *unknown*. Good software designers can identify concepts or constraints that are not well known, and reflect this uncertainty in the model by introducing flexibility. How this flexibility is provided is not important. Polymorphism (and not inheritance) is one tool provided by OO to doing this. Asking for user input for the unknown things is another (non-OO way).
In contrast, the article attacks inheritance because it uses a hierarchy. This is just silly. I was not surprised at the references to communism.
For *really* good information, see: Portland pattern repository, or any bibliography server (e.g. NEC Research index)
A protection process for a technology, product, service, device, component or part thereof, that comprises the steps of:
a) circumventing a technological measure that effectively controls access to a protected work,
b) limiting the commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a protected work,
c) marketing the technological measure for use in circumventing a technological measure that effectively controls access to a protected work
I think Guillaume's nice discussion about some of the drawbacks of Gtk-- mixed memory management policy is fine as far as it goes, but I would like to add some points.
First, there are really many alternatives to choose to decide what kind of memory management to use for a C++ program. Telling is that the C++ standardization committee could only agree on one memory management class (auto_ptr<>). It uses gross hacks for ensuring the type checker does the right thing (And I'm not convinced it's right as it is).
Ok, to get to my real point, here is a list of all memory management policies I could remember having seen used in C++:
1) explicit deallocation (programmer responsible for deleting; e.g. C++ plain pointers)
2) strict ownership (e.g. a creation function returning a smart pointer )
3) transferrable ownership (e.g. auto_ptr)
4) Stack (objects created first are deleted last)
5) Static allocation (memory for object always exists)
6) no deallocation (sometimes you just can leave memory as leaks)
7) garbage collection (The garbage collector takes care of deallocation)
8) Cluster allocator (see "Ruminations on C++" by Andrew Koenig; basically objects are deallocated in clusters, and whenever the cluster is deallocated, all the objects in it are deallocated as well).
9) reference counting with explicit ref/unref.
10) Intrusive reference counting (the objects being pointed to contain a reference count)
11) Non-intrusive reference counting (the reference count is separate from the object, e.g. like boost shared_ptr template)
12) Handle-Body idiom (you write a specialized handle for managing memory for your class)
13) Container-managed (like Gtk-- manage())
14) Containment (like Gtk-- containment based solution)
15) Library-owned objects (library only returns references without ownership to users)
16) Distributed garbage collection
17) Evictor (the objects are maintained in a fixed size array, and the least used objects are deleted when new objects are created that would o verflow the array When the object is next needed after being deleted, it's re-created).
18) Copy semantics (you always do a copy)
19) Lazy copy semantics (you make a copy when you have to)
20) Reaper (The memory is scanned at fixed intervals for freed-up objects, and any objects marked to be deleted are freed).
21) Shared memory allocation
22) Persistent allocation (You mmap() some disk space for your objects, and leave it there to allow it to be used on subsequent invocations of your program)
23) Class allocator (overloading operator new and operator delete for allocating small objects efficiently)
24) Self-managed allocation (the object deallocates itself)
25) Singleton (The object is allocated when it's first used, and deallocated at the end of the program)
26) Mixture of several of the above policies
The design space for memory allocation of C++ objects is really HUGE. So it's no wonder there is some disagreement on what is the preferred way to handle memory management, especially as many of these alternatives are actually contradictory in that it is hard to combine many of these strategies.
I personally prefer auto_ptr combined with a non-intrusive reference counted pointer class and creation functions that return memory wrapped in auto_ptr. You do need some solution for putting references to objects in containers, plain auto_ptr doesn't work for that.
One good way of minimizing vendors blaming each other is making sure your product works with components from at least two vendors. Then you can always substitute the faulty component of the package, and tell the vendor whose software faulted that "when I replace this with , the problem does not occur". Sometimes it's enough that you support several versions of the same vendor's product, but for best results, you need to support different vendors' products.
For some reason, it seems that when you tell a vendor that you are readily able to replace their software with someone else's, they respond much better to requests for support.
The same works other way around too. If you have vendors blaming each other, you just need to replace one of the components with something else, and you are able to say the problem was or was not corrected by replacing that component.
If none of this is possible for your product, then the only real alternative is to prove your point by producing a test driver that only uses one of the products [again replacing other products with something else], but is still able to reproduce the problem.
I think when BBoM says:
:-). Now consider open source. The success of open source is directly related to whether you find good architects to write the code. The difficulties in marketing open source are due to its greatest virtue, not having managers and strict time schedules to keep. However, the managers are needed to make the software work in commercial setting. Now, how to solve the software crisis then? Well, you can't give all the answers in one slashdot posting, now can you?
"[Foote&Yoder 1998a] went so far as to observe that inscrutable code, in fact, have a survival advantage over good code, by virtue of being difficult to comprehend and change."
This must be the reason for all the crap code in the world. But it also assumes _great_ code does not exist. Great code probably has even better survival advantage, by virtue of not needing any change. I once thought that all code needed to change, if the requirements for that portion of code change. But that is *not* true, great code does not need to change, even after your requirements change. Great code may be phased out of use after significant changes in requirements, but it does not need to change.
Now then the Dilbert-style managers enter the picture, and all hope is lost. They take the great code, look at how long it has taken to develop the thing, and decide it must be crap since the last project used a lot of time to develop and enhance it. Then they discard it and REWRITE it in the inscrutable way.
Then someone says software is not doomed to failure. How many organisations do you know that had both the great management and the great architects?
Now, the *obvious* solution is to get rid of managers. Then you have already solved half the problem, and only need to find good architects.