Okay, I like that... different rules for specialist vs general-purpose languages, because choices are limited there and mostly standardised. For GP stuff, you worry more about the plentiful availability of future developers.
Then there's the middle ground, frameworks with their own APIs (as well as XML or annotation-driven configuration) that might as well be a different language. Hibernate would be a good example here, with hbm files and HQL, as would Spring. How would you regard something like Spring? With a feature set and specification size larger than that of either Scala, Clojure or Groovy (maybe even larger than all three combined), it still seems that Spring is chosen far more lightly. I even think that Spring has a learning curve comparable with functional programming, and is every bit as influential on the design of systems. So does it genuinely have less impact on readability/maintainability/testability than you would get from choosing Groovy? On 5 October 2010 20:06, 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail / gtalk / msn : [email protected] pulse / skype: kev.lee.wright twitter: @thecoda -- 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.
