You're the one doing the asserting that a falsifiable statement *is* required for science. I'm not required to prove a negative.

It is not and never has been a requirement for science. It's a belief of the philosopher Karl Popper, and nothing more.

The first smartphone was the Nokia Communicator. 1996.

So you keep incorrectly saying. Karl Popper did not define science.

"less talk, more experimental proof"

Where's yours?

So you plagiarize too?

..and by asking those questions you've trashed the original question.. so when the person asking does know their stuff the end result of your involvement is that you just fucked their thread over. At the very very best you've delayed any meaningful response by literally days because now everyone else is waiting for you to be answered.

Day 1, you ask: "Have you tried to [blah blah] your [woo hoo]?"

Day 2, you ask "Have you gotten all the latest [goo mo]?""

Finally day 4 or 5 comes around and you finally admit that you can't help (something you actually knew on day 1), but now the thread is pushed down, off everyones radar, and is filled with complete crap initiated by you. All because when you didn't know the answer, you decided that you must get involved anyways.

Do everyone in the world a favor and don't get involved when you don't know the answer. Don't pretend to be more than you are. The feel-good moment you get when you click "post" is a sham - you are harming the other person, not helping them.

Its stated quite specifically already so when you then go and ask that, you are of course doing exactly what I said you would do, proving my initial response that it really isn't helpful to describe in excruciating detail what is being tried.

The important specifics are already there: I need my generic class library to enforce a constructor contract on 3rd party code that calls my library.

Maybe you imagine that there isnt a need for it, but thats just proving the GPPP's point also.. that you think you know what other people need better than they do.

So you just proved us both right, showing that literally everyone else in the world would be better off if you didnt open your mouth when you dont know the answer but want to fish for a different question that you actually can answer (which is just self serving shit, harmful to the discussion as signal to noise goes righrt into the toilet .. your the noise.)

i was the proud owner of a Gravis UltraSound, but "potential" isnt what it had.


The GF1 and later GF2 chips were basically the END of an era, not the "potential" beginning of one. By the time the Pentium rolled in, software mixing of 32 channel 16-bit stereo with 32-bit internal mixing was down to single-digit percentages of CPU power.

MSDOS users simply didnt notice what was going on elsewhere. The Gravis was much better than an SB16 for sure, but the SB16 was just a 16-bit stereo DAC packaged together with a Yamaha OPL3 FM synthesis chip, so the bar in the DOS world was set so low that when the DOS world finally caught up with the times it looked like innovation to DOS users but was actually just the final incremental improvements to what clearly was on its way out. The DOS demo scene was already doing 32 channel software mixing on 386 computer several years BEFORE the first Gravis UltraSound.

Not only was software mixing the true "innovation" -- it was driven by the vision of complete software synthesis, which came within the same decade that the UltraSound was released. Cards that did hardware mixing offered no advantages over simpler DACs in the new era.

Why are you constantly trolling climate discussions when you've been proved wrong so many times? No one bothers wasting their time on you any more.

There's a difference between relying on code and relying on hardware encryption.

Good lord no. That's code.

Science often proves common sense wrong.

It really isn't.

A ran into a fine example of why you are wrong just last week.

I was looking for a way for a .NET library developer to specify a type contract that included a non-default constructor with a specific prototype/signature. Now for some this may sound like an Interface, but others will argue that Interfaces should not specify implementation details and they (rightly or wrongly) include constructor prototypes as an implementation detail and argue that this is why interfaces should not (and do not) define constructor prototypes. The questions that appear throughout the internet (on msdn, stackoverflow, etc..) always involved the use of generics and so did the usage I had intended, so of course generic type constraints also came up. Quite specifically my need (and many others) is to develop a library which can construct generic types, however there is another related class of problems dealing with operator overloading that also spawns a similar set of questions based on the same framework limitation.

It did not matter how accurately anyone had described their need to define a constructor signature contract. Every discussion devolved into the same lesson about why interfaces shouldn't specify constructors or any other static functions and methods.

Every single time it was suggested that the person asking the question include a non-static method in the interface which could then construct the type. When it is pointed out that that would require an instance of the type to begin with, it then occurs to these people you suggest coddling, "have you tried the factory pattern?"

Isnt that what they are trying to implement? sigh...

So then the discussions devolve into these people devising more and more complex contortions to defend their belief that interfaces should not ever under any circumstances leak any implementation detail so therefore the questioner is wrong about needing a constructor contract, as if one actually led to the other. Quite remarkably they suggest alternatives that leak far more implementation details the other direction.

They just cannot imagine the need and no amount of explaining will get them to acknowledge that there really is one, therefore its all about something unimportant like the philosophy of interfaces rather than an alternative method of enforcing a constructor contract in the setting of a generic type constraint.

The GPP is 100% right when he says "Just because you don't understand their needs doesn't mean you need to step in and try to change what you think they need. (Ever think they just MIGHT be smarter than you or know their needs better?)"

You sit here defending that behavior on the grounds that you also default to the position that you understand the questioners needs better than they do, and I know why.

You learned that you shouldnt pretend to have answers that you don't have... but you've not handled that knowledge correctly. The proper course of action is to acknowledge to yourself that you don't have the answer, rather than attempt to alter the question so that you do have the answer. When you try to alter the question, it stops being about you helping the questioner and starts being about you helping yourself look smarter.

There's a fourth option: do both of those, then get a witch-doctor to shake some chicken bones at it.

Going through pointless rituals, just in case, and because it won't do any harm, is religion, not computer science.

Who told you that the coders who wrote OpenSSL were computer scientists?

I'm not talking about coding. It's hardware encryption. Once the key has been overwritten with another key, nothing is going to unencrypt that data. Nothing.

If that were true, Commodore would have won, not the PC. PCs were expensive back then. Not as expensive as Macs but far more expensive than PET/C64/Amiga.

Not really. None of those have been the very first of their category. Apple's secret is hard work following a particular set of design principles, not lucky flashes of inspiration.