You can use CORBA, or XML to communicate between your Fortran application, and any other code that you may write. That way, you can get the best of
both worlds. I wouldn't give up so fast on C++/Java though. Investigate those languages more thoroughly before you decide to code in Fortran.
That was a great speech. It reminded me of the old John Belushi bit on SNL, where he would give an editorial, and get more and more worked up, and finally go nuts and scream and yell incoherently.
There was actually a lot of interesting stuff in that speech, some of which was true, some of which was not, and much of which was just incoherent ranting, but who wants to hear the same viewpoint over and over?
I have used GnuGo, and examined the source code.
Although it does not play a bad game, it is certainly not an easy program to modify. It would not be an easy task for a casual developer to come along and add additional functionality. It is certainly not designed to allow the same functionality to be coded in different ways, or to allow different building blocks to be assembled differently. My main reason for rejecting GnuGo is that, unlike most other problem domains, people don't really know how to build a good Go program. The ability to try different techniques and experiment will be vital. I do not believe that GnuGo provides this, but I do not mean to disparage that project in any way, because they have done extremely high quality work given the limits of coding in C.
I have been considering starting an open-source Go project in a few months (after I get laid off and have some time). Here are some of my thoughts.
Writing a Go program may not be exceptionally difficult. It is just a very large problem. Most previous attempts were done by one or two people, in an attempt to have a commercial success. A large team of people would be required. Probably, this could only be done within an open-source framework.
There might be some things that can be learned from Chess programs, for example how to solve Life and Death problems, but a completely different approach will be needed.
I believe that people have attempted to solve the wrong problem. The problem is not
How can I find the next move on an arbitrary board with n stones?
but,
How can I find the next move from a board with n stones which I have already analyzed?
If you are a Go player, you know that in the middle game, you can usually come up with a decent move within a few seconds, but if you walk over to a game being played by other people in the middle game, it would probably take you several minutes of intense thought to analyze the board, figure out what is alive and what is dead, and who is ahead. Therefore, the program needs to save its state between moves. Figuring out the next move should then be MUCH easier.
Most open-source programs are designed by one or a few people, and then outsiders either just fix bugs, or add additional functionality within the current design. For a Go program to have a decent chance of achieving dan level play, not only does it have to be open-source, but open-design.
Assume that a framework exists, and that modules which perform discrete tasks can be plugged into this framework. A standard interface is defined for each module. There would be modules for fuseki, joseki, life and death, etc. The overall framework which would perform multi-threading, saving of state, communication between modules and the client could be designed and coded by one person. But each of the Go specific modules could be designed and coded by a different person. Modules such as Life and Death are probably straightforward, but what about a module that determines good and bad shape? Many different people would have different ideas of how to do this. The framework should allow multiple competing shape modules to be written. They should be interchangeable, so that any of them can easily be plugged into the framework.
In this way, many people can take part in the design of the system. There would be no political fights over how a shape module should be implemented. Different people can write their own, and the one that performs the best within the framework would be used.
Using this set of ideas, I believe that a small subset of the many people who both play Go and are software developers could develop software far better than anything now existing.
I intend to have such a framework implemented by the spring of 2003. I have not posted anything online yet. If you might be interested in participating, feel free to email me at dweiss51@yahoo.com.
To put this more succinctly, in addition to the higher branching factor, coming up with a decent static evaluation function is even more difficult. The tree size could be dealt with eventually, but it is extremely unlikely that there is a decent static evaluation function like for Chess. The DeepBlue static evaluation function only evaluates four different aspects of the game. Try that in Go.
Maybe it would be more useful for the toaster
to control the Commodore 64, rather than the other
way around. You would need a 24 slice toaster;
16 slices to select the address in the 64K memory, and
8 slices to do the pokes, and display the peeks.
Just like the good old days with toggle switches
on the front panel.
It can be very difficult making the transition from software developer to project lead. You assume that because you are competent and motivated that others are the same. Here are some steps that might help you.
First, assess peoples skill and motivation levels. Senior, well-motivated people can be checked on every month or so. Less competent or motivated people may need to be checked on every day.
Give people as much respect as they deserve, but no more. If some people don't do a very good job, make sure that you have frequent code reviews. If they are unwilling to accept criticism from the more experienced people and do the job right, don't be afraid to yell. With an ideal team, motivation is not a problem. With problem cases, don't let it slide. Don't be afraid to point out to them that there are hundreds of more qualifed unemployed software people who would be happy to have their jobs.
Make sure that you have a good process in place. I don't mean anything bureaucratic, but make sure that you do design reviews and code reviews. Make them write something up. Get a definition of the api for the module. Review all code that is written. Require that a test plan, and possibly test code is developed. By implenting a system of reviews, mentoring can be done, and teamwork developed.
If you read the article, the Java developers are in agreement that there is a severe job shortage. It is some of the people that are hiring that claim that there isn't a job shortage, including one imbecile who thinks that some obscure gui functionality is the mark of a REAL Java developer.
The people that I know who are senior Java developers are working on back-end code using J2EE.
There are no jobs for Java developers in the Denver area. Qwest pretty much took care of that.
I am sure that a government with the resources and technical knowhow of the US government could cause a catastrophic failure of much of our critical infrastructure through software. I do not know how many other governments or organizations also have this ability. It is good that someone is publicizing this threat. Do we want to wait for a catastrophe to happen before taking this seriously?
I assume that most/.ers know about the liquid oxygen in the barbeque bit, but in case you don't, check out http://ghg.ecn.purdue.edu/~ghg.
This site has an MPEG file of the meltdown.
How about unrolling giant tv screens on the battlefield, and then showing videos of trucks and men moving by. Then the enemy can shoot at the tv images of soldiers and knock them out one by one. Great decoy.
I realize that people just want to make jokes, but if a car was using Linux, the car manufacturer would take some release as a starting point, and then customize the code for their application. It would fit the job that it was asked to do perfectly, because it would be custom modified for the job.
The fact that the code base would split off from the mainstream Linux distributions would not matter because this is not a computer, it is a car, and future Linux enhancements would likely be largely irrelevant to the car manufacturer.
How about the fact that Intel is going to put a radio on every chip? The article doesn't say if it only receives, or can broadcast as well (spyware anyone?).
Now, if they were talking about a petabyte, you might have a point.
If they were talking about a petabyte, then you could keep all of the scientific satellite data
being sent down (terabytes daily) for awhile on one disk. Even a petabyte isn't enough for some purposes.
Make sure that you write down any 800 numbers
that are displayed. Call them up and tell them
that they ruined your show, and you will never buy anything from them.
I am not sure why so many comments say that the new cars must look like the old cars, or that if a design has been the same for a hundred years, it is a mistake to change it.
As long as the cars look good, who cares if they aren't exactly the same as cars today? Computer keyboards look different than typewriters. Refrigerators, televisions, etc have all undergone massive design changes during their lifetimes.
It sounds like GM has learned from the mistakes of the past, and are trying to do some really cool stuff. I know that this is hard to believe, but if they are spending a billion bucks, they aren't doing this as a public relations effort.
The promise of the Internet for all sorts of businesses was to get rid of the middle man.
Clearly, there are few businesses where the
middle man is more of a problem than the music
industry. It may not be that much longer before
relatively well-known artists start distributing
their work that way. Then, the record executives
will be forced to change or die.
Also, one would imagine that for what Norway was paying the Evil Empire, they could hire more than enough engineers to perform whatever modifications need to be performed to bring Linux up to their requirements.
Slashdot Mirror
You can use CORBA, or XML to communicate between your Fortran application, and any other code that you may write. That way, you can get the best of both worlds. I wouldn't give up so fast on C++/Java though. Investigate those languages more thoroughly before you decide to code in Fortran.
There was actually a lot of interesting stuff in that speech, some of which was true, some of which was not, and much of which was just incoherent ranting, but who wants to hear the same viewpoint over and over?
Hey, I don't mind the rest of it, but don't be criticizing the bouncing boobs.
I believe that he is one of the many clones of Linus Torvalds. Linus finally got tired of hearing that he didn't scale.
I have used GnuGo, and examined the source code. Although it does not play a bad game, it is certainly not an easy program to modify. It would not be an easy task for a casual developer to come along and add additional functionality. It is certainly not designed to allow the same functionality to be coded in different ways, or to allow different building blocks to be assembled differently. My main reason for rejecting GnuGo is that, unlike most other problem domains, people don't really know how to build a good Go program. The ability to try different techniques and experiment will be vital. I do not believe that GnuGo provides this, but I do not mean to disparage that project in any way, because they have done extremely high quality work given the limits of coding in C.
Writing a Go program may not be exceptionally difficult. It is just a very large problem. Most previous attempts were done by one or two people, in an attempt to have a commercial success. A large team of people would be required. Probably, this could only be done within an open-source framework.
There might be some things that can be learned from Chess programs, for example how to solve Life and Death problems, but a completely different approach will be needed.
I believe that people have attempted to solve the wrong problem. The problem is not
but, If you are a Go player, you know that in the middle game, you can usually come up with a decent move within a few seconds, but if you walk over to a game being played by other people in the middle game, it would probably take you several minutes of intense thought to analyze the board, figure out what is alive and what is dead, and who is ahead. Therefore, the program needs to save its state between moves. Figuring out the next move should then be MUCH easier.Most open-source programs are designed by one or a few people, and then outsiders either just fix bugs, or add additional functionality within the current design. For a Go program to have a decent chance of achieving dan level play, not only does it have to be open-source, but open-design.
Assume that a framework exists, and that modules which perform discrete tasks can be plugged into this framework. A standard interface is defined for each module. There would be modules for fuseki, joseki, life and death, etc. The overall framework which would perform multi-threading, saving of state, communication between modules and the client could be designed and coded by one person. But each of the Go specific modules could be designed and coded by a different person. Modules such as Life and Death are probably straightforward, but what about a module that determines good and bad shape? Many different people would have different ideas of how to do this. The framework should allow multiple competing shape modules to be written. They should be interchangeable, so that any of them can easily be plugged into the framework. In this way, many people can take part in the design of the system. There would be no political fights over how a shape module should be implemented. Different people can write their own, and the one that performs the best within the framework would be used.
Using this set of ideas, I believe that a small subset of the many people who both play Go and are software developers could develop software far better than anything now existing.
I intend to have such a framework implemented by the spring of 2003. I have not posted anything online yet. If you might be interested in participating, feel free to email me at dweiss51@yahoo.com.
To put this more succinctly, in addition to the higher branching factor, coming up with a decent static evaluation function is even more difficult. The tree size could be dealt with eventually, but it is extremely unlikely that there is a decent static evaluation function like for Chess. The DeepBlue static evaluation function only evaluates four different aspects of the game. Try that in Go.
Does it only work on mosquitos and roaches, or will it debug your software as well?
Maybe it would be more useful for the toaster to control the Commodore 64, rather than the other way around. You would need a 24 slice toaster; 16 slices to select the address in the 64K memory, and 8 slices to do the pokes, and display the peeks. Just like the good old days with toggle switches on the front panel.
First, assess peoples skill and motivation levels. Senior, well-motivated people can be checked on every month or so. Less competent or motivated people may need to be checked on every day.
Give people as much respect as they deserve, but no more. If some people don't do a very good job, make sure that you have frequent code reviews. If they are unwilling to accept criticism from the more experienced people and do the job right, don't be afraid to yell. With an ideal team, motivation is not a problem. With problem cases, don't let it slide. Don't be afraid to point out to them that there are hundreds of more qualifed unemployed software people who would be happy to have their jobs.
Make sure that you have a good process in place. I don't mean anything bureaucratic, but make sure that you do design reviews and code reviews. Make them write something up. Get a definition of the api for the module. Review all code that is written. Require that a test plan, and possibly test code is developed. By implenting a system of reviews, mentoring can be done, and teamwork developed.
The people that I know who are senior Java developers are working on back-end code using J2EE.
There are no jobs for Java developers in the Denver area. Qwest pretty much took care of that.
I am sure that a government with the resources and technical knowhow of the US government could cause a catastrophic failure of much of our critical infrastructure through software. I do not know how many other governments or organizations also have this ability. It is good that someone is publicizing this threat. Do we want to wait for a catastrophe to happen before taking this seriously?
I assume that most /.ers know about the liquid oxygen in the barbeque bit, but in case you don't, check out http://ghg.ecn.purdue.edu/~ghg.
This site has an MPEG file of the meltdown.
How about unrolling giant tv screens on the battlefield, and then showing videos of trucks and men moving by. Then the enemy can shoot at the tv images of soldiers and knock them out one by one. Great decoy.
Plus, your car will probably require triple-bypass surgery every 50,000 miles.
The fact that the code base would split off from the mainstream Linux distributions would not matter because this is not a computer, it is a car, and future Linux enhancements would likely be largely irrelevant to the car manufacturer.
OK, back to the jokes.
How about the fact that Intel is going to put a radio on every chip? The article doesn't say if it only receives, or can broadcast as well (spyware anyone?).
If they were talking about a petabyte, then you could keep all of the scientific satellite data being sent down (terabytes daily) for awhile on one disk. Even a petabyte isn't enough for some purposes.
Make sure that you write down any 800 numbers that are displayed. Call them up and tell them that they ruined your show, and you will never buy anything from them.
As long as the cars look good, who cares if they aren't exactly the same as cars today? Computer keyboards look different than typewriters. Refrigerators, televisions, etc have all undergone massive design changes during their lifetimes.
It sounds like GM has learned from the mistakes of the past, and are trying to do some really cool stuff. I know that this is hard to believe, but if they are spending a billion bucks, they aren't doing this as a public relations effort.
The promise of the Internet for all sorts of businesses was to get rid of the middle man. Clearly, there are few businesses where the middle man is more of a problem than the music industry. It may not be that much longer before relatively well-known artists start distributing their work that way. Then, the record executives will be forced to change or die.
Also, one would imagine that for what Norway was paying the Evil Empire, they could hire more than enough engineers to perform whatever modifications need to be performed to bring Linux up to their requirements.
Yes, preferably one with large breasts.
I think that Microsoft is very bad. How come noone on /. has noticed this before?
How about an automated tool that would view ads in the background, and get those click counts up, but without having to view those annoying ads?