Thanks for the insight. I guess that sense of tension (for me, at least) just leads to frustration, which eventually leads to discovery and annoyance. It's much worse on the second (or later) attempt!
it gives you the time to think out a strategy to the situation at hand
But basically my strategy is "okay, I'm creeping to the next shadow...slowly." It's not like I've got my astrolabe and star chart out, planning a clever assault on the fleet. I'm just walking, and walking is boring. Right?
I find games in the "stealth" genre excruciatingly boring. It's not because I don't like the idea of hiding or sneaking up on people and killing them and stealing there stuff. It's because the games are always so slow. What do you guys do in all that time it takes you to creep frome one shadow to another? Ponder the mysteries of the universe? Play another game at the same time?
You can't "take" the code from their servers, though. It's just impossible. The closest you could do is to make a copy, and then erase the original.
Copying is different from theft/stealing/larceny both legally and ethically. It's fine to have opinions as to whether it is or should be right/wrong legal/illegal. But lumping it in with stealing is just misleading, and that is not a fair way to present your case.
Of course, this is worse than copyright infringement, as it is misappropriation of trade secrets, which--presuming it is done for economic benefit--is actually a crime.
"... but if a Hafnium bomb could be built, it is thought that a golf ball sized chunk could produce the energy equivalent of 10 tons of conventional explosives."
Well, damn, we had better get our best minds on that one !!
You're probably the same guy that thought it was "ridiculous" that an average computer would need graphics at all in 1980. After all, the average consumer does little more than operate a text mode word procecssor and dial bulletin board systems.
Seriously, more powerful computers means the ability to do more than what the average user can do today. And then the average user will want to do those things.
Any application that can tolerate garbage collection is trivial. Thanks anyway -- I'll stick to C and assembly.
Wow, with this attitude I can see why you are worried about keeping your job. Did you know that GCC uses a garbage collector? They found it too difficult to manually manage memory. Is GCC a trivial application? In my program we write loads of decidedly non-trivial software all of the time that not only tolerates, but benefits greatly from GC.
Garbage collection is not appropriate for every task, but to assert that all tasks worth doing demand C and assembly is ridiculous.
The implementation of higher order functions as closures does not require garbage collection, if you are willing to leak memory. The same exact issue comes up whenever someone returns an allocated object from a function in Java or C. The creation of a closure is an allocation of an object (which may copy values from the current stack frame into it), but the stack frame still goes away when you leave it, as do the local variables.
You seem to have a mistaken impression of the way functional languages are implemented.
On top of that, I don't see why we'd even bother talking about an implementation where we leak memory indefinitely.
A friend of mine did his thesis on a Garbage Collector that is parallell, concurrent, real-time and (mostly) tagless. We have it running in a real compiler. (Here's a later paper he wrote.) So real-time GC is absolutely possible.
How about one of the earlier comments to the effect that mark-and-sweep type algorithms page-faults all the memory used by an application?
Not all garbage collectors are mark-and-sweep. Also, copying GCs have much better fragmentation than malloc, so if you're concerned about keeping the working set small, a copying GC is absolutely the way to go.
Using this technique for memory management comes from "regions," which are a kind of statically checked manual memory management system. Regions are good for some kinds of programs (and are easy to check), but often the lifetime of an object is not determined statically. If this is your only resource management strategy, it will be too restrictive to write many programs.
Any language with higher order functions (which you are calling "closures"--an implementation strategy for higher order functions) can implement this. It's an idiom I sometimes use in ML and elisp has had it for a long time (ie, save-excursion); no doubt it's older than me, even.
Anybody who thinks languages like Haskell or ML are fundamentally more powerful than C++ must be unaware of the Boost Lambda library, and of FC++, a set of header files that implements Haskell language semantics for C++ programs. They get along fine without GC, as well.
If you like your memory management to be by reference counting, then they "get along fine without GC." But reference counting is an inefficient way to do memory management.
Also, I actually believe that copying garbage collection can be good for cache locality, since it can compact the heap to put long lived objects near each other. This is not easy in C++. Of course, this argument needs to be levelled against each GC implementation individually.
You are absolutely right about the inability for GC to work well with other kinds of resources, however. On the other hand, most languages let you manually manage non-memory resources, so I don't see how the situation is better in C++ except that programmers are already used to doing it with memory.
We also could have spared ourselves the computer-months of CPU time and just computed the computational cost using a few miliseconds of calculator time.
The only time such an exercise is successful is when a new code-breaking technique is developed to solve the problem, not when brute force wins.
Just make an electromagnet (coil of wire) with a permanent magnet on a rod attached elastically within it. The rod will move in and out as different voltages are applied to the electromagnet. If you apply a crappy paper cone, you might even get it to make sound.
Slashdot Mirror
The operating system should be called... CunnilingOS.
What about the post-9/11arian epoch? If we don't have it, then the terrorists have already won.
Thanks for the insight. I guess that sense of tension (for me, at least) just leads to frustration, which eventually leads to discovery and annoyance. It's much worse on the second (or later) attempt!
it gives you the time to think out a strategy to the situation at hand
But basically my strategy is "okay, I'm creeping to the next shadow...slowly." It's not like I've got my astrolabe and star chart out, planning a clever assault on the fleet. I'm just walking, and walking is boring. Right?
I find games in the "stealth" genre excruciatingly boring. It's not because I don't like the idea of hiding or sneaking up on people and killing them and stealing there stuff. It's because the games are always so slow. What do you guys do in all that time it takes you to creep frome one shadow to another? Ponder the mysteries of the universe? Play another game at the same time?
You can't "take" the code from their servers, though. It's just impossible. The closest you could do is to make a copy, and then erase the original.
Copying is different from theft/stealing/larceny both legally and ethically. It's fine to have opinions as to whether it is or should be right/wrong legal/illegal. But lumping it in with stealing is just misleading, and that is not a fair way to present your case.
Of course, this is worse than copyright infringement, as it is misappropriation of trade secrets, which--presuming it is done for economic benefit--is actually a crime.
I totally agree. That's not even a good scam. What makes you think they'd have 3000 year old rings?
... or can you?!?
This game was lovely in two dimensions. I'm all for upgrading the graphics and engine for modern hardware, but why make it 3D??
You are right, but not only relational...the future is object-oriented databases. ... implemented in XML.
Infinium is concerned about protecting its IP and its consumers.
Right... those mod chips have a way of crawling into your home and installing themselves, ruining your valuable data. Better protect the consumers!
"... but if a Hafnium bomb could be built, it is thought that a golf ball sized chunk could produce the energy equivalent of 10 tons of conventional explosives."
Well, damn, we had better get our best minds on that one !!
Yeah, but does the human "biologic brain" run at a blistering 10kHz? I don't think so!!
You're probably the same guy that thought it was "ridiculous" that an average computer would need graphics at all in 1980. After all, the average consumer does little more than operate a text mode word procecssor and dial bulletin board systems.
Seriously, more powerful computers means the ability to do more than what the average user can do today. And then the average user will want to do those things.
Any application that can tolerate garbage collection is trivial. Thanks anyway -- I'll stick to C and assembly.
Wow, with this attitude I can see why you are worried about keeping your job.
Did you know that GCC uses a garbage collector? They found it too difficult to manually manage memory. Is GCC a trivial application?
In my program we write loads of decidedly non-trivial software all of the time that not only tolerates, but benefits greatly from GC.
Garbage collection is not appropriate for every task, but to assert that all tasks worth doing demand C and assembly is ridiculous.
The implementation of higher order functions as closures does not require garbage collection, if you are willing to leak memory. The same exact issue comes up whenever someone returns an allocated object from a function in Java or C. The creation of a closure is an allocation of an object (which may copy values from the current stack frame into it), but the stack frame still goes away when you leave it, as do the local variables.
You seem to have a mistaken impression of the way functional languages are implemented.
On top of that, I don't see why we'd even bother talking about an implementation where we leak memory indefinitely.
A friend of mine did his thesis on a Garbage Collector that is parallell, concurrent, real-time and (mostly) tagless. We have it running in a real compiler. (Here's a later paper he wrote.) So real-time GC is absolutely possible.
How about one of the earlier comments to the effect that mark-and-sweep type algorithms page-faults all the memory used by an application?
Not all garbage collectors are mark-and-sweep. Also, copying GCs have much better fragmentation than malloc, so if you're concerned about keeping the working set small, a copying GC is absolutely the way to go.
Using this technique for memory management comes from "regions," which are a kind of statically checked manual memory management system. Regions are good for some kinds of programs (and are easy to check), but often the lifetime of an object is not determined statically. If this is your only resource management strategy, it will be too restrictive to write many programs.
Any language with higher order functions (which you are calling "closures"--an implementation strategy for higher order functions) can implement this. It's an idiom I sometimes use in ML and elisp has had it for a long time (ie, save-excursion); no doubt it's older than me, even.
Anybody who thinks languages like Haskell or ML are fundamentally more powerful than C++ must be unaware of the Boost Lambda library, and of FC++, a set of header files that implements Haskell language semantics for C++ programs. They get along fine without GC, as well.
If you like your memory management to be by reference counting, then they "get along fine without GC." But reference counting is an inefficient way to do memory management.
Also, I actually believe that copying garbage collection can be good for cache locality, since it can compact the heap to put long lived objects near each other. This is not easy in C++. Of course, this argument needs to be levelled against each GC implementation individually.
You are absolutely right about the inability for GC to work well with other kinds of resources, however. On the other hand, most languages let you manually manage non-memory resources, so I don't see how the situation is better in C++ except that programmers are already used to doing it with memory.
We now know what the computational cost was...
We also could have spared ourselves the computer-months of CPU time and just computed the computational cost using a few miliseconds of calculator time.
The only time such an exercise is successful is when a new code-breaking technique is developed to solve the problem, not when brute force wins.
Suing innovators over overly broad patents is not cool, Gamer Dad.
Just make an electromagnet (coil of wire) with a permanent magnet on a rod attached elastically within it. The rod will move in and out as different voltages are applied to the electromagnet. If you apply a crappy paper cone, you might even get it to make sound.
C is not the only programming language that works on linux. If it were, I sure as hell wouldn't use the OS.
Unsafe "optimizations" don't deserve to be called optimizations and should never be enabled by a tool like this.
Well, an easy way to fix it would be to use larger sequence numbers. (Deploying such a solution is another matter...)