SQL scales in complexity REALLY well if you know how the optimizer works and you can structure your tables and your queries to take advantage of the optimizer's tricks.
Isn't that why they put subqueries in SQL? Efficiency suffers because it's hard to for the optimizer to dive into the subquery, but between subqueries and aggresive indentation, you can make even big SQL queries pretty readable by humans.
SQL is terrible for expressing algorithms. Absolutely. Again, that is NOT the point.
You can think of a table as a CLASS. The columns are MEMBERS. The rows are INSTANCES.
When you get to the point where you are "creating one big giant run-on sentence", that is your clue that you should put down the SQL book and pick up your other programming book.
But you should still keep picking up that SQL book and referring to it as you learn that "real" language.
Every other language has been suggested, I suggest learning SQL.
SQL is functional programming. You tell the computer what you want. You don't know or care how it does it.
SQL is clearly not a general purpose programming language. That's not the point.
When you are learning, you need to take small bites of knowledge and chew them well. SQL will teach you to have patience with the computer.
SQL will teach you how to organize your data. This is a lot more important than you might realize. Getting the data structures right can turn hard problems into easy ones.
Don't bother with that JOIN stuff until you are comfortable.
Then move on to another language. Keep coming back to SQL as you learn the other language.
This will get you a good theoretical foundation and you will also have a great marketable skill.
You really do not want to spend your introductory programming experience learning about memory allocation and why the computer does funny things when you run past the end of an array.
BASIC is a terrible introductory language. It is very limited and it will forever stilt your understanding of how computers work and what you can do with them.
It does not matter that Scheme is not commercially successful.
Scheme is a very simple language to understand and learn, yet it contains EVERY tool necessary to write the most sophisticated programs. It is the perfect language to learn how to program.
This is like your six year old saying, "Name me one Tour De France rider who uses training wheels".
MIT turns out a lot of great software people, Scheme is what is taught in their introductory class.
How about taking over the systems that regulate the generators at a power plant? One could blow out the entire plant and every piece of electrical gear downstream.
Re:Even though no one dies from them.
on
Botnets As "eWMDs"
·
· Score: 3, Interesting
What if a hospital's infrastructure was taken down by a botnet immediately after a natural disaster?
If your database is crashed and is no longer capable of accepting data, how is that different from losing data? Go ahead and explain that with a straight face. Do they have another data store where you can keep your data until the database is fixed?
Sun should be ashamed of themselves for even calling this abomination a database in the first place. The word 'database' carries a whole host of expectations that the product simply does not live up to. A text file makes a better database than MySQL.
What is the debate? MySQL releases with known crashing bugs. Noone is disputing that.
Is the debate over whether or not it is okay to ship a database with known crashing bugs?
It really surprises me to hear someone from Sun saying that one can debate the merits of a crashing database. If this is the expected level of performance from MySQL, no wonder people shun it. At the very least they could have called it a beta or rc release, that would set the expectation level at something approaching reality.
Trying to script everything is a challenge, not a nightmare. All the items on your list after running the script can also easily be done in the script.
It is just beyond amazing what can be done in a shell script. Take a look at the abcde program as a prime example.
I have my entire server provisioning procedure in a single shell script. I run the installer, update everything, and then run my "magic" shell script. When it's done, the system is ready for action.
I think of the shell script as a TODO list, but it's bash that's doing the work instead of me.
I wouldn't have it any other way. Human memory is too fallible, and even written instructions are open to interpretation.
If you actually check off the items on the list and not just look at them, you don't need your memory to tell you whether you've done them or not, you can just look at the check marks.
The other half of the equation is taking the check list seriously in the first place. If you do that, then you WILL read and comprehend the questions.
Slashdot Mirror
SQL scales in complexity REALLY well if you know how the optimizer works and you can structure your tables and your queries to take advantage of the optimizer's tricks.
Isn't that why they put subqueries in SQL? Efficiency suffers because it's hard to for the optimizer to dive into the subquery, but between subqueries and aggresive indentation, you can make even big SQL queries pretty readable by humans.
The one advantage of "giant SQL" is that a smart database will crawl all over that huge query and optimize the hell out of it.
But of course we are way past the bounds of introductory programming at this point.
SQL is terrible for expressing algorithms. Absolutely. Again, that is NOT the point.
You can think of a table as a CLASS. The columns are MEMBERS. The rows are INSTANCES.
When you get to the point where you are "creating one big giant run-on sentence", that is your clue that you should put down the SQL book and pick up your other programming book.
But you should still keep picking up that SQL book and referring to it as you learn that "real" language.
Every other language has been suggested, I suggest learning SQL.
SQL is functional programming. You tell the computer what you want. You don't know or care how it does it.
SQL is clearly not a general purpose programming language. That's not the point.
When you are learning, you need to take small bites of knowledge and chew them well. SQL will teach you to have patience with the computer.
SQL will teach you how to organize your data. This is a lot more important than you might realize. Getting the data structures right can turn hard problems into easy ones.
Don't bother with that JOIN stuff until you are comfortable.
Then move on to another language. Keep coming back to SQL as you learn the other language.
This will get you a good theoretical foundation and you will also have a great marketable skill.
Functional programming is where you tell the computer what you want, and you leave it up to the computer to figure out how to do it.
SQL is the best known example of functional programming.
You want to spend your introductory computing experience learning about data structures, algorithms, objects, etc.
You do not want to waste time learning about the difference between pointers and arrays.
You do not want to know why the computer cannot tell that you have indexed past the end of an array.
You do not want to learn about memory allocation and why the computer cannot do it for you.
These things can come later when you are comfortable with the concept of telling a computer what to do.
Edit your LISP code in emacs and you will never make that complaint again.
Better yet, actually LEARN LISP, and you will know that syntax is irrelevant.
One of the classic LISP lessons is how to translate LISP-syntax programs into C-syntax programs and back again.
Did you actually learn Scheme? It is very easy to learn, IF it is taught correctly.
You will find yourself programming very complex stuff within a few hours.
Learning Scheme first will make you a better programmer in every other language. It matters not at all that Scheme is not used commercially.
MIT teaches it as a first language and they seem to turn out quite a few successful software people.
Learning C++ as an introductory language is like learning to ride a bicycle by climbing l'Alpe d'Huez.
After SICP, every computer language becomes very easy to learn, and you see how they are mostly all the same underneath.
You really do not want to spend your introductory programming experience learning about memory allocation and why the computer does funny things when you run past the end of an array.
BASIC is a terrible introductory language. It is very limited and it will forever stilt your understanding of how computers work and what you can do with them.
It does not matter that Scheme is not commercially successful.
Scheme is a very simple language to understand and learn, yet it contains EVERY tool necessary to write the most sophisticated programs. It is the perfect language to learn how to program.
This is like your six year old saying, "Name me one Tour De France rider who uses training wheels".
MIT turns out a lot of great software people, Scheme is what is taught in their introductory class.
How about taking over the systems that regulate the generators at a power plant? One could blow out the entire plant and every piece of electrical gear downstream.
What if a hospital's infrastructure was taken down by a botnet immediately after a natural disaster?
Did Stroustrup create a professor at Texas A&M? I thought he was a software developer, not a genetic engineer.
It's impressive that a company ships junk and admits it? Since when is that impressive? Boy are you setting the bar low.
If your database is crashed and is no longer capable of accepting data, how is that different from losing data? Go ahead and explain that with a straight face. Do they have another data store where you can keep your data until the database is fixed?
Sun should be ashamed of themselves for even calling this abomination a database in the first place. The word 'database' carries a whole host of expectations that the product simply does not live up to. A text file makes a better database than MySQL.
What is the debate? MySQL releases with known crashing bugs. Noone is disputing that.
Is the debate over whether or not it is okay to ship a database with known crashing bugs?
It really surprises me to hear someone from Sun saying that one can debate the merits of a crashing database. If this is the expected level of performance from MySQL, no wonder people shun it. At the very least they could have called it a beta or rc release, that would set the expectation level at something approaching reality.
Does the chip come with a free ticket to Henry Nicholas's lair?
Trying to script everything is a challenge, not a nightmare. All the items on your list after running the script can also easily be done in the script.
It is just beyond amazing what can be done in a shell script. Take a look at the abcde program as a prime example.
Awesome!!!
I have my entire server provisioning procedure in a single shell script. I run the installer, update everything, and then run my "magic" shell script. When it's done, the system is ready for action.
I think of the shell script as a TODO list, but it's bash that's doing the work instead of me.
I wouldn't have it any other way. Human memory is too fallible, and even written instructions are open to interpretation.
If you actually check off the items on the list and not just look at them, you don't need your memory to tell you whether you've done them or not, you can just look at the check marks.
The other half of the equation is taking the check list seriously in the first place. If you do that, then you WILL read and comprehend the questions.
"Every time Andy gives us more power, Bill takes it away".