More to the point, good algorithm design will always trump compiler optimization tricks for sufficiently large inputs.
FTFY.
My heapsort will always beat your insertion sort on arrays over 1000 or so elements, no matter what language/compiler/optimization tactics are used.
Can I pick adversarial languages and element types? You get bash and [ (a.k.a. test ). Your language forks a new process for every comparison. Shouldn't be too difficult to beat.
When people write "C/C++", they usually mean "C and C++"
It's a bad habit that poisons your mind, because saying it enough may make you forget that it's not true. What appears to be lacking is an appropriate and popular term for the family of languages with similar characteristics. This is much like "Romance languages" vs. "Spanish/Italian": the former is universally recognized as a broad category, whereas anyone claiming fluency in the latter had damn better well be able to speak both languages.
... sometimes in release mode you don't want the software to destroy property or kill people just because of some little bug, which may or may not be important.
Sure, real-time control systems need to provide reasonable output regardless of any inputs. However, for most other systems I've found that "get out of dodge" is still the best answer. The top-level program can simply be run in a loop that says "re-execute program with an incrementing counter if it ever exits due to SIGABRT".
People used to worry about... page misses being slow...
Used to worry? Page misses will always matter. Memory subsystems may continually improve, but they are always competing with additional data: more media on websites, bigger caches for streamed content and TCP connections in general, higher-quality graphics and sounds in games, bigger standard shared libraries loaded, yadda yadda.
... aside from the efficiency gains of having at least some amount of buffer so as to not always be allocating/freeing directly to/from the OS (and I bet someone can optimize C++'s new/delete to do the same thing)...
This is already done, at least on Linux (and probably on other UNIXen). C++ new/delete delegates to the same "core" as C malloc/free (maybe not a direct call, but something like _int_malloc is the guts behind both). Those underlying functions only communicate with the operating system infrequently via the sbrk syscall.
I believe "large" allocations use a separate mechanism (mmap) which involves more OS interactions, but now you're getting into optimization of the virtual memory subsystem and other dark corners. You are likely to be eaten by a grue.
Have you really never needed, for example, a linked data structure that could form a cyclic graph?
I have. No single node was "responsible" for the memory of any other node, the links were merely associations. The graph was encapsulated in a single class which was responsible for cleaning up at the end.
In my opinion, this was a better design even if cycle-detecting GC had been available. The graph node traversal was about availability, not ownership.
Yes its true that C/C++ is generally faster than other languages, but when it comes to writing bug proof code, its not so good.
Well when you put it that way, it's not a surprise. C and C++ are different languages with different approaches for effectively achieving low error rates. If you approach them as a single "C/C++" language, you'll end up inheriting the weaknesses of both languages without likewise inheriting the strengths of either.
Instead the best we can do is tell the medical people not to try too hard to keep her alive. A really shitty situation which does not seem moral.
(assuming you are from the USA) I believe a large part of the problem with health care here is the social attitude that alive (in any mental state) is better than peacefully deceased. I'm sorry for your situation, and I'd like to cast my coin into "it's completely moral" pile.
GNU Developers (or devs that use GPL licenses) are probably Chaotic Good, because they're passionate on the principles of "Free Software".
The GPL requires strict enforcement in order to be meaningful. I would peg most GPL-favoring developers as lawful-something based on that alone. The good/evil axis is more about what the developers are doing with the code. For example, GPL'ed pacemaker software is more "obviously good" than GPL'ed pacemaker-interference software. I don't believe that "free software" is inherently good, it is just a legal construct that favors community over an individual. YMMV depending on your DM, of course.
IANAL, but AFAIK 'innocent' is never used in the US Justice System. So, if the government fails to prove he's guilty, then he is not guilty.
Just because the relevant legal minds were negative assholes doesn't mean everyone must be so. Let's just call him innocent and rejoice that there's still hope for our (my?) government.
people tend to handle intersection in a weird way.
FTFY
"Not guilty" intersects Innocent so "Not guilty" = Innocent
I have to admit that the bash side of my brain appreciates your quotation marks. In any case, I checked out Merriam-Webster to see what the real language nazis think about !guilty?=innocent, and they indicate that guilty is a near antonym of innocent, and not an exact antonym. That is the most heartwarming experience I have ever had with a dictionary.
Yeah, that sounded funny to me, too. I'm used to hearing people say "programming HTML", but claiming "algorithms are better than data formats" is just... nonsense all the way down!
On a Slashdot discussion, would you really want 50 different "Reply to This" forms to get loaded with each press of the "Get More Comments" button, all hidden with display:none until the user activates the "Reply to This" element above them?
I'm not sure why you're giving me an example of a situation where static forms are silly, as I had already indicated that sometimes they do have their place. However, my personal opinion on the matter of the Slashdot discussion system and forms is this:
I always open "Reply to This" in a new tab, to avoid losing my place in the existing thread. It's a mental context switch, so the physical switch of having two pages loaded at once makes sense to me.
Nothing is stopping/. developers from dynamically generating an iframe instead of a local DOM structure. From the browser's perspective, it's a separate page and gets its own form caching and whatnot, but from the user's perspective it can be seamless. I've been away from the tech for a few years, I don't know if <iframe> is still demonized or not.
Putting "Reply To This" on a separate page-load adds a little bit of resistance to knee-jerk comments, which I consider a good thing. Of course there is a balance with how much effort you want to ask a user to go through for posting, but I just don't see a big benefit to inline replies for a serious discussion. Maybe someone has done some research on whether this is a real effect or if it's just "common sense gone wrong", but I'll stay conservative on this side for the discussion system.
Overall,/.'s discussion UI has gotten worse for me over time (poor use of whitespace, unnatural behavior with back/forward buttons, inconsistent and unintuitive preferences). It's also obvious from my mobile phone that their design is not very "friendly" to alternate UAs. I don't exactly view them as a shining example for user experience or appropriate client-side scripting in the first place.
Navigating away from a page and then navigating back with the back button tends to lose data entered into a form if the form is created with DHTML (manipulation of the HTML DOM by script).
I'm sure there are a number of reasons why generating a form completely on the client side is the best solution. However, I'm equally sure that there are many situations where that form generation could be done on the server side with no client-side scripting (or at most css display tweaks to hide precomputed dynamic fields). Given the history of the WWW, I'm willing to bet that most developers are erring on the side of too much "ooh shiny" and not enough "it just fscking works".
Amen to that! I've had many arguments in the past over HTML 4.01 Strict vs. XHTML. My conclusion was that unless you're using inline SVG, MathML, or XSL-based stylesheets for a website (a terrible idea), there was no real benefit to advancing beyond 4.01 Strict. Things will probably eventually change with HTML5, but not if it's a moving target.
2 gigs of ram and 100 gigs of speedy ssd - if they threw that on it and just kept the gpu side the same, it would do wonders compared to todays consoles.
Just in case they listen to you, can I request that they do upgrade the GPU? Many games are rendered at lower-than-screen resolution, presumably because their graphics are limited by fill rate. They could all be rendered at-or-above screen resolution and downsampled to avoid aliasing, but that requires moar horsepower. That's a common argument against consoles from the PC gaming crowd.
It won't be the most powerful, but for many, it will be good enough.
And for the others, there will still be wired consoles outputting 3D images (or the generation's equivalent hack), spatial sound generation, and with ridiculously powerful physics engines. My point is that these consoles will always be more powerful than any portable equivalent or a multi-purpose device.
I think the root is more about testosterone and male gearheads than anything else (a perfectly valid market for gaming consoles, large TVs, blu-ray, surround sound, and pretty much anything else with a lot of wires coming out of it). Sure, maybe the Game Boy Super Advance 3x satisfies a large population, but the culture that has an XBox360 or PS3 and not a Wii or DSi now will still be alive in the future.
That's assuming that mobile phones don't become more powerful than consoles.
Why would anyone ever dream of developing a console that is weaker than a mobile phone? It has a better power source, better cooling possibilities, fewer space constraints, and fewer wireless communication requirements.
Slashdot Mirror
FTFY.
Can I pick adversarial languages and element types? You get bash and [ (a.k.a. test ). Your language forks a new process for every comparison. Shouldn't be too difficult to beat.
My point: constant factors matter.
It's a bad habit that poisons your mind, because saying it enough may make you forget that it's not true. What appears to be lacking is an appropriate and popular term for the family of languages with similar characteristics. This is much like "Romance languages" vs. "Spanish/Italian": the former is universally recognized as a broad category, whereas anyone claiming fluency in the latter had damn better well be able to speak both languages.
Sure, real-time control systems need to provide reasonable output regardless of any inputs. However, for most other systems I've found that "get out of dodge" is still the best answer. The top-level program can simply be run in a loop that says "re-execute program with an incrementing counter if it ever exits due to SIGABRT".
Used to worry? Page misses will always matter. Memory subsystems may continually improve, but they are always competing with additional data: more media on websites, bigger caches for streamed content and TCP connections in general, higher-quality graphics and sounds in games, bigger standard shared libraries loaded, yadda yadda.
This is already done, at least on Linux (and probably on other UNIXen). C++ new/delete delegates to the same "core" as C malloc/free (maybe not a direct call, but something like _int_malloc is the guts behind both). Those underlying functions only communicate with the operating system infrequently via the sbrk syscall.
I believe "large" allocations use a separate mechanism (mmap) which involves more OS interactions, but now you're getting into optimization of the virtual memory subsystem and other dark corners. You are likely to be eaten by a grue.
I have. No single node was "responsible" for the memory of any other node, the links were merely associations. The graph was encapsulated in a single class which was responsible for cleaning up at the end.
In my opinion, this was a better design even if cycle-detecting GC had been available. The graph node traversal was about availability, not ownership.
Time well spent, my friend.
Well when you put it that way, it's not a surprise. C and C++ are different languages with different approaches for effectively achieving low error rates. If you approach them as a single "C/C++" language, you'll end up inheriting the weaknesses of both languages without likewise inheriting the strengths of either.
That sounds like a reference to one of his own works! If not, good job. If so, which?
(assuming you are from the USA) I believe a large part of the problem with health care here is the social attitude that alive (in any mental state) is better than peacefully deceased. I'm sorry for your situation, and I'd like to cast my coin into "it's completely moral" pile.
The GPL requires strict enforcement in order to be meaningful. I would peg most GPL-favoring developers as lawful-something based on that alone. The good/evil axis is more about what the developers are doing with the code. For example, GPL'ed pacemaker software is more "obviously good" than GPL'ed pacemaker-interference software. I don't believe that "free software" is inherently good, it is just a legal construct that favors community over an individual. YMMV depending on your DM, of course.
You must fall from grace a lot! I would expect a proper paladin to at least attempt to rehabilitate lulzsec before resorting to confinement.
Pin the tail on the whistleblower?
Just because the relevant legal minds were negative assholes doesn't mean everyone must be so. Let's just call him innocent and rejoice that there's still hope for our (my?) government.
FTFY
I have to admit that the bash side of my brain appreciates your quotation marks. In any case, I checked out Merriam-Webster to see what the real language nazis think about !guilty?=innocent, and they indicate that guilty is a near antonym of innocent, and not an exact antonym. That is the most heartwarming experience I have ever had with a dictionary.
Yeah, that sounded funny to me, too. I'm used to hearing people say "programming HTML", but claiming "algorithms are better than data formats" is just... nonsense all the way down!
I'm not sure why you're giving me an example of a situation where static forms are silly, as I had already indicated that sometimes they do have their place. However, my personal opinion on the matter of the Slashdot discussion system and forms is this:
I'm sure there are a number of reasons why generating a form completely on the client side is the best solution. However, I'm equally sure that there are many situations where that form generation could be done on the server side with no client-side scripting (or at most css display tweaks to hide precomputed dynamic fields). Given the history of the WWW, I'm willing to bet that most developers are erring on the side of too much "ooh shiny" and not enough "it just fscking works".
Oh dear, please tell me that "no rounded borders on a non-public form" was never an actual deal-breaker.
Amen to that! I've had many arguments in the past over HTML 4.01 Strict vs. XHTML. My conclusion was that unless you're using inline SVG, MathML, or XSL-based stylesheets for a website (a terrible idea), there was no real benefit to advancing beyond 4.01 Strict. Things will probably eventually change with HTML5, but not if it's a moving target.
Just in case they listen to you, can I request that they do upgrade the GPU? Many games are rendered at lower-than-screen resolution, presumably because their graphics are limited by fill rate. They could all be rendered at-or-above screen resolution and downsampled to avoid aliasing, but that requires moar horsepower. That's a common argument against consoles from the PC gaming crowd.
And for the others, there will still be wired consoles outputting 3D images (or the generation's equivalent hack), spatial sound generation, and with ridiculously powerful physics engines. My point is that these consoles will always be more powerful than any portable equivalent or a multi-purpose device.
I think the root is more about testosterone and male gearheads than anything else (a perfectly valid market for gaming consoles, large TVs, blu-ray, surround sound, and pretty much anything else with a lot of wires coming out of it). Sure, maybe the Game Boy Super Advance 3x satisfies a large population, but the culture that has an XBox360 or PS3 and not a Wii or DSi now will still be alive in the future.
No I haven't! I suppose that answers my question.
Why would anyone ever dream of developing a console that is weaker than a mobile phone? It has a better power source, better cooling possibilities, fewer space constraints, and fewer wireless communication requirements.
I'm pretty sure that's a dolphin, actually... OK, so maybe their algorithm isn't perfect yet ^_^