I agree to this point. optimizing your hardware/software will only help change the way things are executed.
Automation is happening not only on the software side, but also on the hardware side. With all the transaction level systems almost clear and easily integrated , there is a trend now for decision making & automated/independent systems to run these systems. Things seem to be moving well in this direction. Regards, jd On 7/12/10, Kevin Wright <[email protected]> wrote: > On 12 July 2010 07:47, Wildam Martin <[email protected]> wrote: > >> On Mon, Jul 12, 2010 at 08:18, Kevin Wright <[email protected]> >> wrote: >> > Not at all! It's as though I've said "a screwdriver is often a better >> tool >> > than a hammer", but you're only interested in hanging picture frames. >> >> OK, I understand... >> >> >> > I'm saying that (for a given problem) functional programming will give >> you >> > - a better fit to the problem's domain >> > - fewer lines of code >> > - more maintainable code >> > - faster execution >> >> ... and I can follow these arguments. When I said the functional style >> did not succeed, I meant this for the mainstream development. Of >> course, everything that exists makes sense somewhere. >> >> My examples might be focused on thick client GUI because this is what >> I am working on mostly yet - and while I settled for Swing on the >> thick client side, I did not settle for a web client framework yet. >> >> In general I am always searching for the one language and smallest set >> of tools that can be used quite efficiently to solve 80% of the >> problems and my work is quite widespread (no real focus on particular >> branch or particular type of software). I simply cannot use 3 >> languages with the same efficiency and productivity. And in this >> consensus I meant that the functional did not succeed. But the >> software you or others are creating, might be very specialized and >> functional could be 100% of your solutions. >> >> > All developers work with multiple languages on a daily basis. > Java (procedural/OO) > SQL (declarative) > XSLT (declarative) > build tool scripting (declarative) > shell script (procedural/OO) > JavaScript (OO/functional) > etc. > > The trend is definitely that declarative languages are filling the niches > and they're not your "80%" solution. > But they are a "20%" solution for 20% you can't do without, usually in areas > that people don't think to include in a list of languages they use when > "programming". But you *do* use multiple languages, we all do... > > >> >> > but... I'm also saying that for a different problem, procedural >> programming >> > will give you these, as will object-oriented programming, or declarative >> > programming. I can't say that one of these approaches is inherently >> better, >> > the choice depends entirely on your domain, and often a hybrid is the >> best >> > way. >> >> The declarative is also something I also experienced and also consider >> to not succeeded (for reaching the 80% bar). It can be very fast but >> never is really flexible - and the latter is crucial nowadays. In the >> 80s and 90s my customers usually knew very well what they want and >> there were far less change requests after delivery of the first >> version. Nowadays customers tend to want everything, but don't have >> any plan how to integrate this in existing processes or how the result >> should look like. I always need to take long looks into the glass >> sphere of what the customer could want next. And of course in these >> times most software I developed was running in quite isolated >> environments - often I brought the software along with the first PCs >> to those companies. Today everything needs to integrate well with >> existing stuff. > > > I feel I can state that SQL, and the current generation of alternatives for > NoSQL stores, has succeeded quite well! > Nor is it isolated to any particular industry, or lacking when it comes to > integration. > > >> > Having said all that, there is one area where functional and declarative >> > styles are consistently taking home the cup: >> > - scalability across CPUs/cores/nodes/hosts/shader pipelines/etc. >> > the model of mapping over elements of immutable data structures really >> does >> > scale nicely all the way up to 100,000s of parallel operations. >> >> This could be an explanation, why I don't see the benefit of those >> two: I am not working in the enterprise field (yes, Java not >> necessarily means Enterprise ;-) ) where I need to handle thousands >> and thousands of connections. >> > > > Imagine if your task is to add 1 to an element in an array, and you can do > that for all the elements simultaneously, how might that ability affect the > logic of your programs? Clearly, iterators are only going to be a hindrance > here! > > So concurrency is not about connections, it's about doing lots of *any* kind > of task in parallel. > > Your processor will have an SIMD instruction set, able to transform multiple > pieces of data in a single instruction. > It will likely also have multiple cores, also able to run tasks in parallel > and, of course, there's multi-threading, allowing tasks to share the CPU so > that it won't be sat idle while waiting for a memory page fetch, or user > input, etc. > and then... then there's your GPU. Able to handle thousands of concurrent > operations and increasingly being used for tasks that are nothing to do with > graphics. > > The trend for number of cores in a typical "desktop" computer is only going > in one direction, and I can easily imagine virtual machines soon being able > to optimise and run parts of your software on a GPU, especially once > standards like OpenCL have matured further. I believe that LLVM is already > being used for a fair amount of research in this direction, and VMKit > already provides JVM and CLI implementations that sit on top of LLVM. > > So this really, really isn't about "enterprise" computing. It's rapidly > becoming the only game in town, as a great many authors before me have > already pointed out. > > > >> -- >> 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. > > -- 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.
