Less than a hundred years ago scientists believed the brain worked a bit like a mechanical device and analogies were made to levers, cogs etc. The brain has always been likened to the most advanced piece of technology available at the time, and it's always turned out that it's way more advanced. I see no reason why that shouldn't be the case with all the silly computer analogies people come up with these days...
All big organisations deploying new systems need people to train their users. This would ideally be someone who can read technical documentation and understand how the system works.
I was at one point involved in writing a report on the deployment of a incident report system for the police, and was very surprised by how the users complained about how impractical the system was simply because they were doing it the wrong way. The reason for all this dissatisfaction was that they hadn't received the necessary training to successfully use the new system.
Put simply, all the effort you put into developing a great system is wasted if the users are not trained. You can see how important this job can be, and I'm sure there are organisations that see the value of this and pay people who can do this job what they deserve.
... If you spend some time with it you'll even come to love Visual Studio, particularly the debugger is worth getting to know. Knowing how to use a debugger separates the professionals from the amateurs, and the Visual Studio debugger is the best there is. If you're using C#, you can even use edit-and-continue efficiently (there is edit-and-continue for C++ also, but it's too limited to be very useful, YMMV).
BTW I'm also a mac user, but I do most of my development on windows because of how good Visual Studio is. XCode is getting there, but it still has a way to go - I don't envy the people at Adobe that had to build a huge app like Photoshop using it...
Holy shit! Maybe it's time to stop using printf()'s to debug your code and try to use the debugger in the IDE? The Visual Studio debugger is just so far ahead of anything else out there (for C++) it's not even funny.
Among the mobile phone makers, who hands out SDKs for creating applications on the phones?... I wouldn't even know where to start if I wanted to develop an application for my Sony Ericsson W910, call me clueless but I don't see anything comparable to the iPhone SDK for any other phone.
If you want to know the future of real-time graphics, look at what Pixar and other animation and special effects houses are doing. None of them are using ray-tracing except to achieve specific effects in specific circumstances. The fact is that global illumination combined with scanline renderers simply produce better pictures with less computational requirements.
Re:Progress in Computer Go
on
Cracking Go
·
· Score: 1
Do you know what an intractable problem is? I think it's common for people who haven't studied the theoretical underpinnings of computation to make the claim that any problem can be cracked by coming up with a better algorithm. It's simply not true. Of course Go is a finite problem, but you can get some idea about how likely it is that a better algorithm exist by looking at the general problem of certain parts of the game. For example Go Endgames Are PSPACE-Hard. You can also see how well computers solve tsumego (life and death status problems), which are key to becoming a strong player... Anyway, it takes a lot more time to come up with a better algorithm than to wait for computers to be faster, so if Moore's law is not going to help you it can take lifetimes before a better algorithm is discovered (if one even exists).
It's not true that MC scales nicely with additional computing power, first of all I have no idea where you got the 'fact' that 19x19 go needs 32x as much computing power from and second there are several papers that have investigated the scaling of MC algorithms for Go and concluded that the current methods all show diminishing return unlike Chess algorithms which gain strenght proportional to the computing resources you have.
Re:Here we go again...
on
Cracking Go
·
· Score: 2, Interesting
I'd say it's about pattern matching until you reach 1. dan, then you know almost all of the patterns and it becomes a game of high level strategic thinking.
Progress in Computer Go
on
Cracking Go
·
· Score: 5, Informative
I'm a reasonably strong Go player myself (4. dan) and I've studied computational complexity - my gut feeling is that computers will not beat humans at Go in my lifetime even if Moore's law continues to apply. The only possibility is that someone comes up with a completely new approach, a bit like when alpha-beta search was invented for Chess. At the moment the most interesting approach is Monte Carlo methods applied to Go which has so far lead to a gain of at least two stones strength for the current programs. The strongest Monte Carlo based program is currently MoGo by Sylvain Gelly et al. which you can find more information about at http://www.lri.fr/~gelly/MoGo.htm.
Someone mentioned this earlier in the thread, but it's really important. All good programmers I know use assertions liberally throughout their code. It will not only catch errors, but also serves to document the code as it makes the underlying assumptions clear to anyone looking at the code. Asserts are the C way of specifying preconditions, postconditions and invariants... Or to put it more simply, every time you think 'this pointer better not be NULL when entering this function' you do
assert(pointer != NULL && "You're a moron for calling this function with a NULL pointer!");
The && "comment" is a nice trick for having additional information when your assert fails...
Where I work, we use a naming convention similar to Hungarian, but the goal is a little different -- the point is to _enrich_ the C type system, so we use iVertex where the 'i' indicates it's an index (into an array) and nVertices where it's a number (the number of vertices in said array). We also separate between pVertex and paVertex to indicate if a pointer is to a single vertex or an array of vertices. Several other prefixes are also used to indicate for example that an int is really a bitfield 'b'.
I have a little experience with Haskell, extending a first order logic theorem prover as part of a university course. It's a beautiful language for research, but to write something like an A-title computer game (which I have done professionally) in a language like this is simply not possible with the tools that currently exist. It's extremely hard to predict the performance of a given piece of code, and there are no profilers or serious debuggers available. It can be extremely difficult to figure out someone else's code (because you can be exceedingly clever, which is brilliant when you're programming alone) so it's not really good for large teams. And finally, you'd have to develop your own bindings to all kinds of software libraries (OpenGL, MPI, physics solvers, compression libraries... ). In the end it's just not worth the hassle, with C++ you have way more mature tools and you can get the job done quicker.
Isn't all static type checking some kind of compile-time hack? I think you're completely misinformed about 'generics' in C++, as they are more like macros than anything else. C++ templates are nothing like a real type system which can be found in Haskell amongst others...
There's a lot of posts saying that multithreading is really hard, which is completely true... But what RapidMind is providing is something else, something more like a SIMD model or vector computations. It solves things like elementwise operations on large arrays in an efficient manner using whatever parallel computing resources are available. It's a language with a semantics that don't require complicated synchronisation because you're bascially telling the compiler which operations are independent and then it can go off and compute it in the most efficient way possible. RapidMind was designed to make GPGPU programming easy, so it's a generalisation of the pixel shader model where you have a lot of 'threads' computing the color of each pixel on the display in parallel. This is an easy problem, because there is basically no communication between threads.
Deciding how to allocate an object you create would better be left to the compiler. It's not a hard analysis to do to make sure the reference to an object never escapes a particular (possibly recursive) function call, and in that case the object can be allocated on the stack. Leaving this decision to the compiler makes sure that if someone changes the code you're calling so it suddenly starts to keep references to the objects that you've allocated on the stack and are passing in, it won't break. In big C/C++ programs, this kind of error is quite common since it takes a lot of time to track down all callers to a function you're modifying and understand their allocation patterns. Tracking down errors like this can be extremely time consuming and programming languages that allow these errors are in my opinion wasting valuable programmer time that could be spent optimising code instead.
... and _you_, my brave friend, have obviously not seen the state of C++ code written by competent professionals rushing to meet deadlines and fixing bugs at 2am in the morning. Anyway, a programming language so complex it can only be mastered by the top 5% of programmers after 5 years of education and then another 5 years of experience is probably not what you'd call 'well designed'.
yes, my example was made up as I typed so it would of course not compile. I though the reader would use their imagination to understand the problem I was hinting at instead of nitpicking about adding things like public: qualifiers which would have made the example longer. The point I was getting at is much better detailed in the C++ FAQ at http://www.parashift.com/c++-faq-lite/const-correc tness.html#faq-18.12 -- const overloading is very easy to get into trouble with because it breaks virtual overrides easily and without warning. It's a definite misfeature, and newer (and frankly better designed) programming languages like C# makes it impossible to make this mistake.
I think you're right, you have to know C or C++ intimately to be able to write correct code. C++ is a half-assed attempt to add modern features to C which results in an explosion in complexity. The thing is, C is not an easy language to program in because there is almost no protection against shooting yourself in the foot. Luckily C is pretty small and simple, and it is possible to understand the language well enough to be able to write a simple compiler after you've used it for a couple of years. Now C++ is pretty much impossible for one person to understand. Even the compiler writers find themselves struggling with the specification. If anyone still have doubts, have a look here http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_de fects.html for some eye-opening reading material...
I have quite a bit of experience with C++ and this example is just _one_ of a seemingly unending list of problems that bite the unwary C++ programmer. And without 10s of years of experience, there is _no way_ you can know about all of these. Some of my other 'favourites' are problems related to ordering of construction/destruction of static objects, virtual overrides becoming overloads without warning (try to change one of the arguments of a virtual function to be 'const' in the base class and what happens if you forget to do the same change to the override in some derived class?), all kinds of memory overwrite bugs caused by hanging on to pointers to memory that have been freed, being able to pass the address of an object on the stack out of a function (there is no excuse for this, the kind of program analysis done by optimising compilers could catch this easily -- the worst thing is the code often works at first but breaks much later when no-one has a clue where the bug is). And so on, and so forth...
Unfortunately the code I write is performance critical, so I have to put up with the nightmare that maintaining and extending a million line of code C++ project is...
I use C++ for my work, and I've been programming in C++ for many years. It's definitly a flawed language, in that even skilled experienced and careful programmers find themselves spending weeks tracking down bugs caused by memory overwrites and buffer overflows. Things that _will_ bite you with C++ are overloads of virtual methods (if someone changes the type of a parameter in the base class to be const, then suddenly your derived class is declaring a new overload not an override because it's not const...) forgetting to declare a destructor virtual so you leak some resource where you delete through a pointer with the base class type, and the list just goes on and on.
Add to this the build dependency nightmare that causes a simple change (say, adding a member to a class that's used a lot) to take 10-15 minutes to compile and you have a language that simply takes you longer to get the job done. And the most expensive side of software development is the man-hours it requires, not that you have to buy a newer faster computer to run the software - so programming in an 'efficient' language like C++ is just not the way to go for most projects. In fact the time you save writing in C# (or Java or Haskell for that matter) instead, can be used for performance profiling and finding better algorithms - so in the end you probably end up with a more efficient program anyway.
From my 20 years of experience developing software, I can tell you that 50% of the time is spent debugging code that doesn't do what you expect/want it to do. Still, most people go through university without even learning how to operate a debugger. In my opininon this is by far the biggest problem with CS education, coupled with the inexperience in working on big (>1 MLOC) projects. A suggestion would be to pick out some low-hanging bugs on a high profile open source project (there are always some simple bugs that are not serious enough to get fixed) and get the students to debug them, develop a patch (might be only a few lines of code) and get it submitted to the project. This way everyone wins, your students learn how a big project is operated and they do some good in the process.
Slashdot Mirror
Less than a hundred years ago scientists believed the brain worked a bit like a mechanical device and analogies were made to levers, cogs etc. The brain has always been likened to the most advanced piece of technology available at the time, and it's always turned out that it's way more advanced. I see no reason why that shouldn't be the case with all the silly computer analogies people come up with these days...
On your co-workers MackBookPro you can press Fn+Backspace to get delete. On a full keyboard you press the delete key.
All big organisations deploying new systems need people to train their users. This would ideally be someone who can read technical documentation and understand how the system works.
I was at one point involved in writing a report on the deployment of a incident report system for the police, and was very surprised by how the users complained about how impractical the system was simply because they were doing it the wrong way. The reason for all this dissatisfaction was that they hadn't received the necessary training to successfully use the new system.
Put simply, all the effort you put into developing a great system is wasted if the users are not trained. You can see how important this job can be, and I'm sure there are organisations that see the value of this and pay people who can do this job what they deserve.
... If you spend some time with it you'll even come to love Visual Studio, particularly the debugger is worth getting to know. Knowing how to use a debugger separates the professionals from the amateurs, and the Visual Studio debugger is the best there is. If you're using C#, you can even use edit-and-continue efficiently (there is edit-and-continue for C++ also, but it's too limited to be very useful, YMMV).
BTW I'm also a mac user, but I do most of my development on windows because of how good Visual Studio is. XCode is getting there, but it still has a way to go - I don't envy the people at Adobe that had to build a huge app like Photoshop using it...
Holy shit! Maybe it's time to stop using printf()'s to debug your code and try to use the debugger in the IDE? The Visual Studio debugger is just so far ahead of anything else out there (for C++) it's not even funny.
Among the mobile phone makers, who hands out SDKs for creating applications on the phones? ... I wouldn't even know where to start if I wanted to develop an application for my Sony Ericsson W910, call me clueless but I don't see anything comparable to the iPhone SDK for any other phone.
If you want to know the future of real-time graphics, look at what Pixar and other animation and special effects houses are doing. None of them are using ray-tracing except to achieve specific effects in specific circumstances. The fact is that global illumination combined with scanline renderers simply produce better pictures with less computational requirements.
Do you know what an intractable problem is? I think it's common for people who haven't studied the theoretical underpinnings of computation to make the claim that any problem can be cracked by coming up with a better algorithm. It's simply not true. Of course Go is a finite problem, but you can get some idea about how likely it is that a better algorithm exist by looking at the general problem of certain parts of the game. For example Go Endgames Are PSPACE-Hard. You can also see how well computers solve tsumego (life and death status problems), which are key to becoming a strong player... Anyway, it takes a lot more time to come up with a better algorithm than to wait for computers to be faster, so if Moore's law is not going to help you it can take lifetimes before a better algorithm is discovered (if one even exists).
It's not true that MC scales nicely with additional computing power, first of all I have no idea where you got the 'fact' that 19x19 go needs 32x as much computing power from and second there are several papers that have investigated the scaling of MC algorithms for Go and concluded that the current methods all show diminishing return unlike Chess algorithms which gain strenght proportional to the computing resources you have.
I'd say it's about pattern matching until you reach 1. dan, then you know almost all of the patterns and it becomes a game of high level strategic thinking.
I'm a reasonably strong Go player myself (4. dan) and I've studied computational complexity - my gut feeling is that computers will not beat humans at Go in my lifetime even if Moore's law continues to apply. The only possibility is that someone comes up with a completely new approach, a bit like when alpha-beta search was invented for Chess. At the moment the most interesting approach is Monte Carlo methods applied to Go which has so far lead to a gain of at least two stones strength for the current programs. The strongest Monte Carlo based program is currently MoGo by Sylvain Gelly et al. which you can find more information about at http://www.lri.fr/~gelly/MoGo.htm.
Someone mentioned this earlier in the thread, but it's really important. All good programmers I know use assertions liberally throughout their code. It will not only catch errors, but also serves to document the code as it makes the underlying assumptions clear to anyone looking at the code. Asserts are the C way of specifying preconditions, postconditions and invariants... Or to put it more simply, every time you think 'this pointer better not be NULL when entering this function' you do
assert(pointer != NULL && "You're a moron for calling this function with a NULL pointer!");
The && "comment" is a nice trick for having additional information when your assert fails...
Where I work, we use a naming convention similar to Hungarian, but the goal is a little different -- the point is to _enrich_ the C type system, so we use iVertex where the 'i' indicates it's an index (into an array) and nVertices where it's a number (the number of vertices in said array). We also separate between pVertex and paVertex to indicate if a pointer is to a single vertex or an array of vertices. Several other prefixes are also used to indicate for example that an int is really a bitfield 'b'.
I have a little experience with Haskell, extending a first order logic theorem prover as part of a university course. It's a beautiful language for research, but to write something like an A-title computer game (which I have done professionally) in a language like this is simply not possible with the tools that currently exist. It's extremely hard to predict the performance of a given piece of code, and there are no profilers or serious debuggers available. It can be extremely difficult to figure out someone else's code (because you can be exceedingly clever, which is brilliant when you're programming alone) so it's not really good for large teams. And finally, you'd have to develop your own bindings to all kinds of software libraries (OpenGL, MPI, physics solvers, compression libraries... ). In the end it's just not worth the hassle, with C++ you have way more mature tools and you can get the job done quicker.
Isn't all static type checking some kind of compile-time hack? I think you're completely misinformed about 'generics' in C++, as they are more like macros than anything else. C++ templates are nothing like a real type system which can be found in Haskell amongst others...
There's a lot of posts saying that multithreading is really hard, which is completely true... But what RapidMind is providing is something else, something more like a SIMD model or vector computations. It solves things like elementwise operations on large arrays in an efficient manner using whatever parallel computing resources are available. It's a language with a semantics that don't require complicated synchronisation because you're bascially telling the compiler which operations are independent and then it can go off and compute it in the most efficient way possible. RapidMind was designed to make GPGPU programming easy, so it's a generalisation of the pixel shader model where you have a lot of 'threads' computing the color of each pixel on the display in parallel. This is an easy problem, because there is basically no communication between threads.
Deciding how to allocate an object you create would better be left to the compiler. It's not a hard analysis to do to make sure the reference to an object never escapes a particular (possibly recursive) function call, and in that case the object can be allocated on the stack. Leaving this decision to the compiler makes sure that if someone changes the code you're calling so it suddenly starts to keep references to the objects that you've allocated on the stack and are passing in, it won't break. In big C/C++ programs, this kind of error is quite common since it takes a lot of time to track down all callers to a function you're modifying and understand their allocation patterns. Tracking down errors like this can be extremely time consuming and programming languages that allow these errors are in my opinion wasting valuable programmer time that could be spent optimising code instead.
Advanced Compiler Design and Implementation by Steven Muchnick is a good book in my opinion. Did you try that?
... and _you_, my brave friend, have obviously not seen the state of C++ code written by competent professionals rushing to meet deadlines and fixing bugs at 2am in the morning. Anyway, a programming language so complex it can only be mastered by the top 5% of programmers after 5 years of education and then another 5 years of experience is probably not what you'd call 'well designed'.
yes, my example was made up as I typed so it would of course not compile. I though the reader would use their imagination to understand the problem I was hinting at instead of nitpicking about adding things like public: qualifiers which would have made the example longer. The point I was getting at is much better detailed in the C++ FAQ at http://www.parashift.com/c++-faq-lite/const-correc tness.html#faq-18.12 -- const overloading is very easy to get into trouble with because it breaks virtual overrides easily and without warning. It's a definite misfeature, and newer (and frankly better designed) programming languages like C# makes it impossible to make this mistake.
I think you're right, you have to know C or C++ intimately to be able to write correct code. C++ is a half-assed attempt to add modern features to C which results in an explosion in complexity. The thing is, C is not an easy language to program in because there is almost no protection against shooting yourself in the foot. Luckily C is pretty small and simple, and it is possible to understand the language well enough to be able to write a simple compiler after you've used it for a couple of years. Now C++ is pretty much impossible for one person to understand. Even the compiler writers find themselves struggling with the specification. If anyone still have doubts, have a look here http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_de fects.html for some eye-opening reading material...
... and now explain how using the 'const' keyword interacts with overloading functions and how it works with templates
class A { virtual void f(const A *pA); }
class B : public A { void f(A *pA); }
quick, which functions are the following calling?
A *p = new B(); p->F(p);
const A *p = new B(); p->F(p);
B *p = new B(); p->F(p);
const B *p = new B(); p->F(p);
And that's just overloads...
I have quite a bit of experience with C++ and this example is just _one_ of a seemingly unending list of problems that bite the unwary C++ programmer. And without 10s of years of experience, there is _no way_ you can know about all of these. Some of my other 'favourites' are problems related to ordering of construction/destruction of static objects, virtual overrides becoming overloads without warning (try to change one of the arguments of a virtual function to be 'const' in the base class and what happens if you forget to do the same change to the override in some derived class?), all kinds of memory overwrite bugs caused by hanging on to pointers to memory that have been freed, being able to pass the address of an object on the stack out of a function (there is no excuse for this, the kind of program analysis done by optimising compilers could catch this easily -- the worst thing is the code often works at first but breaks much later when no-one has a clue where the bug is). And so on, and so forth...
Unfortunately the code I write is performance critical, so I have to put up with the nightmare that maintaining and extending a million line of code C++ project is...
I use C++ for my work, and I've been programming in C++ for many years. It's definitly a flawed language, in that even skilled experienced and careful programmers find themselves spending weeks tracking down bugs caused by memory overwrites and buffer overflows. Things that _will_ bite you with C++ are overloads of virtual methods (if someone changes the type of a parameter in the base class to be const, then suddenly your derived class is declaring a new overload not an override because it's not const ...) forgetting to declare a destructor virtual so you leak some resource where you delete through a pointer with the base class type, and the list just goes on and on.
Add to this the build dependency nightmare that causes a simple change (say, adding a member to a class that's used a lot) to take 10-15 minutes to compile and you have a language that simply takes you longer to get the job done. And the most expensive side of software development is the man-hours it requires, not that you have to buy a newer faster computer to run the software - so programming in an 'efficient' language like C++ is just not the way to go for most projects. In fact the time you save writing in C# (or Java or Haskell for that matter) instead, can be used for performance profiling and finding better algorithms - so in the end you probably end up with a more efficient program anyway.
From my 20 years of experience developing software, I can tell you that 50% of the time is spent debugging code that doesn't do what you expect/want it to do. Still, most people go through university without even learning how to operate a debugger. In my opininon this is by far the biggest problem with CS education, coupled with the inexperience in working on big (>1 MLOC) projects. A suggestion would be to pick out some low-hanging bugs on a high profile open source project (there are always some simple bugs that are not serious enough to get fixed) and get the students to debug them, develop a patch (might be only a few lines of code) and get it submitted to the project. This way everyone wins, your students learn how a big project is operated and they do some good in the process.