On Wed, Jan 12, 2011 at 2:46 PM, Sean Corfield <seancorfi...@gmail.com> wrote:
> I'll probably also convert an essay about programming language
> technologies (aimed at my colleagues at World Singles) into a blog
> post at some point since it covers some of this ground too, as well as
> digging more into OO vs Procedural vs Functional and Static vs Dynamic
> and Imperative vs Declarative...
I read over the essay and decided to publish an excerpt of it directly
here instead of editing it for blog consumption. I have not included
the summary and a number of comparative comments about CFML because
they need more editing before I feel comfortable sharing them with a
broader audience (i.e., there's a bunch of really controversial stuff
in there!). Here is the main discussion section for your
entertainment...
There are several groups of classifications of programming languages
that have an impact on how well suited they are for different types of
problems.
Static vs Dynamic
Over the decades, most mainstream languages have had some level of
static typing. The programmer specifies the data types of variables,
the compiler checks they are legal and generates optimized code based
on the types. For years, static typing - and static code analysis -
were considered the only way to build reliable software. Dynamic
languages - with no type checking in the compiler, and often only
little checking at runtime, were considered good for prototyping but
unsafe for serious professional use. Over the last decade, dynamic
languages have seen a huge resurgence, especially in the web world,
because of the speed with which applications can be built and changed,
and their conciseness which allows for greater productivity. The
downsides have been tackled thru process changes to introduce more
testing, earlier in the cycle, and by encouraging shorter release
cycles so bug fixes reach customers faster. The appeal of dynamic
languages has squeezed out traditional static languages in some
problem spaces almost completely.
Examples:
Static: C++, C#, Java, Scala...
Dynamic: CFML, Clojure, Groovy, PHP, Python, Ruby...
Note: Groovy looks like it has a compile-time type system but it's all
dynamic at runtime:
String x = 42; // illegal Java at compile time
// legal Groovy at compile time, fails at runtime _if executed_
if ( false ) {
String x = 42; // illegal Java at compile time
// legal Groovy, never executed, won't throw an
exception
}
Object-Oriented vs Functional Programming
Both of these approaches have been around for decades. Smalltalk and
Simula were two of the original OO languages dating back well over
thirty years. The concepts of FP date back to the 30's and even LISP,
one of the earliest FP languages, dates back to the 50's. FP grew in
popularity in the 70's with a number of new languages (including ML,
SASL, Miranda and my own SURE language) but never gained mainstream
acceptance. In the 80's and 90's, OO continued to grow through C++ and
then Java and has become the dominant programming paradigm thru the
last decade. One of the modern stalwarts of FP, Haskell, appeared in
the early 90's but still didn't make FP 'popular', even tho' it has a
strong community and a good installed base. In the last decade,
however, the complexity of computing problems and the emergence of
day-to-day concurrency and parallelization, especially with multi-core
computers, has led to FP being taken more seriously - I'll explain why
in more detail below. Scala is a strong multi-paradigm (OO and FP)
language on the JVM and F# is a strong pure-FP language from Microsoft
on their CLR, Erlang is a strong pure-FP language native to its host
machine (Erlang was designed by Ericsson to support massive scale,
fault tolerant telephony systems). Lately Clojure has become quite
popular (despite it's LISP-like syntax!) because it is the only
dynamic scripting language that is both pure-FP and able to achieve
near-native Java performance - a problem that has plagued most
scripting languages (as well as most FP languages).
Imperative vs Declarative
Most programming languages are imperative: do this, do that - a
sequence of decisions and actions, laid out in the code. Certainly all
procedural code is imperative, almost by definition, but most OO code
is also imperative. Declarative languages, by contrast, let you
describe a solution without necessarily saying how to get there - the
language itself figures it out. XSLT is probably the most familiar
declarative language these days for people but Prolog is one of the
grand daddies of them all, dating back to the 70's and based on
research from the 60's. In Prolog, you literally describe the solution
and the inference engine tries to figure out how to generate paths to
that solution (it's a fascinating language - I used it extensively in
the 80's and almost took a role as team lead on a commercial team
developing large-scale data analysis algorithms in Prolog). However,
Prolog and its ilk haven't become popular partly because they are, for
the most part, interpreted and often have arcane syntax. Not all
declarative languages are like Prolog, however, and many FP languages
are considered declarative, at least in part. The benefit of a
declarative language is that it is higher-order, more concise and
let's you focus on the problem domain and the solution you want,
without getting bogged down in implementation details. Several modern
language are becoming popular for creating DSLs - Domain Specific
Languages - which are usually declarative in style and often
implemented in an FP style. Ruby and Groovy in particular support a
lot of DSL work in a declarative style, backed by an FP
implementation. I've also seen some very elegant DSLs expressed
directly in Clojure - due to its FP nature and its semantic macro
support.
Why FP?
Functional Programming emphasizes immutable data, avoidance of 'state'
(especially shared state) and use of higher-order functions (i.e.,
separating processes from data so processes can be combined and
distributed more easily and then applied to data as needed - in some
ways the very opposite of OO's tendency to blend data and
functionality). Immutable data and avoidance of shared state tend to
make concurrency relatively easy, and together they completely avoid
the performance overhead of locking and synchronization in other
languages. Combined with higher-order functions, this also allows for
automatic parallelization in multi-core environments. In other words,
FP is particularly suited to to today's problems and today's computer
systems. Immutability and higher-order functions also make programs
easier to understand and maintain - since there are no side-effects
(in most code) and units of work tend to be smaller and easier to test
or verify (and also easier to combine into powerful new systems). This
is why FP has become so popular lately, after decades of lurking in
the shadows!
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:340712
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
