I was one of the exceptional kids who shouldn't be speaking for the average person - but even I recognise that old-fashioned science textbooks full of dry, boring text are not the way to go to keep students interested.
You seem to fail to realise the obvious point that when I post something on a public website (like Slashdot), anyone can potentially view it, with no acess controls. (Being required to put it in a username and password does not really count as "access controls" if anyone can create an account.) There is no expectation of privacy. Same with a billboard. No expectation of privacy.
When I give my address out to Amazon.co.uk, it's not the case that anyone can potentially view it. There is an expectation of privacy.
Is it that hard to understand? Are you just being willfully obtuse?
There's no problem with processing information "in the frequency domain" as you anachronistically call it - I assume you mean "analog-encoded information". You just need accurate enough sampling, and then hey presto, you have digital information.
The real problem comes with understanding what the hell is going on in the brain. I.e. what each signal means. Which is nothing to do with analog/digital.
Radio waves aren't sound. That's why you can't hear them.
Sound waves are vibrations of the medium (air, or water, or rock, etc.). Radio waves are not vibrations of the medium. They don't need any medium. They are made of photons. Or rather, there is a wave-particle duality, where the same wave can either be viewed as a wave or as a set of photons.
What kind of nonsense logic is that? Is that like the old question (paraphrased) "If an alien falls in the forest and no-one hears it, does it really exist?"
I bet an object-oriented flavor of SQL syntax could be developed to work with OODBMS's, making the learning curve a lot flatter for people who already know SQL.
It already has been invented. It's called Object Query Language (OQL).
Oops. Should've used preview - point 2 should read:
2. Design your classes so that they are independent of any particular usage scenario. For example, prevention-of-nonsense invariants like "minimumSize <= maximumSize" should be enforced in the persistent class, but not application-specific invariants. (Yes, unrealistic in many situations, hence the next suggestion...)
The REAL problem with OO databases isn't that RDBMs might be more mature or whatever else you might read, it is that the data is almost always more important to companies than the behaviors that operate on that data. For example, if the company has a database of customers, they might want to use that database in dozens of different ways, and they might want to grow it for years, if not decades. The OO-database view tends to look at things too much from the view of one single application of the data and the data gets entangled with code behavior based on that specific application.
Three possible ways to address that:
Don't make fields private unless you are absolutely 100% sure that they should remain private for all time.
Design your classes so that they are independent of any particular usage scenario. For example, prevention-of-nonsense invariants like "minimumSize
Use an OODBMS with excellent, seamless schema evolution support. (Few, if any, existing production OODBMSs have this, admittedly).
I think better schema evolution support is ultimately the "best" way to solve this problem, but that will have to wait until the technology matures.
A join or ten wasn't nearly as expensive as getting data out of what was essentially just a dump.
What do you mean by a "dump"? Sounds like you were using the OO db inappropriately, e.g. by querying for "SELECT * FROM extent1" and then linearly searching it, or something.
3. People would ask us questions about the data we were storing that would have been absolutely trivial to find in a RDBMS (like "how many of these events occured last month when this device was in this state) that we'd have to write long slow-performing pieces of code to retrieve.
Doesn't ObjectStore have a query language similar to SQL? The Object Data Standard defines OQL, but I know that the Object Data Standard is not exactly "industry standard" yet. As for speed, it's still possible to create indexes, optimise data structures and algorithms, etc.
Other people wanted to write applications that used our data. That wasn't too easy, because they wanted slightly different objects. We would have had to agree on a object for everything we shared, or store things twice. With an RDBMS we used could use views, or generate the objects differently from the same tables.
This is an odd complaint. In any decent OODBMS, creating views (even manually) should be fairly simple. Yes, you might have to write some repititive code - there's room for improvement there. This is where aspect-oriented programming (specifically, composition filters) comes in, I think.
Yes but that logic still has to go somewhere. I don't see how putting the logic outside the objects will help remove the complexity.
If querying over some objects involves pointless logic computation, that suggests the relevant class(es) need rewriting - but it doesn't imply that OO databases are inherently bad.
You should chuck whatever language you're working in and replace it with one that supports full co-routines.
Threads, coroutines - what's the difference?
Now before you bite my head off, I know they are different. But both require individual stacks, coroutines can be emulated with threads - and threads support higher throughput (one thread can do compute while another is blocking on I/O) than single-threaded coroutine implementations.
There is a line to be drawn, and I would very much like to hear people's opinions on what is an acceptable line to draw, and where to draw it.
I would like to find a way, but I don't think it would be beneficial to put any ethics clauses in open source licenses at all. I think that any further fracturing of open source licenses into incompatible variants would do far more harm than good - because then you would have even more projects with incompatible licenses who couldn't ever share any code with each other. This would likely lead to the creation of "straight GPL", "straight BSD", etc. forks/reimplementations of major projects that decided to introduce ethics clauses into licenses. Then the "straight-licensed" projects (or "amorally licensed" if you wanted to be pejorative) would be more likely to succeed, by attracting more developers.
I know that sounds like a simplistic freemarketroid argument (like saying "the market will always favour efficiency" or whatever), but I think in this case it's true.
I agree, but I think you'll find the anti-war movement contains a large majority of people who don't believe in knee-jerk "no war under any historical circumstances" (i.e. the dictionary definition of pacifism). Very few people now believe that going to war with Hitler was wrong.
Casualties in the Gulf War were very low, and I can't imagine this being much different.
Casualties on our side were ridiculously low.
Casualties on the Iraqi side were vastly higher - but clearly you don't know that - not surprising, since the media hardly ever mentioned the numbers of Iraqi casualties at the time.
The concept of there being 100,000 civilian deaths (I've heard someone say it) is FUD.
It's not only not FUD, it's actually a conservative estimate. Check out the UN research on the subject.
3. Google saying "Searching 3,083,324,652 web pages" and "Results 1 - 10 of about 1,500,000. Search took 0.07 seconds"
WTF makes you think that's artificial intelligence??? Programming that required some intelligence, sure - but it wasn't programmed by an autonomous AI - it was programmed by human programmers.
Do you think that a (nanoscale) "barcode scanner" would be in any way intelligent if it could scan 1.5m items in a fraction of a second? Uh... I think not.
Any specified Turing Test can be defeated in much the same way as a lock-pick can defeat any specified lock
No it can't. Why then has no-one won the gold Loebner Prize yet?
The specification can be extremely simple. Here's mine: Take a panel of 10 computer scientists, a human volunteer and 11 computers. The volunteer and the AI software must both attempt to convince the panel that they're human, in IRC chat or something.
Most AI programs would be exposed as frauds in about 30 seconds or less.
That's why the Turing Test is so good. It's hard - because it's general, not specific. If you think it's specific to a certain task I think you have the wrong idea about what the Turing Test is.
As a result the daft buggers have been ordered to use Nedit, unless they agree to replace Windows with Linux and run Jedit on their desktop machine.
What has Linux got to do with JEdit? Why the requirement to replace Windows with Linux? JEdit runs on Windows too - obviously, as it's a pure Java program.
Garbage collection has been automated ever since Java 1.0 - but (in the traditional model at least) it only runs infrequently to avoid inconvenciencing the user. Clicking on the memory command allows you to invoke a garbage collection cycle is explicitly.
I agree. I'm working on a new programming language with better-than-Eiffel contracts (preconditions, postconditions, etc.), and the plan is for it to store all code in a database with consistency triggers. Of course, that means it'll have to handle the loose equivalent of CVS/Bitkeeper-style revision control by itself, but that's doable.
There is already enough room in a 32-bit instruction word to create millions of opcodes, even allowing for those that have embedded flags, register numbers etc. Moreover, "64-bit" (IIRC) isn't really about the size of the instruction word, but about the flat address space (and other stuff, but the flat address space is the fundamental thing). So that's nothing to do with 64-bit.
At first your idea sounds like a good idea to reduce code size, but probably the reason why it hasn't been done yet is that TANSTAAFL. You need to implement all that libc stuff as either microcode or actual hardware, and the code size improvements don't outweigh the chip real estate, chip design, testing, etc. costs.
I was one of the exceptional kids who shouldn't be speaking for the average person - but even I recognise that old-fashioned science textbooks full of dry, boring text are not the way to go to keep students interested.
When I give my address out to Amazon.co.uk, it's not the case that anyone can potentially view it. There is an expectation of privacy.
Is it that hard to understand? Are you just being willfully obtuse?
The real problem comes with understanding what the hell is going on in the brain. I.e. what each signal means. Which is nothing to do with analog/digital.
Sound waves are vibrations of the medium (air, or water, or rock, etc.). Radio waves are not vibrations of the medium. They don't need any medium. They are made of photons. Or rather, there is a wave-particle duality, where the same wave can either be viewed as a wave or as a set of photons.
Not all the cells, surely?
What proportion of cells are damaged in the process?
It already has been invented. It's called Object Query Language (OQL).
2. Design your classes so that they are independent of any particular usage scenario. For example, prevention-of-nonsense invariants like "minimumSize <= maximumSize" should be enforced in the persistent class, but not application-specific invariants. (Yes, unrealistic in many situations, hence the next suggestion...)
Three possible ways to address that:
- Don't make fields private unless you are absolutely 100% sure that they should remain private for all time.
- Design your classes so that they are independent of any particular usage scenario. For example, prevention-of-nonsense invariants like "minimumSize
- Use an OODBMS with excellent, seamless schema evolution support. (Few, if any, existing production OODBMSs have this, admittedly).
I think better schema evolution support is ultimately the "best" way to solve this problem, but that will have to wait until the technology matures.What do you mean by a "dump"? Sounds like you were using the OO db inappropriately, e.g. by querying for "SELECT * FROM extent1" and then linearly searching it, or something.
3. People would ask us questions about the data we were storing that would have been absolutely trivial to find in a RDBMS (like "how many of these events occured last month when this device was in this state) that we'd have to write long slow-performing pieces of code to retrieve.
Doesn't ObjectStore have a query language similar to SQL? The Object Data Standard defines OQL, but I know that the Object Data Standard is not exactly "industry standard" yet. As for speed, it's still possible to create indexes, optimise data structures and algorithms, etc.
Other people wanted to write applications that used our data. That wasn't too easy, because they wanted slightly different objects. We would have had to agree on a object for everything we shared, or store things twice. With an RDBMS we used could use views, or generate the objects differently from the same tables.
This is an odd complaint. In any decent OODBMS, creating views (even manually) should be fairly simple. Yes, you might have to write some repititive code - there's room for improvement there. This is where aspect-oriented programming (specifically, composition filters) comes in, I think.
If querying over some objects involves pointless logic computation, that suggests the relevant class(es) need rewriting - but it doesn't imply that OO databases are inherently bad.
Threads, coroutines - what's the difference?
Now before you bite my head off, I know they are different. But both require individual stacks, coroutines can be emulated with threads - and threads support higher throughput (one thread can do compute while another is blocking on I/O) than single-threaded coroutine implementations.
Is he consciously paraphrasing Goering there, I wonder?
I would like to find a way, but I don't think it would be beneficial to put any ethics clauses in open source licenses at all. I think that any further fracturing of open source licenses into incompatible variants would do far more harm than good - because then you would have even more projects with incompatible licenses who couldn't ever share any code with each other. This would likely lead to the creation of "straight GPL", "straight BSD", etc. forks/reimplementations of major projects that decided to introduce ethics clauses into licenses. Then the "straight-licensed" projects (or "amorally licensed" if you wanted to be pejorative) would be more likely to succeed, by attracting more developers.
I know that sounds like a simplistic freemarketroid argument (like saying "the market will always favour efficiency" or whatever), but I think in this case it's true.
I agree, but I think you'll find the anti-war movement contains a large majority of people who don't believe in knee-jerk "no war under any historical circumstances" (i.e. the dictionary definition of pacifism). Very few people now believe that going to war with Hitler was wrong.
Casualties in the Gulf War were very low, and I can't imagine this being much different.
Casualties on our side were ridiculously low.
Casualties on the Iraqi side were vastly higher - but clearly you don't know that - not surprising, since the media hardly ever mentioned the numbers of Iraqi casualties at the time.
The concept of there being 100,000 civilian deaths (I've heard someone say it) is FUD.
It's not only not FUD, it's actually a conservative estimate. Check out the UN research on the subject.
WTF makes you think that's artificial intelligence??? Programming that required some intelligence, sure - but it wasn't programmed by an autonomous AI - it was programmed by human programmers.
Do you think that a (nanoscale) "barcode scanner" would be in any way intelligent if it could scan 1.5m items in a fraction of a second? Uh... I think not.
No it can't. Why then has no-one won the gold Loebner Prize yet?
The specification can be extremely simple. Here's mine: Take a panel of 10 computer scientists, a human volunteer and 11 computers. The volunteer and the AI software must both attempt to convince the panel that they're human, in IRC chat or something.
Most AI programs would be exposed as frauds in about 30 seconds or less.
That's why the Turing Test is so good. It's hard - because it's general, not specific. If you think it's specific to a certain task I think you have the wrong idea about what the Turing Test is.
What has Linux got to do with JEdit? Why the requirement to replace Windows with Linux? JEdit runs on Windows too - obviously, as it's a pure Java program.
At first your idea sounds like a good idea to reduce code size, but probably the reason why it hasn't been done yet is that TANSTAAFL. You need to implement all that libc stuff as either microcode or actual hardware, and the code size improvements don't outweigh the chip real estate, chip design, testing, etc. costs.