True, but the guidance part is the key. And I'm not saying this should be something decided by managers, but by senior technical people.
What was suggested at the start sounded a bit more loose, and you still do need communication with managers, because the tools and languages you chose will influence directly the people you need to hire. I also think having too many different languages for reasons that are not well thought out is not a good practice, and you're going to end up with a lot of unmaintainable code if your language choices are emotional rather than strictly technical and based on some real world considerations. On Oct 5, 4:25 pm, Ricky Clarkson <[email protected]> wrote: > All those considerations apply even if you stick with Java or C. You > need to be able to trust your developers to do what is right for the > organisation, with guidance. > > On Tue, Oct 5, 2010 at 8:06 PM, Augusto Sellhorn > > > > <[email protected]> wrote: > > On Oct 5, 4:59 am, Kevin Wright <[email protected]> wrote: > > >> does it now make sense to also put more control > >> over the choice of language into the hands of the people who will actually > >> be using it? > > > No, you want to take into consideration longer term concerns like the > > readability of the code, and the maintenance concerns. You also have > > to take into account the skillsets of the current team, and what type > > of developers you will need in the future. So you don't want > > developers to just pick whatever language they want for a part of a > > project, you want a software architect or some technical person of > > some authority to do that instead. > > >> On the other hand, are these > >> considerations fundamentally different when choosing libraries such as > >> hibernate, spring, lambdaj or lombok, or when choosing testng in preference > >> to lombok? and is code reuse in many organisations really high enough that > >> you can't already claim the codebases of different projects are fragmented? > >> In truth, is the suffering all that great where we *already* use different > >> languages for parts of a system (SQL and javascript anyone...)? > > > I think a different computer language is a much different thing than > > selecting a library, but even for a 3rd party library there should be > > some process in your organization that you have to go through to use > > it. I remember a project where two people were trying to do something > > with timers, one picked Quartz the other picked some timer > > infrastructure on Spring, but they're both trying to do the same. > > That's not what you want to happen! > > > SQL and Javascript are good examples; both standard technologies and > > have very specific uses, you need to access a database? Use SQL, you > > need to do a webapp on a browser go with Javascript. In those cases > > these different technologies really solve a specific issue and need to > > be supported. > > > I think that's not the same as somebody picking a language because it > > eliminates a few characters per line of code, or has features that are > > purely just for syntactic sugar. > > >> Where is the balance here? Is it really still acceptable, in this day and > >> age, for management to mandate that "though shalt use Java, and only Java"? > > > In some cases this may be necessary. In others you'll need a different > > mix of technologies. What you don't want is a project where everybody > > is using very different technologies that makes it harder for somebody > > to understand the code or maintain it in the future. > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
