eBook - Top Ten Reasons to Embrace Spatial Components

Receive Posts by Email

Enter your email address:

Does Lisp Influence Your C++?

The idea for this post started on Aug 11, 2011, when I read Gregg’s post about choosing a scripting language for 3DScript, the CGM interactive test bed.  That article had a lot of good ideas, but I feel like it kind of missed the point regarding Lisp/Scheme/Functional Programming.  He used a do loop to try to make the point that the syntax is rather goofy.   The reason scheme came up at all is that it is used as a scripting language for acis3dt.exe our 3D ACIS Modeler Test application.

I actually agree that the syntax for a do loop is goofy.  However, learning about Lisp (and the lispy features of perl, see http://hop.perl.plover.com/) has made me a much better programmer than I would otherwise be.  In some ways, this thesis is older than the hills. To illustrate this, Google various subjects surrounding Lisp, Functional Programming, etc., for example, map-reduce.  When I talk with other programmers, I get the feeling that the message bears repeating.

So please bear with me while I sketch a few specifics.  Also, feel free to add your own in the comments:

  • Referential transparency makes things a lot easier to reason about.  Put another way: it is much easier to deal with C/C++ code that doesn’t modify global and static variables.
  • The best way to speed up code is to get a smarter algorithm. 

- Writing programs as compositions of simple (but high order functions), makes it much easier to reason about them:
- There are a few functional programming clichés that often help in dramatically speeding things up
                         - Memoization
                         - Make the algorithm lazy

  • Mathematical proofs are very easily given in terms of induction/recursion

- The literature on Lisp has lots of discussion about how you can convert between recursion and iteration.

  • Thinking about classes in terms of closures is helpful to me.

A common anti-pattern in legacy code is monolithic and large functions which give a detailed to do list.  Typically, I end up extracting functions from the huge monster, turning them into classes, and then parameterizing their behavior.  This is really almost the same thing as taking a code snippet, making a closure over the variables you need to encapsulate, etc.

C/C++  still tends to be ubiquitous because:
(a) So many system libraries are written in C or C++
(b) Well written C++ can be very fast

However, C-style languages don’t lend themselves to simple and concise reasoning about code.  If there were a well-established Lisp with a good linker, it might eat C’s lunch.

Here's a cartoon on the subject http://imgs.xkcd.com/comics/lisp.jpg

What do you think?


Hi Eric,

As a general reply to the title of your post (perhaps not so relevant to the specific content), I am profoundly affected by another functional language, Haskell. My background is in Mathematics and C/C++ programming but I my work (and thoughts) of these subjects are only loosely connected. Recently, I've been diving into functional programming in Haskell and it has changed my whole mindset on programming and its close relation with certain areas of mathematics.

For my next programming project, whatever language I end up using to implement it, I know that the functional paradigm (and specifically to Haskell, lazy evaluation) will influence my design.


See comments

Request an evaluationREQUEST AN EVALUATION

Download technical whitepapersDOWNLOAD TECHNICAL WHITEPAPERS

Read the Spatial Blend newsletterREAD SPATIAL BLEND NEWSLETTER

Watch technical webinarsWATCH TECHNICAL WEBINARS

Featured Video


Build IT

eBooks & Whitepapers

eBooks & Whitepapers

Download technical eBooks and whitepapers on topics including industry challenges and product solutions.

Spatial Facebook Spatial Twitter Spatial LinkedIn Spatial YouTube Spatial Blog RSS


A quarterly e-Newsletter highlighting industry trends, and includes articles from Spatial developers. Sign up to receive The Spatial Blend.