Well, though I do love my Firefox, I must say that the above comments sound like some of the corporate suites I talk to who assure me that IE6 is fine. Why change?
I mean - running JavaScript and rendering pages in Chrome is REALLY FAST. What part of that is due to WebKit, I do not know. If Gecko can be made to compete - that is great. However if an essential technological limitation has been hit, and if Chrome/WebKit surmounted it - than we should recognize progress and move on.
1. If you insinuate that multi-process programming is easier than multi-threaded programming any time that resources need to be shared, than you are plain wrong.
2. In a non-threaded program you are running essentially a single thread. If that thread hangs, your whole program hangs anyway. Mutex or no mutex.
3. True - but they also solve a whole new class of problems. So they are not a universal bullet, I would not multi-thread hello world. But when the time comes to when you need them - it sure feels like a magic bullet.
Anyway. SOMEONE POST SOMETHING ON TOPIC! I am more than half way through this, and I still don't know why WebKit is cool, and why Mozilla won't use it! (And multi-threaded vs. multi-process is not that reason)
So what is the point of this tax?
It DECREASES the tax on gas guzzlers, by charging a hybrid the same tax as an H2. So it is damaging on the environment.
It is an awful intrusion of privacy.
It will likely not work.
To be fair, the only thing that is a redeeming quality is that by timing when you drive, and charging different ammount of tax, there IS A SLIGHT possibility that it will reduce traffic jams. The expense and difficulty of implementing the system though, make it impractical compared to a simple toll booth.
I can only hope the good voters from OR will vote this bill down like they should.
One of the main points in this article is programmer's time is more precious than machine time.
Programmer's time might be more precious than machine time when writing small scripts and proof-of-concept code, intended for a TINY audience, but USER time is more precious than programmer time when developing real applications, and USER time wastage is directly correlated to machine time wastage.
I agree with much of what he is saying - about CPU power being massivelly wasted. I honestly would not have believed back in 95, that the performance (or should I say user experience) I got out of my 100Mhz CPU with 32MBs of RAM will be roughly comparable with my 2200Mhz machine with 700MBs of RAM when using most applications (GTA III being a notable exception)....
On the other hand I, can't believe that he would suggest that we go forth and waste a million times more power for NOTHING!!!!
Still I maintain that Object Prevalence is NOT a product but a concept. A foundation on which other products can be based. What has been shown to us can hardly be even called a library.
It shows us (a proof of concept?) how we can have the functionality of a memory resident database in a few hundred lines of code. It also gives us a scalable foundation. The author took a bigger bite than he can chew when he said that we can throw away our databases.
Taking the snapshots from memory and dumping them to a file, as well as keeping a transaction log to bring the database up to the minute is not a new concept. The concisness of this particular implementation is what impressed me.
You are right that before you can call it a real database it needs a lot more work, yet it is a good persistance mechanizm that beats the hell out of flat files, and is also CHEAP, and very LIGHT. By consuming very little system resources, yet providing high flexibility, products relying on this concept can compete in the market place. Also - lets face it - there are some good B-Tree (if that is your cup of tea) implementations out there already, object locking is something we do all the time already when we multithread, and not all applications need to be all that ad-hoc.
There is room of Object Prevalence out there, and there is a lot of room for products based on it to grow. I am looking forward to seeing some interesting things come out of it.
Good points. Considering the its simplicity, though, you must admit the system is very slick. Lacking the structure of a real database, it has obvious shortcomings, yet it does exactly what it promisses - provides OO-based, high-performance persistance mechanizm. As the author points out in his paper, Prevalence is a concept and not a tool. The point I am trying to make is that although SQL is not integrated into this product (yet), it may not be entirely applicable at this stage. SQL was designed to put an abstraction layer between the middleware and the database, so the middleware developer needs to know very little about about the DB's API. The sorting, seraching, etc algorithms and API were hidden behind it. The author of the aricle is collapsing the database in the middleware. The programmer is responsible for providing the search and sort, etc code. Eventually a library with standard methods, and even a SQL clone can be developed, but a part of the beauty of the system is that its foundation is totally open, providing, as another post pointed out, opportunity for inovative, and potentially more powerful solutions. If basic persistance is what you are after, the >500 lines of code of this project are a great way to get it.
Slashdot Mirror
Well, though I do love my Firefox, I must say that the above comments sound like some of the corporate suites I talk to who assure me that IE6 is fine. Why change?
I mean - running JavaScript and rendering pages in Chrome is REALLY FAST. What part of that is due to WebKit, I do not know. If Gecko can be made to compete - that is great. However if an essential technological limitation has been hit, and if Chrome/WebKit surmounted it - than we should recognize progress and move on.
Really, come on! I tired of 'thread bashing'.
1. If you insinuate that multi-process programming is easier than multi-threaded programming any time that resources need to be shared, than you are plain wrong.
2. In a non-threaded program you are running essentially a single thread. If that thread hangs, your whole program hangs anyway. Mutex or no mutex.
3. True - but they also solve a whole new class of problems. So they are not a universal bullet, I would not multi-thread hello world. But when the time comes to when you need them - it sure feels like a magic bullet.
Anyway. SOMEONE POST SOMETHING ON TOPIC! I am more than half way through this, and I still don't know why WebKit is cool, and why Mozilla won't use it! (And multi-threaded vs. multi-process is not that reason)
NoCAT is a nice tool that is available for exactly that kind of project.
So what is the point of this tax?
It DECREASES the tax on gas guzzlers, by charging a hybrid the same tax as an H2. So it is damaging on the environment.
It is an awful intrusion of privacy.
It will likely not work.
To be fair, the only thing that is a redeeming quality is that by timing when you drive, and charging different ammount of tax, there IS A SLIGHT possibility that it will reduce traffic jams. The expense and difficulty of implementing the system though, make it impractical compared to a simple toll booth.
I can only hope the good voters from OR will vote this bill down like they should.
One of the main points in this article is programmer's time is more precious than machine time.
Programmer's time might be more precious than machine time when writing small scripts and proof-of-concept code, intended for a TINY audience, but USER time is more precious than programmer time when developing real applications, and USER time wastage is directly correlated to machine time wastage.
I agree with much of what he is saying - about CPU power being massivelly wasted. I honestly would not have believed back in 95, that the performance (or should I say user experience) I got out of my 100Mhz CPU with 32MBs of RAM will be roughly comparable with my 2200Mhz machine with 700MBs of RAM when using most applications (GTA III being a notable exception)....
On the other hand I, can't believe that he would suggest that we go forth and waste a million times more power for NOTHING!!!!
Good criticism!
Still I maintain that Object Prevalence is NOT a product but a concept. A foundation on which other products can be based. What has been shown to us can hardly be even called a library.
It shows us (a proof of concept?) how we can have the functionality of a memory resident database in a few hundred lines of code. It also gives us a scalable foundation. The author took a bigger bite than he can chew when he said that we can throw away our databases.
Taking the snapshots from memory and dumping them to a file, as well as keeping a transaction log to bring the database up to the minute is not a new concept. The concisness of this particular implementation is what impressed me.
You are right that before you can call it a real database it needs a lot more work, yet it is a good persistance mechanizm that beats the hell out of flat files, and is also CHEAP, and very LIGHT. By consuming very little system resources, yet providing high flexibility, products relying on this concept can compete in the market place. Also - lets face it - there are some good B-Tree (if that is your cup of tea) implementations out there already, object locking is something we do all the time already when we multithread, and not all applications need to be all that ad-hoc.
There is room of Object Prevalence out there, and there is a lot of room for products based on it to grow. I am looking forward to seeing some interesting things come out of it.
Good points. Considering the its simplicity, though, you must admit the system is very slick. Lacking the structure of a real database, it has obvious shortcomings, yet it does exactly what it promisses - provides OO-based, high-performance persistance mechanizm. As the author points out in his paper, Prevalence is a concept and not a tool. The point I am trying to make is that although SQL is not integrated into this product (yet), it may not be entirely applicable at this stage. SQL was designed to put an abstraction layer between the middleware and the database, so the middleware developer needs to know very little about about the DB's API. The sorting, seraching, etc algorithms and API were hidden behind it. The author of the aricle is collapsing the database in the middleware. The programmer is responsible for providing the search and sort, etc code. Eventually a library with standard methods, and even a SQL clone can be developed, but a part of the beauty of the system is that its foundation is totally open, providing, as another post pointed out, opportunity for inovative, and potentially more powerful solutions. If basic persistance is what you are after, the >500 lines of code of this project are a great way to get it.