Same Dev Tools/Language/Framework For Everyone? 519
AC writes "Upper management of the company I work at recently declared that all new development should be done with a single combination of development tools, language, and framework. The main rationale is that people can be relocated from one group / project to another faster, because they don't need to learn a new environment when they switch. Of course the chosen language / framework used by everybody does not need to be the best tool for the job, but it should be good enough to allow every project to get done. What does Slashdot think about this? Is it OK to use the same development tools and language for every project, instead of choosing what fits best? Will the time saved be sufficient to offset the time lost to the 'not the best tool for the job' environment developers will be forced to use?"
Microsoft (Score:3, Informative)
You should look at what the majority of the developers are using to make this decision. If you are a Microsoft shop, and cost is not a huge issue, the combination of VS 2008, .Net 2 or 3, and C# and VB.net will fill your need and just can't be beat in terms of getting large teams to work together. Plus, you can always add php via VS.PHP. Unfortunatly, if you are using php, or something else, your choices are going to be all over the place for IDE and framework.
Re:Standardize the RIGHT tools (Score:5, Informative)
That combination is better than just free as in beer... it's also free as in free speech! Subversion, Ant, and CruiseControl are all Free Software.
Re:Depends (Score:3, Informative)
The need to show "how good you are" with VIM is extremely lame!
Well, you're thinking that the VIM guy really gives a tit what everyone else thinks. If he still codes 2x-20x what all the IDE people use, and he's happy, and his code works, he's not going anywhere soon.
I've worked with more than a few crack developers who can hunt-and-peck faster than I can touch type, which isn't slow... Oh, they happened to know as much of the internals of the business as the business people did...
Re:Standardize the RIGHT tools (Score:1, Informative)
For a real nice cross-platform build system with more of a C++ bias, check out CMake [cmake.org] + Dart [kitware.com]. I've recently been forced into developing on a Windows desktop rather than Linux. I've got everything running smoothly under cygwin, including nmake VC++ (one of CMake's targets) builds from within emacs.
Re:Standardize the RIGHT tools (Score:2, Informative)
Re:Start sending out resume... (Score:3, Informative)
What features does Java need, that it doesn't have?
It needs to not be object oriented. The paradigm just doesn't suit compiler writing.
For parsing, functional languages can easily have Domain Specific Languages embedded into them, which makes writing parsers as easy as transcribing the grammar.
For working with the tree structure a compiler is commonly written in many "micro" passes each of which does some subtle optimization on the tree. Because the idea is that you do lots of different small passes, you want your code to be tiny, that's where pattern matching on the structure of the trees comes in really handy, instead of some fairly hairy conditional statements.
For both of these tasks Higher Order Functions are extremely useful -- letting you pass around a function to apply to parts of a tree, or in the case of parsing, the DSL is usually written as combinators of HOFs.
Finally, you missed out an entire stage -- static analysis (type checking, bounds checking etc). These analyses usually involve traversals of the tree annotating it with useful information -- again, very easily done in a functional language. Not so easily done in an OO one.
p.s. whoever modded you down is an idiot -- no question is a stupid question.Re:Choose them all under one. (Score:3, Informative)
If someone is good at something, ferchrissake KEEP THEM THERE!
I see that finishing a project appears to be a foreign concept to you.
-jcr
He's a maintenance coder, apparently. And likes it.
Re:Standardize the RIGHT tools (Score:2, Informative)
Re:Choose them all under one. (Score:3, Informative)
So yeah, perforce doesn't give you much over SVN with a small/medium dev team, but you do start noticing some short-comings, and little quirks with SVN when you start working on larger projects. e.g. Branching and (especially) merging. I'd definately go with perforce for a large scale project - if only for the relatively pain free merging....
Re:Choose them all under one. (Score:3, Informative)
They may be using a 3rd party commercial Eclipse package like MyEclipse.
Re:Choose them all under one. (Score:4, Informative)
Even a free tool has a TCO. We use Eclipse but we have a team who support it (as well as numerous other tools) in our environment. They do things like setup/configuration, installation, investigating new plugins, developer support, etc. I don't think it amounts to a significant amount per developer but it is a non-zero cost.
Re:Choose them all under one. (Score:3, Informative)
We use perforce here. I've been using it for about a year now, and honestly, the benefits of it must not be at the end user level. It's substantially the same as SVN, CVS, etc. I suspect the advantages are at the administration level (reorganizing, branching, merging, etc).
From a user perspective, it actually feels like a step backward from the old standby, CVS. It requires you to "lock" a file before editing it, and often seems to lose track of what files you have "checked out". It also seems to have issues determining differences with whitespace/linebreak changes when you have developers on Linux and Windows checking in code together.
Re:Choose them all under one. (Score:5, Informative)
[..] I suspect the advantages are at the administration level (reorganizing, branching, merging, etc).
Having gone from an svn shop to a Perforce shop, I can definitely say that branching/merging is much easier in svn than in Perforce. Also, the whole "client" concept is a bad alternative to file system state files (i.e. .svn or CVS directories).
I'm not saying that using the filesystem is the best alternative possible, but it's the least worst right now.
Not dev tools. (Score:3, Informative)
Two of us run Linux, two of us run OS X, and two of us run Windows. On OS X, one uses vim and one uses TextMate; on Windows, one uses Visual Studio and one uses Eclipse; on Linux, one is a tester, and I use Kate.
While I'm at it, two of us use the Dvorak keyboard layout.
To force us all to use one platform, and one environment, would be to drop our productivity severely for the learning curve, and permanently as we all work on a platform that doesn't as closely match the way we work.
Now, forcing one language/framework, I can understand -- we mostly use Rails, and pretty much entirely Ruby. But what would be the point of forcing one dev environment?
Is it so that they could easily give my laptop to someone else, or give me a different machine? We basically get a budget with which to pick out our own hardware. This laptop is mine but for a technicality: if I ever leave, they'll take it back and reformat it for the next person.
I agree with many of the other sentiments here -- programmers should not be moved from project to project. But depending on the projects, it may be at least as difficult to learn the new project as it is to learn a new language/framework.
But unless you've made an exceedingly poor choice of language/framework, you should still be able to pick (mostly) your own dev tools.
Re:Office violence (Score:3, Informative)
Woosh, you totally missed the point.
He's saying that programmers will need to move on to something else once the project is done. You know, when there's nothing much else for them to do? When the project's finished?
He's not saying that the company should be shuffling people around different projects all the time.
Reading is fundamental.