> I'd prefer more people spend their time making decisions about > business-level or application-level issues, rather than language or > framework issues. In the MS world, it *can* be much easier to focus > on those issues regardless of your team's experience, because almost > without exception they will be using the same tools and the same set > of libraries (framework/3rd-party/etc). That's not to say there's > absolutely no choice at all, but you tend to have to have a *really* > defined need to go outside the 'standard' options presented.
Agree, this sets a lower bar for development, which some of the Java community likes to interprets as it being a dumb, docile and uncritical community. The good-enough perspective is dominating on .NET, with de-facto support for most needs leading to less-is-more; I can understand if managers are tempted by this. Which stack is the best for your next major product in Java? There's no definitive right answer, you can go with something proprietary (ADF), what looks de-facto (Wicket) or you what's official (JSF) - it feels a bit like playing the lottery. > There are far fewer "Struts vs Grails vs etc"-type decisions MS-based > shops have, which leaves more time for other decisions. My limited > experience has seen that time translated into more business-focused > decisions/investigations, though it could just as easily be spent in > other techie-focused stuff instead. Ah but then we would not have the "fun" discussions between OSGi vs. Jigsaw, Eclipse vs. NetBeans, tabs vs. spaces, SWT vs. Swing, Hibernate vs. JPA, Scala vs. Fan etc. etc. That's not necessarily a stab at open source, more a realization that perhaps it's good to leave some decisions to the experts/architects. > Indeed, the person putting in very little > effort would likely produce a better quality result. Arguably, that > person put in 'the effort' years ago learning it, but it could also > very well be that there's benefits to the language and platform that > make it easier to provide the quality without as much effort. That's indeed the idea of abstraction, being able to express intent with course, context-free building blocks. Java caters to the philosophy that we should expand though the library, which is admirable. The problem is that the core language does not really support this very well. With no operator overloading, we are left with BigDecimal oddities. With checked exceptions, closures becomes really hard. Without properties, binding can not be type safe etc. So just as Neo found out, the real world is not as polished and pretty - be ready for oil on your pants and cranks that don't always fit. The Matrix had one architect, the real world don't. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
