What you describe is the common configuration, where one developer becomes a code primadonna. He (or she) will be the only one who really understands the system and everyone else just try to work around the primadonna and avoid getting in his or hers way. This is very bad because
1. You become *way* to dependent on the primadonna.
2. You don't get near full benefit of the rest of the team.
3. You will get a high staff turn-over because noone can tolerate a primadonna in the long run.
If you have a small to medium sized team (\10 developers) processes like XP will keep your developers producing quality code fast and happy at the same time.
Yes... Lets try to introduce another web technology. (Sarcasm!!)
Everyone and their momma want their new and old software to be "web-enabled". What a great idea - someone invents a great concept for browsing hypertext documents with images, and hey... ho we all find ourselves being forced to develop applications for it! Of course web browsers, being web browsers, were never intended for running applications so the market place is now plastered with different technologies to make the web browser a better platform for.. you name it!
I hate developing for the web for two reasons primarily:
1. The user experience is seldom exactly what you want because, well.. web browsers are web browser - hypertext and images, remember! Good thing someone invented the web - writing gopher applications would probably stink even more.
2. You write the GUI in HTML or XML/XSL whatever, then you have your clientside scripting in javascript or vbscript. The server side is implemented in [customers bizar language requirement here]. Of course, as you are writing a state-of-the-art distributed application you use.... good-ol' one-way http for communication. WHAT A MESS! You have to master all these technologies and the tools/testing frameworks/IDEs to work with them. Good riddens
The way I see it, there is no point in punishing yourself with a diet for 4 months to loose weight. Or exercising like hell for a few months. The only thing that works is to turn your lifestyle around - and just a little will help.
* Ride a bike to work
* Stop eating candy - Quit cold turkey and you wont miss it at all in a short while
* Start playing tennis, soccer, basket, or swim.
Merry Christmas to all
on
Merry Christmas
·
· Score: 3, Redundant
..that celebrates christmas!
- and wishes of peace, harmony and tolerance towards all that do not.
Make sure that everything you write yourself is covered by unit tests. This will catch many problems with the open-source libraries and components you use, but another important benefit in this context is, that it allows you to refactor your code and replace one library with an alternative implementation with confidence.
As an XP developer I take a serious interest in unit testing, so I browsed the site - claims claims claims, but no details... I perused their PDF white paper - more claims and absolutely no specifics.
If they can't explain exactly what you get with QMTest in a few paragraphs, then it is probably not worth my time. Thankfully I'm already quite pleased with JUnit, RubyUnit and CppUnit.
However, if other slashdot readers have more patience with the project - I encourage them to write a summary of their findings here!
If you like Python you will love ruby. Its syntax is imho much nicer and ruby is true OO. There are many technical reasons to like it, but the really great thing is how it is really easy to express yourself in. Unfortunately Ruby is not really as popular outside Japan as it deserves. Check out the pragmatic programmers book and give it a whirl.
I'm right. Java is a fad, not worth much more than the Windows OS in terms of quality, and my CS faculty
I think most people in the./ camp have finally come to the point, where they no longer bash Windows from the technical stand point, and with good reason. Anyway, there are lots of other reasons to bash MS and Windows, so I suggest you train you gun at something worth the ammo.
As I post this, numerous posters have already suggested C/C++ as their choice as a first language. This leads me to believe that they have little experience with at least one of the two languages, since they seem to believe that they are so similar that they should to be mentioned together in this context. C is almost a subset of C++, but C++ is much more expressive, much bigger and much harder to learn for a novice CS student. Being a good C++ programmer is definitely not the same as being good at C, and the other way around.
Finally, I think both of them suck as a first language, because they don't let you focus on you OO design and program logic - Java is much better for that. We are talking introductory stuff and first language, so lets concentrate on the important stuff and save the complications of reality for the next course.
My personal feeling is that Java is clunky, ugly, and runs much too slow on most platforms
Clunky and ugly? Compared to what? The language is pretty clean OO (as opposed to C), and clean and simple (as opposed to C++). This makes it an excellent candidate compared to those two languages for learning OOP, right? Your last point about runtime performance has little to do with how useful it is as a teaching language. Believe me, if you are going to be serious about programming, you are going to learn plenty of languages, but few are as clean and suitable for OOP education as Java.
Actually C++ is a multi-paradigm language which includes OO features. I wouldn't recommend it, especially if your experience is with VB, because you are likely to benefit from working with a less powerful, more OO-centric language, so you are less likely to develop strange styles and bad habits. Then, when you have developed a sound OO understanding and coding practice, you can move on to C++.
... and why you've omitted to mention any functional languages like the assorted lisps & schemes.
Because I have no real experience with these languages, but I can see why that is not an obvious answer to you - after all this is slashdot, the place where everybody feels they are experts, just because they know a few acronyms and can write "Hello World" (but not much else) in seven odd languages.
It also makes it blindingly obvious that you don't know your emacs modes from your elbow, too.
You are probably right, emacs is the kitchen sink tool, that does it all, better than more modern tools tailor made for their specific purpose. Yes - you definitely qualify as "one of those guys that give open source, linux etc a bad rep". I still use emacs for many things, because the editor in JBuilder isn't powerful enough, but that doesn't mean that the IDE doesn't provide a lot of great stuff that you don't get with emacs.
I can't believe you ask the slashdot community. Most of the guys here think C is a great language for application development and they think emacs, gcc and possibly a few xterm's is what it takes to make them the most efficient developers. Fact of the matter is that many of them have never done any serious work in an IDE using a higher level language such as C++, Java or Python. Unfortunately that doesn't keep them from offering their opinions about emacs vs IDEs and C for developing applications quite loudly!
Java is a great language, and there are several very good IDEs available for Linux. I have used JBuilder professionally for 8 months now - before that I used emacs exclussively, but I'm not going back now! JBuilder is top notch but lacks a great refactoring browser. I know you can buy a refactoring tool called jfactor that plugs into VisualAge, so if that's important to you, then maybe you should try that.
I've worked on both sides of the pond (Cupertino, California, U.S and Copenhagen, Denmark), and while the hours in the U.S. are definitely longer, the pace is slower, so in my experience the end productivity is about the same.
We have all witnessed the massive improvement of the visual realism of the first person shooters in the last few years. However the means of interaction is not only limited by crude I/O devices like screens and mice, but also be the shear complexity it takes to really simulate a world with convincing interaction that goes beyond running around, pushing buttons, riding elevators and shooting shootable stuff? Do you see any solution to these problems? How about massive parallel systems? I know you are a multiprocessing believer - do you see any signs of the industry moving towards mp systems?
Personally, I believe the SMP support in Q3A will do the same for SMP systems as glquake did for OpenGL support. Do you plan to put further effort into exploiting mp systems in your next project(s)?
The Geforce 256 and further generations of accelerators (will) allow a great increase in model details in terms of texture detail and in particular in terms of polygonal detail - Wont this mean that future games will require many more artists and modelers? I mean, if the model complexity increases with an order of magnitude wont this increase have a severe impact on the time it takes to create a single model? How will this reflect on Ids development model with so few artists? Creating highly complex models and textures seems like an extremely scalable task suitable for open source development. Do you see Open Source projects as a potential competitor in the future? Do you see a way for Id to make business and use the wast potential of open source development for art and perhaps code?
But a lot of what you are saying is just plain wrong. For starters the summary you link to was posted to the friends of performer mailing list by an SGI employee - and you expect objectivity from that source?
Also, you disagree that SGI's graphic solutions aren't cost-effective compared to consumer 3D boards - even SGI wouldn't risk such as statement (_they_ would realize it would make them look stupid). SGI's target market is only a tiny fraction of the consumer market in terms of the number of products sold, so there's a good reason for this.
But SGI's product is not only being superceded in terms of cost effectiveness. SGI's base reality and Infinite Reality (2) systems are not that impressive compared to the consumer boards. The Nvidia GeForce even has a higher polyrate than the single-pipe IR2, and it certainly has a very comparable fill rate (faster or slower depending on the number of raster managers).
There's nothing that drives product development as fast as the consumer market competion. SGI has faced this reality, why wont you?
What SGI has, but you fail to mention at all (perhaps because it is a _valid_ point), is slightly more features, like 3D textures and multi-sampling (for e.g. anti-aliasing).
Now, about the use of SGI worksstations for making special effects in movies. This has nothing to do with SGI hardware at all - Computer animations in movies are based on raytracing techniques, which to my knowledge are done entirely in software. Nobody is disputing that SGI has the expertise when it concerns graphics - but many are (correctly, imho) disputing that SGIs hardware will be able to stay ahead of the consumer products unless they do something radical. SGI sees the same thing and have formed a strategic alliance with the 3D consumer market leader Nvidia - SGI will built their future hardware using the same chips as consumer boards, only SGI will put them to work in parallel, like some company did with the Voodoo(2) chipset
Linux is not an alternative to SGI yet - the OpenGL hardware support is not solid enough yet, but we're getting there, partially thanks to SGI! Additionally the software isn't there yet either, but we're getting there. For instance SGI(!) is porting performer to linux!
SGI is a cool company with a _lot_ of engineering talent. They really don't need you to spread FUD - Now that the bosses have woken up and demonstrated that they do have the guts to make truly radical changes like adopting linux as a key element in their strategy, they'll make it just fine.
> It's really too bad we don't have something like Glide (really easy to program to), but open, not 'only 3dfx' crap
That's a common but very misguided opinion. Glide is a rasterization only API and is pretty much rendered obsolete by the addition of transformation and lighting to the hardware. Of course Glide could be extended to encompass this part of the pipeline as well, but what would be the point - OpenGL already does that. With DX7 D3D will get there too.
> I'm eagerly awaiting the new generation. But I expect the real crazy stuff to start happening in the following generation... > it may be finally time to kill some very old paradigms in 3d hardware...
I'd be interested to hear your thoughts on what might replace the current paradigm. Are you thinking voxel-based rendering techniques?
Am I wrong when I state that the amount of research (even recent!) devoted to rendering techniques based on the current paradigm dwarfs the effort put into researching more innovative approaches to rendering?
Actually this is pretty big news. Up till this point fill rate has been all that mattered for 3D chip makers, providing the capability of allowing higher resolutions, more rendering passes (for different visual effects) and higher frame rates. This is the first (consumer level?) chip to add transformation and lightning to the 3D chip, thus offloading these duties from the CPU. This effectively means more polygons can be used and this will have a truely remarkable effect on the realism.
Aren't you tired of watching perfectly flat walls with big posters stuck on them?
What you describe is the common configuration, where one developer becomes a code primadonna. He (or she) will be the only one who really understands the system and everyone else just try to work around the primadonna and avoid getting in his or hers way. This is very bad because
1. You become *way* to dependent on the primadonna.
2. You don't get near full benefit of the rest of the team.
3. You will get a high staff turn-over because noone can tolerate a primadonna in the long run.
If you have a small to medium sized team (\10 developers) processes like XP will keep your developers producing quality code fast and happy at the same time.
Yes ... Lets try to introduce another web technology. (Sarcasm!!)
.. you name it!
.... good-ol' one-way http for communication. WHAT A MESS! You have to master all these technologies and the tools/testing frameworks/IDEs to work with them. Good riddens
Everyone and their momma want their new and old software to be "web-enabled". What a great idea - someone invents a great concept for browsing hypertext documents with images, and hey... ho we all find ourselves being forced to develop applications for it! Of course web browsers, being web browsers, were never intended for running applications so the market place is now plastered with different technologies to make the web browser a better platform for
I hate developing for the web for two reasons primarily:
1. The user experience is seldom exactly what you want because, well.. web browsers are web browser - hypertext and images, remember! Good thing someone invented the web - writing gopher applications would probably stink even more.
2. You write the GUI in HTML or XML/XSL whatever, then you have your clientside scripting in javascript or vbscript. The server side is implemented in [customers bizar language requirement here]. Of course, as you are writing a state-of-the-art distributed application you use
Am I the only one considering a change of career?
The way I see it, there is no point in punishing yourself with a diet for 4 months to loose weight. Or exercising like hell for a few months. The only thing that works is to turn your lifestyle around - and just a little will help.
* Ride a bike to work
* Stop eating candy - Quit cold turkey and you wont miss it at all in a short while
* Start playing tennis, soccer, basket, or swim.
..that celebrates christmas!
- and wishes of peace, harmony and tolerance towards all that do not.
Have a nice year!
Make sure that everything you write yourself is covered by unit tests. This will catch many problems with the open-source libraries and components you use, but another important benefit in this context is, that it allows you to refactor your code and replace one library with an alternative implementation with confidence.
As an XP developer I take a serious interest in unit testing, so I browsed the site - claims claims claims, but no details... I perused their PDF white paper - more claims and absolutely no specifics.
If they can't explain exactly what you get with QMTest in a few paragraphs, then it is probably not worth my time. Thankfully I'm already quite pleased with JUnit, RubyUnit and CppUnit.
However, if other slashdot readers have more patience with the project - I encourage them to write a summary of their findings here!
Coding Conventions
yep
If you like Python you will love ruby. Its syntax is imho much nicer and ruby is true OO. There are many technical reasons to like it, but the really great thing is how it is really easy to express yourself in. Unfortunately Ruby is not really as popular outside Japan as it deserves. Check out the pragmatic programmers book and give it a whirl.
Pragmatic Ruby
I'm right. Java is a fad, not worth much more than the Windows OS in terms of quality, and my CS faculty
./ camp have finally come to the point, where they no longer bash Windows from the technical stand point, and with good reason. Anyway, there are lots of other reasons to bash MS and Windows, so I suggest you train you gun at something worth the ammo.
I think most people in the
As I post this, numerous posters have already suggested C/C++ as their choice as a first language. This leads me to believe that they have little experience with at least one of the two languages, since they seem to believe that they are so similar that they should to be mentioned together in this context. C is almost a subset of C++, but C++ is much more expressive, much bigger and much harder to learn for a novice CS student. Being a good C++ programmer is definitely not the same as being good at C, and the other way around.
Finally, I think both of them suck as a first language, because they don't let you focus on you OO design and program logic - Java is much better for that. We are talking introductory stuff and first language, so lets concentrate on the important stuff and save the complications of reality for the next course.
My personal feeling is that Java is clunky, ugly, and runs much too slow on most platforms
Clunky and ugly? Compared to what? The language is pretty clean OO (as opposed to C), and clean and simple (as opposed to C++). This makes it an excellent candidate compared to those two languages for learning OOP, right? Your last point about runtime performance has little to do with how useful it is as a teaching language. Believe me, if you are going to be serious about programming, you are going to learn plenty of languages, but few are as clean and suitable for OOP education as Java.
Actually C++ is a multi-paradigm language which includes OO features. I wouldn't recommend it, especially if your experience is with VB, because you are likely to benefit from working with a less powerful, more OO-centric language, so you are less likely to develop strange styles and bad habits. Then, when you have developed a sound OO understanding and coding practice, you can move on to C++.
... and why you've omitted to mention any functional languages like the assorted lisps & schemes.
Because I have no real experience with these languages, but I can see why that is not an obvious answer to you - after all this is slashdot, the place where everybody feels they are experts, just because they know a few acronyms and can write "Hello World" (but not much else) in seven odd languages.
It also makes it blindingly obvious that you don't know your emacs modes from your elbow, too.
You are probably right, emacs is the kitchen sink tool, that does it all, better than more modern tools tailor made for their specific purpose. Yes - you definitely qualify as "one of those guys that give open source, linux etc a bad rep". I still use emacs for many things, because the editor in JBuilder isn't powerful enough, but that doesn't mean that the IDE doesn't provide a lot of great stuff that you don't get with emacs.
I can't believe you ask the slashdot community. Most of the guys here think C is a great language for application development and they think emacs, gcc and possibly a few xterm's is what it takes to make them the most efficient developers. Fact of the matter is that many of them have never done any serious work in an IDE using a higher level language such as C++, Java or Python. Unfortunately that doesn't keep them from offering their opinions about emacs vs IDEs and C for developing applications quite loudly!
Java is a great language, and there are several very good IDEs available for Linux. I have used JBuilder professionally for 8 months now - before that I used emacs exclussively, but I'm not going back now! JBuilder is top notch but lacks a great refactoring browser. I know you can buy a refactoring tool called jfactor that plugs into VisualAge, so if that's important to you, then maybe you should try that.
I don't want to say anything profound. I just want to pay my respect to the guy who wrote my favourite book. Thank you.
I've worked on both sides of the pond (Cupertino, California, U.S and Copenhagen, Denmark), and while the hours in the U.S. are definitely longer, the pace is slower, so in my experience the end productivity is about the same.
Ok, I take it you didn't break anything then? Good for you.
Hello John,
We have all witnessed the massive improvement of the visual realism of the first person shooters in the last few years. However the means of interaction is not only limited by crude I/O devices like screens and mice, but also be the shear complexity it takes to really simulate a world with convincing interaction that goes beyond running around, pushing buttons, riding elevators and shooting shootable stuff? Do you see any solution to these problems? How about massive parallel systems? I know you are a multiprocessing believer - do you see any signs of the industry moving towards mp systems?
Personally, I believe the SMP support in Q3A will do the same for SMP systems as glquake did for OpenGL support. Do you plan to put further effort into exploiting mp systems in your next project(s)?
The Geforce 256 and further generations of accelerators (will) allow a great increase in model details in terms of texture detail and in particular in terms of polygonal detail - Wont this mean that future games will require many more artists and modelers? I mean, if the model complexity increases with an order of magnitude wont this increase have a severe impact on the time it takes to create a single model? How will this reflect on Ids development model with so few artists? Creating highly complex models and textures seems like an extremely scalable task suitable for open source development. Do you see Open Source projects as a potential competitor in the future? Do you see a way for Id to make business and use the wast potential of open source development for art and perhaps code?
> And remember Bill Gates was a University drop out and Linus did finnish university.
Now I gotta now if that spelling mistake was just that - a spelling mistake, og a "clever" pun.
But a lot of what you are saying is just plain wrong. For starters the summary you link to was posted to the friends of performer mailing list by an SGI employee - and you expect objectivity from that source?
Also, you disagree that SGI's graphic solutions aren't cost-effective compared to consumer 3D boards - even SGI wouldn't risk such as statement (_they_ would realize it would make them look stupid). SGI's target market is only a tiny fraction of the consumer market in terms of the number of products sold, so there's a good reason for this.
But SGI's product is not only being superceded in terms of cost effectiveness. SGI's base reality and Infinite Reality (2) systems are not that impressive compared to the consumer boards. The Nvidia GeForce even has a higher polyrate than the single-pipe IR2, and it certainly has a very comparable fill rate (faster or slower depending on the number of raster managers).
There's nothing that drives product development as fast as the consumer market competion. SGI has faced this reality, why wont you?
What SGI has, but you fail to mention at all (perhaps because it is a _valid_ point), is slightly more features, like 3D textures and multi-sampling (for e.g. anti-aliasing).
Now, about the use of SGI worksstations for making special effects in movies. This has nothing to do with SGI hardware at all - Computer animations in movies are based on raytracing techniques, which to my knowledge are done entirely in software. Nobody is disputing that SGI has the expertise when it concerns graphics - but many are (correctly, imho) disputing that SGIs hardware will be able to stay ahead of the consumer products unless they do something radical. SGI sees the same thing and have formed a strategic alliance with the 3D consumer market leader Nvidia - SGI will built their future hardware using the same chips as consumer boards, only SGI will put them to work in parallel, like some company did with the Voodoo(2) chipset
Linux is not an alternative to SGI yet - the OpenGL hardware support is not solid enough yet, but we're getting there, partially thanks to SGI! Additionally the software isn't there yet either, but we're getting there. For instance SGI(!) is porting performer to linux!
SGI is a cool company with a _lot_ of engineering talent. They really don't need you to spread FUD - Now that the bosses have woken up and demonstrated that they do have the guts to make truly radical changes like adopting linux as a key element in their strategy, they'll make it just fine.
> It's really too bad we don't have something like Glide (really easy to program to), but open, not 'only 3dfx' crap
That's a common but very misguided opinion. Glide is a rasterization only API and is pretty much rendered obsolete by the addition of transformation and lighting to the hardware. Of course Glide could be extended to encompass this part of the pipeline as well, but what would be the point - OpenGL already does that. With DX7 D3D will get there too.
> I'm eagerly awaiting the new generation. But I expect the real crazy stuff to start happening in the following generation ...
> it may be finally time to kill some very old paradigms in 3d hardware...
I'd be interested to hear your thoughts on what might replace the current paradigm. Are you thinking voxel-based rendering techniques?
Am I wrong when I state that the amount of research (even recent!) devoted to rendering techniques based on the current paradigm dwarfs the effort put into researching more innovative approaches to rendering?
Actually this is pretty big news. Up till this point fill rate has been all that mattered for 3D chip makers, providing the capability of allowing higher resolutions, more rendering passes (for different visual effects) and higher frame rates. This is the first (consumer level?) chip to add transformation and lightning to the 3D chip, thus offloading these duties from the CPU. This effectively means more polygons can be used and this will have a truely remarkable effect on the realism.
Aren't you tired of watching perfectly flat walls with big posters stuck on them?