It's incredible how people buy the marketroid BS about rdbms systems.
What are transactions anyway?
It simply means that when you store:
(85, "some other data")
it gets stored:
(23, 85, "some old data")
(32, 85, "some data")
With 23 and 32 the transactions that have created the data.
After a while, transaction 23 gets sweeped (=deleted) by some sweeping process.
In the meanwhile, as long as transaction 32 has not been committed, all the other transactions 23,24,25,..., 33,34,... will not see "some data" but rather "some old data".
SELECT COL1,COL2 FROM T1
conceivably becomes (optimized rather than in bland SQL)
SELECT COL1,COL2
FROM T1, TRANSACTIONS
WHERE T1.TRANSID=TRANSACTIONS.TRANSID
AND TRANSID >=
(SELECT MAX(TRANSID) WHERE COMMITTED=TRUE)
Of course, in a pointer arithmetic oriented system language like C, this stuff would go very fast, but rather hard to implement too.
Unfortunately, we need this speed rather badly, on the relatively slowish hardware of today.
Row-locking is very similar, with some in memory table getting consulted before touching a particular row (can you smell the overhead?) and transparantly having a column in every table that uniquely numbers the rows.
MySql blazes, faaaast, because it does not implement the overhead for this. If you implement the table transaction, and the table rowlocks (preferably somewhere in-memory), you've got transactions and row locks implemented anyway.
If they build it into MySql, you cannot get rid of the overhead any longer, if you don't need it.
I guess the solution could consist in turning Mysql into some db framework with adaptor classes, mostly written in something higher level (like compiled GCJ Java), and then supply your own adaptor classes that implement the additional features that you need for a particular project. Note, however, that MySql wouldn't be as fast any longer, and therefore lose much of its appeal in the process.
Unfortunately, the whole virtual machine approach sucks like a 2-dollar hooker.
Why not have to linker grab the.class and(!) native.obj files that your application needs (and nothing more) and link them to one executable?
It would solve a large number of problems that are now plaguing Java applications:
(1) A need to deploy the run-time
(2) another need to deploy the run-time everytime you upgrade the jdk.
(3) an unnecesary requirement for the run-time to remain backwards compatible.
Why not take the sealed jar approach to the logical point where it not only contains all the.class files your application needs but the.obj files as well?
In such case, an executable would have all its dependencies, contained in its own file, and there would be no need to remain backward compatible. The new executable would simply contain the new dependencies!
Second, I would like to see:
import org.myorg.somefunctionality.1.99.* As some
It prevents global name space pollution, and it clearly indicates what namespace the classes and methods come from. Now you would have to write the horrible:
If you don't want other people to use your idea, keep it to yourself then.
By the way, if you compose your invention using use any idea from the public domain, your so-called intellectual property is nothing more than theft and re-sell of stolen goods.
Let us watch the patent system go up in flames, in one big f*ckfest of debilitating litigation.
Instead of weening, let us all start filing absurd patents too. I'm claiming the zero-click, the two-click, three-click, say n-click processes for myself!
The waterfall life cycle of a project has been dead for decades now. You must be prepared to redo things or else miserably fail.
The one, single, main reason for total project failure is the inability of management to face the truth and agree to redo the things that didn't work out as planned. Even though it sounds extremely tempting, just continuing according to plan, is not an option.
If you can't write it, you can't design it. So designing is part of the process. It's simply telling beforehand what you are going to try. But then again, you're most likely going to end up with a different strategy, because your original idea has run into insurmountable obstacles. Designing is an iterative process very closely linked with coding. You can't separate both.
Testing consists in writing test modules that continuously challenging (your own, or someone else's) assumptions under different conditions. You can't test, if you can't write. So it's part of the process.
Management is stating what end result must be attained by the functionality of the code, by which resources and by what end date; then staff the team accordingly; and periodically find out if things are still on track. Management is not part of the process.
Most often management doesn't even understand the process; and the more they interfere, the more likely things will go wrong.
There may be a lot of other aspects to software development, but for me the most important one is creative and determined reasoning through a maze of obstacles to finally reach your goal: beautiful code.
Coding is much more like an art than a science; you definitely need to be talented and you will never learn it out of a book. Obtaining a degree in it may help a bit, but that still doesn't mean that you have the holy fire burning inside of you.
The relationship between a code and his code is not much unlike the one between a singer and his song, a poet and his poem, a sculptor and his statue...
Why do they sing, write, compose, sculpt? Because they can't live without it. The same observation holds true for real, good coders. Writing code is the one thing we cannot live without.
Offering a management position to a developer, is like asking Mick Jagger to become studio manager at Universal. He'll tell you to f*ck off...
I guess avoiding the Microsoft tax by using Linux is a minor issue, when you're facing the prospect of a $10,000 per patient per year Glaxo-Welcome tax for 20% of your population.
What are you going to use to avoid that? Bill Clinton has threatened to unleash the seven plagues of Egypt on South-Africa, if they use patent-infringing alternatives.
At least 45 million Africans are slated to die over the next 5 years for Glaxo-Welcome's intellectual property patent on AZT.
Slashdot Mirror
It's incredible how people buy the marketroid BS about rdbms systems.
... will not see "some data" but rather "some old data".
What are transactions anyway?
It simply means that when you store:
(85, "some other data")
it gets stored:
(23, 85, "some old data")
(32, 85, "some data")
With 23 and 32 the transactions that have created the data.
After a while, transaction 23 gets sweeped (=deleted) by some sweeping process.
In the meanwhile, as long as transaction 32 has not been committed, all the other transactions 23,24,25,..., 33,34,
SELECT COL1,COL2 FROM T1
conceivably becomes (optimized rather than in bland SQL)
SELECT COL1,COL2
FROM T1, TRANSACTIONS
WHERE T1.TRANSID=TRANSACTIONS.TRANSID
AND TRANSID >=
(SELECT MAX(TRANSID) WHERE COMMITTED=TRUE)
Of course, in a pointer arithmetic oriented system language like C, this stuff would go very fast, but rather hard to implement too.
Unfortunately, we need this speed rather badly, on the relatively slowish hardware of today.
Row-locking is very similar, with some in memory table getting consulted before touching a particular row (can you smell the overhead?) and transparantly having a column in every table that uniquely numbers the rows.
MySql blazes, faaaast, because it does not implement the overhead for this. If you implement the table transaction, and the table rowlocks (preferably somewhere in-memory), you've got transactions and row locks implemented anyway.
If they build it into MySql, you cannot get rid of the overhead any longer, if you don't need it.
I guess the solution could consist in turning Mysql into some db framework with adaptor classes, mostly written in something higher level (like compiled GCJ Java), and then supply your own adaptor classes that implement the additional features that you need for a particular project. Note, however, that MySql wouldn't be as fast any longer, and therefore lose much of its appeal in the process.
Java is definitely C++ done right, as a language.
.class and(!) native .obj files that your application needs (and nothing more) and link them to one executable?
.class files your application needs but the .obj files as well?
Unfortunately, the whole virtual machine approach sucks like a 2-dollar hooker.
Why not have to linker grab the
It would solve a large number of problems that are now plaguing Java applications:
(1) A need to deploy the run-time
(2) another need to deploy the run-time everytime you upgrade the jdk.
(3) an unnecesary requirement for the run-time to remain backwards compatible.
Why not take the sealed jar approach to the logical point where it not only contains all the
In such case, an executable would have all its dependencies, contained in its own file, and there would be no need to remain backward compatible. The new executable would simply contain the new dependencies!
Second, I would like to see:
import org.myorg.somefunctionality.1.99.* As some
Instead of:
import org.myorg.somefunctionality.1.99.*
It prevents global name space pollution, and it clearly indicates what namespace the classes and methods come from. Now you would have to write the horrible:
org.myorg.somefunctionality.1.99.someClass myvar=new org.myorg.somefunctionality.1.99.someClass()
I would like to see instead:
some.someClass myvar=new some.someClass()
Open-sourcing is definitely needed, so that we can finally move the thing forward!
If you don't want other people to use your idea, keep it to yourself then.
By the way, if you compose your invention using use any idea from the public domain, your so-called intellectual property is nothing more than theft and re-sell of stolen goods.
Let us watch the patent system go up in flames, in one big f*ckfest of debilitating litigation. Instead of weening, let us all start filing absurd patents too. I'm claiming the zero-click, the two-click, three-click, say n-click processes for myself!
The waterfall life cycle of a project has been dead for decades now. You must be prepared to redo things or else miserably fail.
The one, single, main reason for total project failure is the inability of management to face the truth and agree to redo the things that didn't work out as planned. Even though it sounds extremely tempting, just continuing according to plan, is not an option.
I haven't read the book. I actually got the term from a song "The holy fire that bombards the heavens", by the Scene. (The song is in Dutch)
If you can't write it, you can't design it. So designing is part of the process. It's simply telling beforehand what you are going to try. But then again, you're most likely going to end up with a different strategy, because your original idea has run into insurmountable obstacles. Designing is an iterative process very closely linked with coding. You can't separate both.
Testing consists in writing test modules that continuously challenging (your own, or someone else's) assumptions under different conditions. You can't test, if you can't write. So it's part of the process.
Management is stating what end result must be attained by the functionality of the code, by which resources and by what end date; then staff the team accordingly; and periodically find out if things are still on track. Management is not part of the process.
Most often management doesn't even understand the process; and the more they interfere, the more likely things will go wrong.
There may be a lot of other aspects to software development, but for me the most important one is creative and determined reasoning through a maze of obstacles to finally reach your goal: beautiful code.
...
...
Coding is much more like an art than a science; you definitely need to be talented and you will never learn it out of a book. Obtaining a degree in it may help a bit, but that still doesn't mean that you have the holy fire burning inside of you.
The relationship between a code and his code is not much unlike the one between a singer and his song, a poet and his poem, a sculptor and his statue
Why do they sing, write, compose, sculpt? Because they can't live without it. The same observation holds true for real, good coders. Writing code is the one thing we cannot live without.
Offering a management position to a developer, is like asking Mick Jagger to become studio manager at Universal. He'll tell you to f*ck off
I guess avoiding the Microsoft tax by using Linux is a minor issue, when you're facing the prospect of a $10,000 per patient per year Glaxo-Welcome tax for 20% of your population.
What are you going to use to avoid that? Bill Clinton has threatened to unleash the seven plagues of Egypt on South-Africa, if they use patent-infringing alternatives.
At least 45 million Africans are slated to die over the next 5 years for Glaxo-Welcome's intellectual property patent on AZT.