How about some real world examples here then. A couple of these even relate to client-facing GUI work, which seems to be your focus, though it is of source only a *tiny* part of the problem space that we can solve via computer programming.
declarative paradigm: - SQL for database queries - JavaFX for GUI work - XSL-T for "document" processing functional paradigm: - highly concurrent + stable telecoms switches using Erlang - reactive programming against a 2D scene graph (Scala+fresca): http://www.ganguin.net/frp2d.pdf - MapReduce These should all be very, very familiar to you, with the exception of the reactive programming work that first needed for an effective implementation of delimited continuations to come about. Look around on Wiki pages for Scala, Clojure, OCaml, Haskell, etc. and you'll find plenty more that you recognise. Given that MapReduce is so famously used by Google, and Google are the world's largest IT company, could it not be argued that Functional Programming is actually now the dominant paradigm? Objects, and GUIs, really are a tiny part of the big picture. On 11 July 2010 12:09, Wildam Martin <[email protected]> wrote: > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] 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.
