Follow Slashdot stories on Twitter


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Scientists Say a Dirty Child Is a Healthy Child 331

Researchers from the School of Medicine at the University of California have shown that the more germs a child is exposed to, the better their immune system in later life. Their study found that keeping a child's skin too clean impaired the skin's ability to heal itself. From the article: "'These germs are actually good for us,' said Professor Richard Gallo, who led the research. Common bacterial species, known as staphylococci, which can cause inflammation when under the skin, are 'good bacteria' when on the surface, where they can reduce inflammation."

Nokia Ovi Store Launches 64

Kensai7 writes "The much-awaited Nokia Ovi Store opened for business yesterday. By following a business model similar to that of successful rival Apple for the iPhone, Nokia is trying to provide developers and customers a vast portfolio of Symbian OS applications, games, widgets, etc. TechCrunch took a look at some of the more interesting applications available at the start, but was disappointed by the launch itself. The Ovi Store team acknowledged some difficulties due to high levels of traffic."

LEGO Rock Band Confirmed 98

SailorSpork writes to tell us that the rumored LEGO Rock Band has been confirmed, and it's set to be released later this year. The game is being developed for the Xbox 360, PS3, Wii, and DS. The press release lists the first five songs selected for the game, and says players will "work their way through local venues, stadiums and fantasy locations on Earth and beyond, that mimic the imaginative settings that the LEGO world offers. Also continuing the LEGO 'build-and-play' gaming experience, players will be able to create their own LEGO Rock Band style as they customize their minifigure avatars, band and entourage, including roadies, managers and crew." A new page on the Xbox website provides more (slightly odd) details: "Play killer riffs to destroy a giant robot, summon a storm, and demolish a skyscraper using the power of rock!"

Comment Corporate-Wide standardization (Score 1) 654

From the question, it is hard to ascertain the size of the "company" Below a certain size, standardization is more trouble than the benefits provide. In the middle, standardization probably depends on how willing the developers are. At the top end, where I live, some amount of standardization is a must. With 200 developers in our division alone, being hit with numeroud SOX (SarbOx to some) requirements, a need to implement massive DR plans for our systems, and a wide geographic development distribution that sometimes does not communicate well enough, treating programming languages like tools in a toolbox is unworkable. That said, you can't just quit cold turkey. At our size, you need to define a "strategic" language. In our case, many of our vendors utilize Java and J2EE, so that becomes our strategic language. However, we continue to support some older Win32 client code that demands VB6, and some vendors we use chose .NET, so we have to support that as well. That said, stuff like Python, PHP, Perl, Pascal, etc. must have serious justification before they are used for major development work (Perl is a favorite for the UNIX admins, but they are not considered development staff here)

Yes, there are times when the project gets sub-optimized by being constrained language-wise. Developers will grumble (and I am a senior development resource, BTW), but overall, the cost is less to enforce some standardization. Why?

Cross training/support. The fewer languages, the more bodies we have on staff that know it.

Integration. Not everything can be a web service. Our business users hate us telling them that we need to rewrite that chunk of code because it is in Language A and the rest of the project is in Language B

Development Machine stability: Compilers, IDEs, runtimes, etc., all have to pass through a rigorous testing matrix before they can be loaded on Development machines. Cringe if you want, but SOX and other regulations make those things necessary. Thus, more languages means more money tied to testing and certifying the components on a development box

Coding standards: The fewer languages, the fewer times we have to sanction a team to author standard for that language.

As a developer, I find the "languages as hand-tools" analogy severely lacking. Possibly, treating them like powertools is better. Once I select my Dewalt cordless tools, I am locked into a battery option, saw blades, etc. Some stuff can be bought generically, but I'm not going to go out and buy a Wilwaukee set of cordless tools just because their saw option does a better job on miter cuts. I will figure out a way to make good miters with my Dewalt. If I find myself making miters all day, I might consider buying just the Milwaukee saw, but I know I'll be forking over more bucks for extra chargers, batteries, blades, etc. I will not do that lightly.

I applaud developers who can pick up languages easily and are fluent in many. That said, language prowess does not give the developer license to create a programming Tower of Babel. If a developer can't show that kind of restraint, the company is no longer a good fit for him/her.

In the end, I think 1 is too few languages, but I think > 4 is too many for a large firm. Same goes for editors, compilers, etc. Of course, each company has to weigh the risks against the benefits. I can see a cross-platform developer needing many more compiler options, and there are no doubt firms where performance cannot ever be sub-optimized, so my comments are moot. However, for those who live in a data-processing land where I exist, there is little to gain from switching languages like a playboy switches partners.

Slashdot Top Deals

"In the face of entropy and nothingness, you kind of have to pretend it's not there if you want to keep writing good code." -- Karl Lehenbauer