Am Sun, 12 Aug 2012 14:34:58 +0200 schrieb "Paulo Pinto" <pj...@progtools.org>:
> On Sunday, 12 August 2012 at 11:48:23 UTC, bearophile wrote: > > Paulo Pinto: > > > >>And when they have them, there are many other issues to take > >>care of.< > > > > This is a bad argument because there are always other issues to > > take care of. Even if a firm buys an artificial intelligence > > able to self-write all the code, I am sure people in that firm > > will keep saying "we have many other issues beside writing > > code!". > > > > Bye, > > bearophile > > Sure it is, but I've learned that if you live in the Fortune 500 > corporation world, it not worth fighting against it. > > Actually there are a few talks in InfoQ about this type of issue. > > http://www.infoq.com/presentations/Stop-Refactoring > http://www.infoq.com/presentations/Who-Ever-Said-Programs-Were-Supposed-to-be-Pretty > > -- > Paulo There is code to be written in different areas of business for sure. There is rapid changing business code as yours, there is moderately changing application software, there are extensible tools like Eclipse and it goes further on to libraries and software used in sensitive areas, nuclear power plants, medical or mars robots. So there's definitely people who don't want to be slowed down by unnecessary errors and strictness in the language because it doesn't make money, and others who want to have a look at every little warning to make the code as failsafe as possible. I'm thinking of unhandled exceptions as well as integer overflow and similar. In the end your products wouldn't be finished in time either, if the libraries and tools you build them with weren't good. And open-source software often has the benefit there, that you can actually look at the source if something remains unclear in the documentation, and also that often a lot of people have looked over the code; people with different backgrounds and experience, that detect other types of bugs and pitfalls. In that way success is not always defined economically. It is defined by the goals you set for a given project. A person who uses test driven development might chose D, because of its built in unit tests and invariant() {...}. Similarly a physicist might shy away from it, because of the semantic noise. (They want an integer, but are confronted with the concept of signed/unsigned 32 and 64 bit values and BitInts) TL:DR - it all depends on your target audience :) -- Marco
