Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Use the right tool for the job (Score 1) 437

Most problems you need to solve already have libraries to make it easy. So figure out what your specific problem is, find the right library and language combination that best supports you. If you really care about performance, or some other specific metric, then you might need to use another language, but in general, I'd say use the your favorite language that supports the library you need to achieve your goal. I am currently using C#, javascript, java, C++, shellscript, and a couple other languages. And for each additional feature, I ask myself what is the best tool for the job. There are many ways for different languages to inter-operate, so don't feel that you are confined for just one language. If you think that rust is the best language for a particular task, use it and integrate it with the rest of your code. And if later you decide that another language is better at doing that task, someone can port that one task without having to rewrite your whole stack.

Comment Some very good reasons for "bad" code (Score 1) 507

Nearly all code is "bad" to one degree or another. There are some very good reasons for this. 1. As Steve Jobs said, "real artists ship". If you're in a research lab it may be a different matter, but in the real world, your code is never perfect, yet sooner or later you need to let real people use it, and either make money or discover that you're trying to solve a problem that doesn't exist. If the former happens, you should try and go back and improve your code. If the latter happens, be glad that you didn't try to design the perfect solution to your non-existent problem and go try to solve real problems. 2. The human race moves forward. Hardware gets faster, cheaper, smaller and uses less energy. Operating systems, browsers, and languages become easier to develop for with new features, and become more efficient with hardware acceleration, various optimizations, etc. You may have written amazing code 10 years ago, but it is "bad" code today because there are now better ways to do things that didn't exist at the time. Over time you should update your code to try to take advantages of this, though you may be limited due to a need to support legacy platforms. 3. You weren't the same person 10 years ago as you are now. We are continuously learning new things, fixing previous mistakes, and making new ones. If you look back at your old code, you should think that it's "bad" at least in some ways. If you don't, it means you didn't learn anything since you wrote it, which is a shame. 4. You don't know everything, and you don't have to. That's why you hire smart people, so you can focus on your strengths while outsourcing the rest, and so that you can learn how others approach problems differently than you. Instead of trying to defend your territory as others have mentioned, I'd ask for ways in which the code is "bad" and can be improved, and then include him in the process of triaging those tasks against the rest of the team's workload.

Comment Re:Quit whining (Score 1) 724

This post seems to be more of a bug report or feature request than a troll or bully. Whenever you are developing software, if you are lucky enough to have people actually use it, you will get feedback generally both positive and negative. Before responding to bugs or feature requests from the community, you probably want to think about how much you are willing to invest in improving the product as a whole (time, money, etc). Also try to estimate what fixing this specific issue will buy you (increased revenue, more users, community goodwill, self gratification, etc.). And try to deal with those issues that will get you the most bang for you buck...

Slashdot Top Deals

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell