This seems backwards; I'm missing something. Remember, I'm asking about Jupiter moving back out, not in toward the sun (which the article suggests is from friction with dust etc.). Other objects would have to lose orbital momentum for Jupiter to gain. Jup moving out would push the space junk inward, not outward.
The idea that Jupiter moved inwards then back out would have the back out movement come from flinging smaller planetoids out of their orbit and exchanging angular momentum.
But Jupiter is massively massive, to misuse English. It's hard to believe all those small asteroids and junk would have enough bulk and momentum to make a difference on it.
Was there a lot more junk flinging around back then? I don't get it.
Let me clarify. It may be "software engineering science" to study reasons existing code bases need changes (written in varied languages and paradigms), but as given, it is not OOP-specific science. The/. intro says "object-oriented computer science". That study is not "object-oriented computer science" because it doesn't split it up by paradigm (OOP versus procedural versus functional, etc). To me "object-oriented computer science" is measuring OOP's impact.
I do not believe there are ANY field studies in Meyer's book that show OOP "being better". You are welcome to prove me wrong.
Do you mean % of software devoted to maintenance? % devoted to "changing data formats"? I know later in the book he claims OOP wraps data formats and therefore allegedly reduces the impact of those on code. But those later arguments are spurious in my opinion when compared to the alternatives. Adapters can be made in any paradigm. And reducing that 18% slice may increase other slices. Either way, those 2 slices are not measures of OOP improvements.
Paul Graham partially credits Lisp for making him rich via his store-site start-up, despite having viable competitors. The company that bought him out eventually converted it to a more conventional language stack for day-to-day maintenance.
The best "lone wolf" developers probably use something like Lisp and a high amount of math-like abstraction to crank out vast amounts of features in a short time.
However, a good team programmer knows how OTHER typical programmers think and read code, and writes code that is easy for them to navigate, digest, and change. Team programming is more like authoring a good technical manual, not clever gee-whiz tricks.
No, it depends on the type and frequency of the changes. Some change patterns favor case lists and some favor sub-classing (in terms of fewest lines/blocks/modules that need to be changed). I don't believe one is inherently more common than another. Selecting the "best" solution requires knowledge and experience about the domain, and/or a good "horse sense" of domain analysis.
Predicting the future is never easy.
There are some other complexities to consider, such as if a set-oriented variation-on-a-theme becomes more appropriate than a hierarchy for modeling variation, but that's a long topic.
Your viewpoint is too idealistic in my opinion to result in a practical difference. You are fighting a personal war that nobody else is attending, tilting at windmills.
My two semi solutions are to put a ceiling on campaign contributions (which the current Supreme Court is against), and to have federal-level issue votes, not just representative votes.
Is it possible to use a big disk for both blocking light and for diffraction, per target object? That way both parties can be right. Win win. (Pardon me for sounding like a PHB there).
The weather agency should state it as a percent similar to rain forecasts. Example: "There is a 70% estimated probability that snow will reach more than 2 feet deep in City X" kind of thing. It's then understood there's a 30% chance the snow will be a bust.
Slashdot Mirror
The real Justin B crashes cars, and the Justin B app crashes phones.
This seems backwards; I'm missing something. Remember, I'm asking about Jupiter moving back out, not in toward the sun (which the article suggests is from friction with dust etc.). Other objects would have to lose orbital momentum for Jupiter to gain. Jup moving out would push the space junk inward, not outward.
I don't believe the expansion of the universe makes any notable difference on the scale of a solar system.
But Jupiter is massively massive, to misuse English. It's hard to believe all those small asteroids and junk would have enough bulk and momentum to make a difference on it.
Was there a lot more junk flinging around back then? I don't get it.
To get it to pass, rename it JobCreator++
Let me clarify. It may be "software engineering science" to study reasons existing code bases need changes (written in varied languages and paradigms), but as given, it is not OOP-specific science. The /. intro says "object-oriented computer science". That study is not "object-oriented computer science" because it doesn't split it up by paradigm (OOP versus procedural versus functional, etc). To me "object-oriented computer science" is measuring OOP's impact.
I do not believe there are ANY field studies in Meyer's book that show OOP "being better". You are welcome to prove me wrong.
Maybe what he really wants is logic programming, along Prolog's line.
Until..."I've been hacked! She has 3 green dicks! That I can live with, but not her looking like Kim Jong-Un now."
If you complain, we'll re-write it in Java and make it 30GB
Quantum chess, my favorite! Oh wait, that's the prenup fineprint
Do you mean % of software devoted to maintenance? % devoted to "changing data formats"? I know later in the book he claims OOP wraps data formats and therefore allegedly reduces the impact of those on code. But those later arguments are spurious in my opinion when compared to the alternatives. Adapters can be made in any paradigm. And reducing that 18% slice may increase other slices. Either way, those 2 slices are not measures of OOP improvements.
Toldja, 640 bytes otta be enough for anyone. -Gill Bates
I bet other civilizations failed to travel outside their star system because they devoted all their energy to trying to solve the Fermi Paradox.
Yes it is a form of "soft" censorship. So be it. We have to sacrifice some ideals to avoid living in a corporate waste-land. Tradeoffs tradeoffs.
What "works" for you or me doesn't necessarily scale to the rest of voters.
That's what they get for using double underscores in function names.
Paul Graham partially credits Lisp for making him rich via his store-site start-up, despite having viable competitors. The company that bought him out eventually converted it to a more conventional language stack for day-to-day maintenance.
The next probe will be Zombie 2.
The best "lone wolf" developers probably use something like Lisp and a high amount of math-like abstraction to crank out vast amounts of features in a short time.
However, a good team programmer knows how OTHER typical programmers think and read code, and writes code that is easy for them to navigate, digest, and change. Team programming is more like authoring a good technical manual, not clever gee-whiz tricks.
Indeed. My theory is that many of those mysterious gamma-ray bursts are civilizations earning a Galactic Darwin award.
"Hey look, we can create mini anti-black-holes in our la ~ ^ & [NO CARRIER]
No, it depends on the type and frequency of the changes. Some change patterns favor case lists and some favor sub-classing (in terms of fewest lines/blocks/modules that need to be changed). I don't believe one is inherently more common than another. Selecting the "best" solution requires knowledge and experience about the domain, and/or a good "horse sense" of domain analysis.
Predicting the future is never easy.
There are some other complexities to consider, such as if a set-oriented variation-on-a-theme becomes more appropriate than a hierarchy for modeling variation, but that's a long topic.
Your viewpoint is too idealistic in my opinion to result in a practical difference. You are fighting a personal war that nobody else is attending, tilting at windmills.
My two semi solutions are to put a ceiling on campaign contributions (which the current Supreme Court is against), and to have federal-level issue votes, not just representative votes.
Is it possible to use a big disk for both blocking light and for diffraction, per target object? That way both parties can be right. Win win. (Pardon me for sounding like a PHB there).
Will "AOL" be painted on the disk in huge letters?
Those damned Patriots under-inflated the snow machine!
The weather agency should state it as a percent similar to rain forecasts. Example: "There is a 70% estimated probability that snow will reach more than 2 feet deep in City X" kind of thing. It's then understood there's a 30% chance the snow will be a bust.