Code Watch: A paradigm for your thoughts

By Larry O Brien

May 18, 2012 — (Page 1 of 2)
Once upon a time, back when men wore parachute pants and women wore fingerless gloves, there was a software crisis. The demand for new software exploded in the 1980s as PCs started penetrating small and retail businesses (running a Swatch boutique was hard enough, but at least you could keep your inventory on a Zip disk), and corporate departments started going rogue with sophisticated spreadsheets and easy-to-program database-oriented "fourth-generation languages." Demand outstripped supply, and a gap rapidly grew between the focus of the mainstream paradigm (systems analysis and Structured Design) and the day-to-day problems being faced (brittle codebases, customers too busy to review even a few hundred rows of the requirements matrix, and the emergence of graphical user interfaces).

Fast-forward to today, when we wear... I dunno, whatever's trending on Pinterest, I guess. There is a software crisis. Single-core programming is on its last legs. We've carved out a niche and a buzzword ("Big Data") to pretend that all of us aren't going to be in a world of trouble when clients start realizing they're waiting around for results and we're only using 1/8th, 1/16th, 1/32nd of available processing power. A gap has rapidly grown between the focus of the mainstream paradigm (object-oriented programming) and the day-to-day problems being faced (infrastructure dependencies, legacy codebases and under-utilized processing capacity).

One advantage OOP had over Functional Programming (FP) is the undivided attention developers had on GUIs. Every developer (and I mean every developer) had customers demanding dropdown menus and mouse support, and these things are, as we all know, hard to do properly using top-down imperative programming. There was a very strong (if somewhat erroneous) association between GUI programming (demanded) and OOP (perhaps worth learning). This was so pervasive that Steve Jobs, when he introduced NeXTStep 2.0 in 1990, demonstrated programming with Interface Builder as one of that system's core advantages.

Today's industry isn't nearly as focused on manycore, even though it's a much bigger problem than the relatively trivial problem of learning new mobile or touch APIs. And although there's a vague association between FP and concurrency, it is not so definitively linked in the minds of the mainstream. There are still far too many developers who think that "the OS will take care of it" or "I'll use a library," or who don't even realize that the current mainstream concurrency model (developer-controlled threading with shared mutable state) is far more dangerous and difficult than manually managing memory.

Related Search Term(s): functional programming, object-oriented programming

Pages 1 2

Share this link: http://sdt.bz/36633

Technorati

Digg

Slashdot

Facebook

Friendfeed

Twitter

del.icio.us

Code Watch: Functional programming's smugness problem Functional programming techniques are held back by those who practice them being not nice to other people

Code Watch: Here comes functional programming C#'s popularity means functional programming is here to stay and poised to overcome its roadblocks

Integration Watch: The intractability of parallel programming Not much progress has been made in the field of parallel programming. What can be done to advance it?

Code Watch: Functional programming's smugness problem
Functional programming techniques are held back by those who practice them being not nice to other people Read More...