2010/7/11 Kevin Wright <[email protected]>: > Modularity is good practice in any language, but it isn't an automatic > cure-all. There are some problems that really demand a paradigm shift for > the best solution (i.e. to a functional or declarative model) > Such a shift can't simply be achieved through writing smaller methods. > Though it can, ironically, sometimes be achieved by writing bigger > ones; such as functional programming via google collections
As you mention the functional and declarative models. Those models are damn old and did not succeed back in the 80s or 90s. I don't think that those models are the real solutions for the real problems in software development. Let's give a few examples: a) For person being new to programming in general and learning Java, one of the first question is how to develop GUIs. Same question for a C++-programmer or those coming over from VB or .net. One of the first things is that people missing an out-of-the-box easy-to-use way to display tables. People trying the default table model in Swing usually get very fast to the limits of that. So basically there would be needed a useful standard model that is included in the standard libraries. They find it simply awkward, the need to develop their own table model for very common use cases. At least, the JTable is a veeery powerful thing and basically I guess, no more other table widget needed (at least for my use cases) - but it takes some effort to get the power as you need to develop your own table model (yes, or use some of the ready ones - but for me I didn't found one that matched my needs fully). When I tried .net the last time, I missed plenty of widgets and I guess I would need to buy several additional table widgets for different uses. b) Even for the experienced developer it is annoying complicated to run or integrate with OS specific moduls. Although there are plenty of options in Java, it should be more easy. And I mean in particular loose coupling with OS specific modules and techniques (e.g. optional COM, .NET interoperability, ...). I do not really dig into Scala - only follow the news - but I have not noticed any groundbraking new solution for that in Scala. c) None of the newer languages I know, do face the RAD (rapid application development) needs, Windows people know from MS Access. I still get customer requests to develop MS Access applications. Although I beg them not to do Access, sometimes they insist - for some reasons I can understand. in the late 80s and early 90s I developed a few years with a RAD tool (and BTW these were the times where I earned most with least effort). The best what I could find so far leading in this direction from current point of view is JVx (http://www.sibvisions.com/de/jvx) but of course it is not one tool for everything (it is for database focused applications), but ok, MS Access is too. I have not digged much into that right now, but what I want to point out is that such things are needed much more than yet another language where plenty of core problems are to solve again and again. d) Integration of Web-browser windows in own thick client applications or window handling in general (not the application related windows but others (simple use case is to get information about the active window if it is a completely different application). Whenever I need to do this I need to dig into OS specific API stuff. Don't know any language doing better in a platform independent way. These are just a very few examples of problems I often run into. I want those issues to be solved over getting properties for example (BTW: I had properties for years in VB and I prefer the way now I have it in Java - so this is another rurn, I can't understand - must be desired by people who not really know the drawbacks of using properties). So as long as most of that stuff is not solved, a new language can never be groundbraking and a REAL GOOD reason to change the language again and again. -- Martin Wildam -- 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.
