"I've also seen books out there on physics for game programmers - this might come in quite handy for things just as simulating the look of gravity's effect on objects, etc., so look into that, too."
I would like to point out that such tutorials and texts are easily found on the internet. Just google around a bit and you can get it for free (instead of buing expensive books).
First, you should try to understand how computers work. There are many great books on the subject, but I find older tutorials just as informative. For graphics I would recommend the PCGPE, at least the VGA tutorial.
You also need to learn to program. This is done on two levels, first you learn one language, but when you try your second you will see the similarities and thus learn programming, and apprechiate the languages as tools (at least that is the ideal case). I would start by using C or perhaps C++ as these are the most commonly used languages today (they are however not the easiest languages, and for example, pointers require a good understanding in how a computer works). I would recommend Steven Prata's book on C (I don't remember it's title, but try amazon). For C++, just try Bruce Eckels homepage, he has lots of free books on line (google for Bruce Eckel).
The you will probably need a library that removes all the fuzz from programming, such as hardware details (you still need to understand the hardware though!). I would recommend SDL (www.libsdl.org) for general game/demo programming. But also directfb, if you intend writing software for Linux only. For applications I would recommend Qt (www.trolltech.com), a great UI/portability toolkit, but I have to mention GTK+/GNOME too (to avoid being hit by flames from their fans).
A general tip is that knowledge pays. Read as much as you can, howtos, tutorials, books, articles, etc. and try to understand it. If you see how things work, you will soon become a great programmer. It helps if your attitude is "difficult you say? I like challenges!".
A final warning, programming can be concidered a drug. It easily eats much of your spare time!
I once got hold of 5-10 stickers that would trigger most shops alarm systems (the check points at the entry and exit points). It was a real laugh to put these stickers on peoples belongings and watch them set of alarms at the local mal...
Seriously, I think that it would become a problem to have these devices enabled after having been used. This requires the security system to verify that the mark is 'one of ours' before sounding the alarm. Kill the marker after the payment has been done and everything is plain sailing.
Mine said something like: "Well, it does indeed look like this php is better than asp, but as we use Office, we'll stick to what we know." so I'm stuck with Microsoft up mine... so to speak.
The commersial Qt version can run on Win32. If you have the dll you would (perhaps, maybe, haven't tried) be able to compile your exes using gcc in cross compilation mode from kdevelop, thus develop win32 apps in a linux environment...
I guess that this means that there are very few excuses for running win32 as a developer (besides propretary tools and evil managers...)
QSA shows the great hidden abilites of the Qt toolkit. Hopefully the code will show how easy this is so that a free VBA compatible version will appear rendering all (non-viral) Windows scripts runnable in a free environment. This is one of the major things M$ Office has today, the scriptability. It is not great, not even good according to some (me) but it is there and works.
I wasn't speeding, but apparently going too fast (as I aquaplaned). I went over a crest while going through a sharp curve and the rest is already known to you...
I learned two big things while doing this: 1) water is more dangerous than it seems, and 2) the value of a car compared to a human is neglectable, I am *really* glad noone got hurt!
Oh wait, I thought you smashed the car while at work for testing purposes...
Actually, it was my first job. I'd been working there alittle bit over one week when there was an urgent delivery needing care. Since the company cars were all used and I don't own a car I got to borrow my (quite new) boss' personal car...
I had my worst phone conversation ever when I had to tell him that I would come by train. "Could someone please pick me up?".
It took four months to replair the car. His fondest parts of the car were the rims; they were part of a limited edition. The problem with them is that in the process of smashing his car into pieces I crossed the side of the road. It was about one foot high and I hit it with the side first (luckily I did not flip the car). Two rims were jammed into the car, quite oddly shaped when removed, and the other two where ripped of the car and were never found.
As I said, the most embarissing thing I've ever done (this far). Nothing I recommend anyone trying at home!
You have to consider the ratio saved lives vs killed by missuse/accident. Most modern protection systems like airbags, seat belts, belt tensioners, ABSs, traction control systems, dynamic breaks, etc have a very good ratio, even though they cause problems. I would however not suggest using them the wrong way, collisions hold huge amounts of energy which can easily kill or deadly injure ignorant/badly informed/lazy individuals.
As for your suggestion about a law against stupid accidents. In Sweden there is a law against accidents, so if noone ever broke any rules, but still caused an accident, they will be punished. As for many of your examples, they are allready illegal (intoxicated driving, driving while using a cell phone, etc) and the rest are just things that one shouldn't do while driving.
I live in Sweden where seat belts are compulsory too, just as in the UK. This rule is the biggest life saver of them all, no airbag in the world saves you in a roll-over situation (which is quite common).
As for the force, I work at a company producing the inflators used in passenger side airbags and they are really powerful (the company name is Autoflator, a part of the Autoliv group). I have also smashed a car (aquaplaning... scary stuff) and I got hit pretty good by the airbag.
One big difference, stem-cells are just cells, without emotions, will and such (sole if you want to put it in one word, even though I do not belive in the sole idea).
An airbag inflator has the power of a hand granade. I would not like to carry such as device too close to the body. Also, what happens if I would wear a packpack, or have someone on join me on the bike (sitting behind me).
This device may look right, but how many lives will it save compared to those it take. Also, how do you dispose an explosive jacket, or take it with out on an aircraft. I'd say that this is probably a publicity stunt, and not really a life saver as airbags in cars are, but thats just MHO.
"The intent of the project is to produce stem cells for medical research."
The benefits of this is to great to avoid doing it. If the cells are not cloned in the US, they will be bought from abroad, so the result will be the same anyway. Brave of Stanford to dare doing this in the US anyhow!
I must agree! User cases is the way to discuss software with users. You can draw user cases as in UML to make things really clear.
In mu profession I often write software to replace or complement older software. My applications are often used to reduce paperwork and to avoid doing things manually. To be able to do this in a good way, you need to know what your user does how and when and, idealy, why. This is why I often spend many hours letting the users explain their current work to me. When they are done, I put together a number of user cases trying to redescribe what they've explained to me and then schedule another meating. On the second meeting I try to explain what the user is supposed to do, and I explicitly as the user if this fits into the way they work. This process can take a few iterations 3-5 meetings (including the first 2), but always yeild good software and great user feedback.
It does not cost money, it costs time (which is money according to many).
SF does make money from the hosting, but still, there is no cost to the open source project, which is the point. I do not care too much about other peoples expenditures when discussing my economy.
Most open source projects goes live without _any_ budget. All that it takes is time (which is a cost for companies, but not for voluntary workers). As for servers and such, put a page on sourceforge, and try to get a few mirrors up and running too (they will come, if the project is attractive).
As for the actual release, try to make a good presentation about the project, what it is meant to do, where you want to go with the development, and encourage a developers community with a forum of some sort (mailing list), also, most open source projects must have screenshots (why, I don't know?).
If the project is attractive, and you work hard enough you'll gather a group of power users. These users are great, ask them what they want, how they want it, and tell them to talk to you about anything that bugs them. You'll need all the feedback you can get.
Finally, and most importantlly: do not expect to have others working for you, they may report bugs, send small patches, you'll have to do most work, at least in the beginning.
Ok, I admit I may have been a little too hard on his text. But the following quote from my reply sums things up:
"I'd say that the law of leaky abstractions is greatly exaggerated, but not entirely invalid. If you suffer from leaky abstractions you should concider changing tools or approach but not run away crying saying that abstraction is bad. Abstraction is a great tool, but as with all other tools it takes time to master. When used correcly it can reduce debugging time and increase the reusability. As a great example of code reuse I must point out that the TCP abstraction has saved thousands (if not millions) of source code lines. Just imagine if everyone had to rely on IP directly; How complex wouldn't the code be."
Leaky abstractions is not a problem in it self, the actual problem is that someone is using the wrong tools in the wrong situation.
I've studied the Law of Leaky Abstactions during the weekend, and have come up with a list of comments. All these comments are of course MHO.
Mr. Spolsky argues that object orientation, or non trivil abstractions always leak, and that this is making programming unnecesarily hard. I would like to disagree. He starts his text by describing a very good abstraction that has been used and reused for many years in thousands of applications, the TCP layer, using the IP layer to provide easy message passing over the internet (or any other IP net by the way). He claims that the TCP abstraction leaks when, for example, a network cable breaks so that the communication cannot take place. I would like to say that this is a part of the abstraction: TCP connections can break. It is a natural part of a communications protocol and must be taken into account. TCP is, IMHO, a protocol used to send messages in one or more IP packages and to get them back they way I sent them. If the cable is broken, of course I do not expect my message to arrive. To put it in plain English, TCP allows me to send longer messages over a network and takes care of the splitting into packages and reassembly. That is all, it does not perfrom magic.
Mr. Splolsky goes on with a number of examples of leaking abstractions, I'll comment them one by one here:
When iterating over two dimensional arrays the order that you access the items leads to different performance. This is mainly due to page faults (I'll ignore cache misses here). To solve this, simply use the right tool. If you want predictable response times and the ability to force a page to stay in memory, use a real-time OS. The general, flat memory space, OS abstraction does not guarantee access times. It does not even guarantee that your process is running all the time, a UNIX system might even swap out your entire process if you'r out of luck.
As for the SQL problem, this must be a problem in the language specification. It is a leaky abstraction, but you can always use another access method to retreive data from the database if performance is an issue. It is always hard to combine a high level abstraction with really high performance.
He goes on with files accessed over a network. I must ask a simpley question: what makes this a network problem? Local files can also fail. If the.forward file is located on a local harddrive that failes (CRC error in the actual file) you still experience this problem. This is a part of the file abstraction; Things can fail. Just as in the TCP example. This would not change if we went back to writing individual blocks to the hard drive platters, it would just complicate access, *alot*.
As for string classes, I will discuss this later.
The last example is just plain bull. The roof, wind screen and climate controls of a car is not used to abstract away the weather. Neither is traction control systems and such devices. These are simply tools that increase the comfort of the driver and passengers.
Now, lets deal with the C++ string class. The example "foo" + "bar" is wrong. To declare a string constant, you should type string("foo") + string("bar"). This is just as odd as the declaration of long constants: 1L + 2L. I believe that the reason that C++ does not have a native string type is because C++ only knows scalar values (a string is a pointer which is a scalar value). This is due to the heritage from C.
He goes on rambling about accessing OUT LPTSTR arguments, COM objects, ASP.NET flaws etc. These are bad abstractions by Microsoft and should not be concidered useful examples. Then to compain about Visual BASIC failing now and then for non-basic related issues; I dare to call VB an ugly hack. It is not a real tool to be used in professional software development. I get frightened when I see how many business critical systems that are based on VB code.
Then he goes off topic (to use a/. expression). He starts to attack code generation tools and RADs. This is not abstraction, this is tools to allow people without the right competence and knowledge to try out programming. RADs are in fact _a_very_bad_thing_ as they encourages bad software development practice. They make it easy to forget how important it is to sitt down and thing before you start implementing.
The next thing to complain about is that you need to know more to develop software today than ten - fifteen years ago. I do not find this strange as we construct far more complex and interdependent systems today. This while spending less and less time on planning.
I'd say that the law of leaky abstractions is greatly exaggerated, but not entirely invalid. If you suffer from leaky abstractions you should concider changing tools or approach but not run away crying saying that abstraction is bad. Abstraction is a great tool, but as with all other tools it takes time to master. When used correcly it can reduce debugging time and increase the reusability. As a great example of code reuse I must point out that the TCP abstraction has saved thousands (if not millions) of source code lines. Just imagine if everyone had to rely on IP directly; How complex wouldn't the code be.
Abstraction helps us develop better, more complex software and avoid reinventing the wheel every five minutes!
Slashdot Mirror
"I've also seen books out there on physics for game programmers - this might come in quite handy for things just as simulating the look of gravity's effect on objects, etc., so look into that, too."
I would like to point out that such tutorials and texts are easily found on the internet. Just google around a bit and you can get it for free (instead of buing expensive books).
First, you should try to understand how computers work. There are many great books on the subject, but I find older tutorials just as informative. For graphics I would recommend the PCGPE, at least the VGA tutorial.
You also need to learn to program. This is done on two levels, first you learn one language, but when you try your second you will see the similarities and thus learn programming, and apprechiate the languages as tools (at least that is the ideal case). I would start by using C or perhaps C++ as these are the most commonly used languages today (they are however not the easiest languages, and for example, pointers require a good understanding in how a computer works). I would recommend Steven Prata's book on C (I don't remember it's title, but try amazon). For C++, just try Bruce Eckels homepage, he has lots of free books on line (google for Bruce Eckel).
The you will probably need a library that removes all the fuzz from programming, such as hardware details (you still need to understand the hardware though!). I would recommend SDL (www.libsdl.org) for general game/demo programming. But also directfb, if you intend writing software for Linux only. For applications I would recommend Qt (www.trolltech.com), a great UI/portability toolkit, but I have to mention GTK+/GNOME too (to avoid being hit by flames from their fans).
A general tip is that knowledge pays. Read as much as you can, howtos, tutorials, books, articles, etc. and try to understand it. If you see how things work, you will soon become a great programmer. It helps if your attitude is "difficult you say? I like challenges!".
A final warning, programming can be concidered a drug. It easily eats much of your spare time!
I once got hold of 5-10 stickers that would trigger most shops alarm systems (the check points at the entry and exit points). It was a real laugh to put these stickers on peoples belongings and watch them set of alarms at the local mal...
Seriously, I think that it would become a problem to have these devices enabled after having been used. This requires the security system to verify that the mark is 'one of ours' before sounding the alarm. Kill the marker after the payment has been done and everything is plain sailing.
Mine said something like: "Well, it does indeed look like this php is better than asp, but as we use Office, we'll stick to what we know." so I'm stuck with Microsoft up mine... so to speak.
The commersial Qt version can run on Win32. If you have the dll you would (perhaps, maybe, haven't tried) be able to compile your exes using gcc in cross compilation mode from kdevelop, thus develop win32 apps in a linux environment...
I guess that this means that there are very few excuses for running win32 as a developer (besides propretary tools and evil managers...)
"Some of the features that I like best are the support for cross compilation..."
GCC can cross compile to win32, just buy the full Qt version and hack away!
QSA shows the great hidden abilites of the Qt toolkit. Hopefully the code will show how easy this is so that a free VBA compatible version will appear rendering all (non-viral) Windows scripts runnable in a free environment. This is one of the major things M$ Office has today, the scriptability. It is not great, not even good according to some (me) but it is there and works.
"As far as I am concerned, Internet adverts are just like magazine adverts. I don't notice those ones either (unlike TV adverts)."
You notice the lost time, especially when you're connected through a slow modem and pay by the minute... It is a huge bandwidth wasteage!
I'd actually pay more for a guarantee against banners and spam from my ISP.
"As far as I am concerned, Internet adverts are just like magazine adverts. I don't notice those ones either (unlike TV adverts)."
You notice the lost time, especially when you're connected through a slow modem and pay by the minute... It is a huge bandwidth wasteage!
I wasn't speeding, but apparently going too fast (as I aquaplaned). I went over a crest while going through a sharp curve and the rest is already known to you...
I learned two big things while doing this: 1) water is more dangerous than it seems, and 2) the value of a car compared to a human is neglectable, I am *really* glad noone got hurt!
Oh wait, I thought you smashed the car while at work for testing purposes...
Actually, it was my first job. I'd been working there alittle bit over one week when there was an urgent delivery needing care. Since the company cars were all used and I don't own a car I got to borrow my (quite new) boss' personal car...
I had my worst phone conversation ever when I had to tell him that I would come by train. "Could someone please pick me up?".
It took four months to replair the car. His fondest parts of the car were the rims; they were part of a limited edition. The problem with them is that in the process of smashing his car into pieces I crossed the side of the road. It was about one foot high and I hit it with the side first (luckily I did not flip the car). Two rims were jammed into the car, quite oddly shaped when removed, and the other two where ripped of the car and were never found.
As I said, the most embarissing thing I've ever done (this far). Nothing I recommend anyone trying at home!
You have to consider the ratio saved lives vs killed by missuse/accident. Most modern protection systems like airbags, seat belts, belt tensioners, ABSs, traction control systems, dynamic breaks, etc have a very good ratio, even though they cause problems. I would however not suggest using them the wrong way, collisions hold huge amounts of energy which can easily kill or deadly injure ignorant/badly informed/lazy individuals.
As for your suggestion about a law against stupid accidents. In Sweden there is a law against accidents, so if noone ever broke any rules, but still caused an accident, they will be punished. As for many of your examples, they are allready illegal (intoxicated driving, driving while using a cell phone, etc) and the rest are just things that one shouldn't do while driving.
I live in Sweden where seat belts are compulsory too, just as in the UK. This rule is the biggest life saver of them all, no airbag in the world saves you in a roll-over situation (which is quite common).
As for the force, I work at a company producing the inflators used in passenger side airbags and they are really powerful (the company name is Autoflator, a part of the Autoliv group). I have also smashed a car (aquaplaning... scary stuff) and I got hit pretty good by the airbag.
At least we agree on not wearing them!
You know what I mean, sorry for not being a native English speaker like you.
One big difference, stem-cells are just cells, without emotions, will and such (sole if you want to put it in one word, even though I do not belive in the sole idea).
An airbag inflator has the power of a hand granade. I would not like to carry such as device too close to the body. Also, what happens if I would wear a packpack, or have someone on join me on the bike (sitting behind me).
This device may look right, but how many lives will it save compared to those it take. Also, how do you dispose an explosive jacket, or take it with out on an aircraft. I'd say that this is probably a publicity stunt, and not really a life saver as airbags in cars are, but thats just MHO.
Sweden will probably be a source of stem cells. This solution has been suggested by Bush's administration.
"The intent of the project is to produce stem cells for medical research."
The benefits of this is to great to avoid doing it. If the cells are not cloned in the US, they will be bought from abroad, so the result will be the same anyway. Brave of Stanford to dare doing this in the US anyhow!
I must agree! User cases is the way to discuss software with users. You can draw user cases as in UML to make things really clear.
In mu profession I often write software to replace or complement older software. My applications are often used to reduce paperwork and to avoid doing things manually. To be able to do this in a good way, you need to know what your user does how and when and, idealy, why. This is why I often spend many hours letting the users explain their current work to me. When they are done, I put together a number of user cases trying to redescribe what they've explained to me and then schedule another meating. On the second meeting I try to explain what the user is supposed to do, and I explicitly as the user if this fits into the way they work. This process can take a few iterations 3-5 meetings (including the first 2), but always yeild good software and great user feedback.
It does not cost money, it costs time (which is money according to many).
SF does make money from the hosting, but still, there is no cost to the open source project, which is the point. I do not care too much about other peoples expenditures when discussing my economy.
Most open source projects goes live without _any_ budget. All that it takes is time (which is a cost for companies, but not for voluntary workers). As for servers and such, put a page on sourceforge, and try to get a few mirrors up and running too (they will come, if the project is attractive).
As for the actual release, try to make a good presentation about the project, what it is meant to do, where you want to go with the development, and encourage a developers community with a forum of some sort (mailing list), also, most open source projects must have screenshots (why, I don't know?).
If the project is attractive, and you work hard enough you'll gather a group of power users. These users are great, ask them what they want, how they want it, and tell them to talk to you about anything that bugs them. You'll need all the feedback you can get.
Finally, and most importantlly: do not expect to have others working for you, they may report bugs, send small patches, you'll have to do most work, at least in the beginning.
Ok, I admit I may have been a little too hard on his text. But the following quote from my reply sums things up:
"I'd say that the law of leaky abstractions is greatly exaggerated, but not entirely invalid. If you suffer from leaky abstractions you should concider changing tools or approach but not run away crying saying that abstraction is bad. Abstraction is a great tool, but as with all other tools it takes time to master. When used correcly it can reduce debugging time and increase the reusability. As a great example of code reuse I must point out that the TCP abstraction has saved thousands (if not millions) of source code lines. Just imagine if everyone had to rely on IP directly; How complex wouldn't the code be."
Leaky abstractions is not a problem in it self, the actual problem is that someone is using the wrong tools in the wrong situation.
I just had to recommend this. Great gameplay over network.
Please read this. It is my comments to TLoLA.
I've studied the Law of Leaky Abstactions during the weekend, and have come up with a list of comments. All these comments are of course MHO.
Mr. Spolsky argues that object orientation, or non trivil abstractions always leak, and that this is making programming unnecesarily hard. I would like to disagree. He starts his text by describing a very good abstraction that has been used and reused for many years in thousands of applications, the TCP layer, using the IP layer to provide easy message passing over the internet (or any other IP net by the way). He claims that the TCP abstraction leaks when, for example, a network cable breaks so that the communication cannot take place. I would like to say that this is a part of the abstraction: TCP connections can break. It is a natural part of a communications protocol and must be taken into account. TCP is, IMHO, a protocol used to send messages in one or more IP packages and to get them back they way I sent them. If the cable is broken, of course I do not expect my message to arrive. To put it in plain English, TCP allows me to send longer messages over a network and takes care of the splitting into packages and reassembly. That is all, it does not perfrom magic.
Mr. Splolsky goes on with a number of examples of leaking abstractions, I'll comment them one by one here:
Now, lets deal with the C++ string class. The example "foo" + "bar" is wrong. To declare a string constant, you should type string("foo") + string("bar"). This is just as odd as the declaration of long constants: 1L + 2L. I believe that the reason that C++ does not have a native string type is because C++ only knows scalar values (a string is a pointer which is a scalar value). This is due to the heritage from C.
He goes on rambling about accessing OUT LPTSTR arguments, COM objects, ASP.NET flaws etc. These are bad abstractions by Microsoft and should not be concidered useful examples. Then to compain about Visual BASIC failing now and then for non-basic related issues; I dare to call VB an ugly hack. It is not a real tool to be used in professional software development. I get frightened when I see how many business critical systems that are based on VB code.
Then he goes off topic (to use a /. expression). He starts to attack code generation tools and RADs. This is not abstraction, this is tools to allow people without the right competence and knowledge to try out programming. RADs are in fact _a_very_bad_thing_ as they encourages bad software development practice. They make it easy to forget how important it is to sitt down and thing before you start implementing.
The next thing to complain about is that you need to know more to develop software today than ten - fifteen years ago. I do not find this strange as we construct far more complex and interdependent systems today. This while spending less and less time on planning.
I'd say that the law of leaky abstractions is greatly exaggerated, but not entirely invalid. If you suffer from leaky abstractions you should concider changing tools or approach but not run away crying saying that abstraction is bad. Abstraction is a great tool, but as with all other tools it takes time to master. When used correcly it can reduce debugging time and increase the reusability. As a great example of code reuse I must point out that the TCP abstraction has saved thousands (if not millions) of source code lines. Just imagine if everyone had to rely on IP directly; How complex wouldn't the code be.
Abstraction helps us develop better, more complex software and avoid reinventing the wheel every five minutes!