C# Dev - I've tried Lisps, but I don't get it [closed]

Question

After a few months of learning about and playing with Lisp, both CL and a bit of Clojure, I'm still not seeing a compelling reason to write anything in it instead of C#.

I would really like some compelling reasons, or for someone to point out that I'm missing something really big.

The strengths of Lisp (per my research):

• Compact, expressive notation - More so than C#, yes... but I seem to be able to express those ideas in C# too.
• Implicit support for functional programming - C# with LINQ extension methods:
  • mapcar = .Select( lambda )
  • mapcan = .Select( lambda ).Aggregate( (a,b) => a.Union(b) )
  • car/first = .First()
  • cdr/rest = .Skip(1) .... etc.
• Lambda and higher-order function support - C# has this, and the syntax is arguably simpler:
  • "(lambda (x) ( body ))" versus "x => ( body )"
  • "#(" with "%", "%1", "%2" is nice in Clojure
• Method dispatch separated from the objects - C# has this through extension methods
• Multimethod dispatch - C# does not have this natively, but I could implement it as a function call in a few hours
• Code is Data (and Macros) - Maybe I haven't "gotten" macros, but I haven't seen a single example where the idea of a macro couldn't be implemented as a function; it doesn't change the "language", but I'm not sure that's a strength
• DSLs - Can only do it through function composition... but it works
• Untyped "exploratory" programming - for structs/classes, C#'s autoproperties and "object" work quite well, and you can easily escalate into stronger typing as you go along
• Runs on non-Windows hardware - Yeah, so? Outside of college, I've only known one person who doesn't run Windows at home, or at least a VM of Windows on *nix/Mac. (Then again, maybe this is more important than I thought and I've just been brainwashed...)
• The REPL for bottom-up design - Ok, I admit this is really really nice, and I miss it in C#.

Things I'm missing in Lisp (due to a mix of C#, .NET, Visual Studio, Resharper):

• Namespaces. Even with static methods, I like to tie them to a "class" to categorize their context (Clojure seems to have this, CL doesn't seem to.)
• Great compile and design-time support
  • the type system allows me to determine "correctness" of the datastructures I pass around
  • anything misspelled is underlined realtime; I don't have to wait until runtime to know
  • code improvements (such as using an FP approach instead of an imperative one) are autosuggested
• GUI development tools: WinForms and WPF (I know Clojure has access to the Java GUI libraries, but they're entirely foreign to me.)
• GUI Debugging tools: breakpoints, step-in, step-over, value inspectors (text, xml, custom), watches, debug-by-thread, conditional breakpoints, call-stack window with the ability to jump to the code at any level in the stack
  • (To be fair, my stint with Emacs+Slime seemed to provide some of this, but I'm partial to the VS GUI-driven approach)

I really like the hype surrounding Lisp and I gave it a chance.

But is there anything I can do in Lisp that I can't do as well in C#? It might be a bit more verbose in C#, but I also have autocomplete.

What am I missing? Why should I use Clojure/CL?

Answer 1

Macros let you write compilers w/o leaving the comfort of your language. DSLs in languages like C# generally amount to a runtime interpreter. Depending on your domain, that might be problematic for performance reasons. Speed does matter, otherwise you'd be coding in an interpreted language and not C#.

Also, macros also let you consider human factors - what is the most user-friendly syntax for a particular DSL? With C# there's not much you can do about the syntax.

So Lisp allows you participate in language design w/o sacrificing a path towards efficiency. And while these issues might not matter to you, they are extremely important as they underlie the foundations of all useful production-oriented programming languages. In C# this foundational element is exposed to you in a very limited form at best.

The importance of macros is not lost on other languages - Template Haskell, camlp4 come to mind. But yet again it's an issue of usability - Lisp macros to date are likely the most user-friendly yet powerful implementation of compile-time transformation.

So in sum what people generally do w/ languages like C# is build DSILs (Domain Specific Interpreted Languages). Lisp gives you the opportunity to build something much more radical, DSPs (Domain Specific Paradigms). Racket (formerly PLT-Scheme) is particularly inspiring in this regard - they have a lazy language (Lazy Racket), a typed one (Typed Racket), Prolog, and Datalog all embedded idiomatically via macros. All these paradigms provide powerful solutions to large classes of problems - problems not best solved by imperative programming or even FP paradigms.

Answer 2

Almost everything that was originally available only in Lisps has thankfully migrated into a lot of other modern languages. The biggest exception is the "code is data" philosophy, and macros.

Code is Data (and Macros) - Maybe I haven't "gotten" macros, but I haven't seen a single example where the idea of a macro couldn't be implemented as a function

Yeah, macros are hard to grok. Metaprogramming in general is hard to grok. If you saw any macro that could be implemented as a function, then the programmer was doing it wrong. Macros should only be used when a function won't work.

The "hello world" example of a macro is to write "if" in terms of cond. If you're really interested to learn the power of macros, try defining a "my-if" in clojure, using functions and watch how it breaks. I don't mean to be mysterious, I've just never seen anyone start to understand macros by explanation alone, but this slideshow is a pretty good intro: http://www.slideshare.net/pcalcado/lisp-macros-in-20-minutes-featuring-clojure-presentation

I've had small projects where I saved literally hundreds/thousands of lines of code using macros (compared to what it would have taken in Java). Much of Clojure is implemented in Clojure, which is only possible because of the macro system.

Answer 3

I'm not an expert in Common Lisp, but I know both C# and Clojure reasonably well so hopefully this is a useful perspective.

• Simple syntax => power - Lisps are about the simplest syntax that could possible work. S-expressions are all you need. Once you've grokked "(function-call arg1 arg2 arg3)" then you've basically got it. The rest is just picking the right function calls and arguments. Seems almost trivially simple, but the fact is that this simplicity is what gives Lisps so much strength and flexibility, and in particular enable the meta-programming capabilities that Lisp is famous for. e.g. if I want a macro to call several different functions on the same arguments I just do something like the following (not this is not just runtime function application - it's a macro that generates compiled code as if you had written out all the individual function calls by hand):

(defmacro print-many [functions args]  
  `(do   
     ~@(map   
        (fn [function] `(println (~function ~@args)))   
        functions)))

(print-many [+ - * /] [10 7 2])  
19  
1  
140  
5/7

• As a result of the incredibly simple syntax, Lisp's "code is data" philosphy is much more powerful than anything you can do with function composition / templates / generics etc. It's more than just DSLs, it's code-generation and manipulation, at compile time, as a fundamental feature of the language. If you try to get these kind of capabilities in a non-homoiconic language like C# or Java, you'll eventually end up reinventing Lisp, badly. Hence the famous Greenspuns Tenth Rule : "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp". If you've ever found yourself inventing a turing-complete templating / flow control language within your application then you probably know what I mean.....

• Concurrency is a unique strength of Clojure (even relative to other Lisps), but if you believe that the future of programming will mean having to write applications that scale to highly multi-core machines, then you really really should look into this - it's pretty groundbreaking. Clojure STM (Software Transactional Memory) works because Clojure embraces immutability and lock-free concurrency constructs based on a novel separation of identity and state (see Rich Hickey's excellent video on identity and state). It would be very painful to graft this sort of concurrency capability onto a language / runtime environment where a significant proportion of the APIs work on mutable objects.

• Functional programming - Lisps emphasise programming with higher order functions. You're right that it can be emulated in OO objects with closures / function objects etc. but the difference is that the entire language and standard library is designed to help you write code in this way. For example, Clojure sequences are lazy, so can be infinitely long unlike your ArrayLists or HashMaps in C#/Java. This makes some algorithms much easier to express, e.g. the following implements an infinite list of fibonacci numbers:

  (def fibs (lazy-cat '(0 1) (map + fibs (drop 1 fibs))))

• Dynamic typing - Lisps tend to be at the "dynamic" end of the functional programming language spectrum (as opposed to langaages like Haskell with a very strong and beautiful conception of static types). This has both advantages and disadvantages, but I'd argue that dynamic languages tend to favour programming productivity because of greater flexibility. This dynamic typing has a minor runtime performance cost, but if that bothers you you can always add type hints to your code to get static typing. Basically - you get convenience by default, and performance if you are willing to do a bit of extra work to get it.

• Interactive development - actually I think you can get some sort of REPL for C# 4.0, but in Lisp it's standard practice rather than a novelty. You don't have to do a compile / build / test cycle at all - you write your code directly in the running environment, and only later copy it into your source files. It teaches you a very different way to code, where you see results immediately and refine your solution iteratively.

A few quick comments on the things you see as "missing":

• As you say, Clojure has namespaces. In fact, they are dynamic namespaces: you can update them at runtime - this provides some surprising benefits for interactive development. I've had lots of fun redefining functions under the nose of a running thread, or hacking a live data structure....
• Compile / design time support - not really relevant if you're coding at a REPL - you just do it and see the result directly. Having said that, Clojure is starting to get some improved IDE support, e.g. the CounterClockwise plugin for Eclipse.
• GUI development - Yes, you'll have to learn a new API, but that's always going to be the case when switching languages.... good news is that the Java APIs aren't that hard and there are now some interesting Clojure-specific wrappers / examples that look pretty easy to use. See this question on Clojure GUI development for some nice examples
• GUI debugging: this works with the GUI debugger in Eclipse assuming you use CounterClockwise, or Enclojure if you use Netbeans. Having said that, I don't use this capability - I find interactive debugging at the REPL more productive.

I personally find the advantages of Clojure / Lisp pretty compelling, and I'm not planning on going back to C#/Java (beyond what I need to borrow all the useful libraries!).

However, it did take a few months for me to really get my head around it all. If you're genuinely interested in learning Lisp / Clojure as an enlightening learning experience, there is no substitute for diving in and forcing yourself to implement a few things.....

Answer 4

C# has got a lot of features, but the mix feels different. That some language has a feature still does not mean that it is easy to use, paradigmatic and well integrated with the rest of the language.

Common Lisp has this mix:

• s-expressions as a data syntax
• code as data leads to macros and other techniques of symbolic computation
• dynamic language allows runtime modifications (late binding, MOP, ...)
• strongly typed, dynamically typed
• interactive use with incremental compiler or interpreter
• Evaluator as core execution engine
• managed memory with Garbage Collection
• Hybrid language with heavy use of imperative, functional and object-oriented programming. Other paradigms can be added (rules, logic, constraints, ...).

Now, other languages, like C#, have that, too. But often not with the same emphasis.

C# has

• C-like syntax
• mostly imperative object-oriented, with some FP features
• statically typed
• mostly batch use with a batch compiler
• managed memory with Garbage Collection

It does not help that C# has for example code manipulation features, if they are not widely used as in Lisp. In Lisp you won't find many software that does not make heavy use of macros in all kinds of simple and complex ways. Using code manipulation is really a big feature in Lisp. Emulating some uses is possible in many languages, but it does not make it a central feature as in Lisp. See books like 'On Lisp' or 'Practical Common Lisp' for examples.

Same for interactive development. If you develop a large CAD system, most of the development will be interactive from the editor and the REPL - directly into the running CAD application. You can emulate much of that in C# or other languages - often by implementing an extension language. For Lisp it would be stupid to restart the CAD application under development for adding changes. The CAD system would then also contain an enhanced Lisp that would have added language features (in form of macros and symbolic descriptions) for describing CAD objects and their relationships (part-of, contained, ...). One can do similar things in C#, but in Lisp this is the default development style.

If you develop complex software using an interactive development process or your software has a substantial symbolic part (meta programming, other paradigms, computer algebra, music composition, planning, ...), then Lisp may be for you.

If you work in the Windows environment (I don't), then C# has an advantage, since it is a main development language of Microsoft. Microsoft does not support any form Lisp.

You write:

• Namespaces. Even with static methods, I like to tie them to a "class" to categorize their context (Clojure seems to have this, CL doesn't seem to.)

Common Lisp does not attach namespaces to classes. Namespaces are provided by symbol packages and are independent of classes. You need to reorient your approach to object-oriented programming if you use CLOS.

• Great compile and design-time support the type system allows me to determine "correctness" of the datastructures I pass around anything misspelled is underlined realtime; I don't have to wait until runtime to know code improvements (such as using an FP approach instead of an imperative one) are autosuggested

Use the Lisp compiler. It informs you about unknown variables, might have style recommendations (depending on the compiler used), gives efficiency hints, ... The compiler is a keystroke away.

• GUI development tools: WinForms and WPF (I know Clojure has access to the Java GUI libraries, but they're entirely foreign to me.)

The commercial Lisps like LispWorks and Allegro CL offer similar things under Windows.

• GUI Debugging tools: breakpoints, step-in, step-over, value inspectors (text, xml, custom), watches, debug-by-thread, conditional breakpoints, call-stack window with the ability to jump to the code at any level in the stack (To be fair, my stint with Emacs+Slime seemed to provide some of this, but I'm partial to the VS GUI-driven approach)

The commercial Lisps like LispWorks and Allegro CL offer all of that under Windows.

Answer 5

Rainier Joswig said it the best.

For me, the power of Lisp can't be understood by just looking at a list of Lisp features. For Lisp, and Common Lisp in particular, the whole is greater than the sum of the parts. It's not just the REPL plus s-expressions plus macros plus multi-method dispatch plus closures plus packages plus CLOS plus restarts plus X, Y and Z. It's the whole shebang all ingeniously integrated. It's the day-to-day experience which is very very different than the day-to-day experience of other programming languages.

Lisp looks different, it is used differently, one approaches programming in a different fashion when using it. It is elegant, complete, big and seamless. It is not without its own blemishes and peccadilloes. There are certainly comparisons to other languages that might be made where it might not come out ahead. But in no way is Lisp just language X plus REPL and macros, or language Y plus multi-method dispatch and restarts.

Answer 6

Code is Data (and Macros) - Maybe I haven't "gotten" macros, but I haven't seen a single example where the idea of a macro couldn't be implemented as a function; it doesn't change the "language", but I'm not sure that's a strength

Typically, a macro should be used for something that is not expressible as a function call. I don't know if there is a switch-like conditional in C# (similar to what exists in C, as switch (form) { case ... }), but let us assume it does and has close to the same restrictions (requiring an integral type).

Now, let us further assume that you'd like something that looks like that, but dispatches on strings. In lisp (well, specifically in Common Lisp and probably in others), that is "just" a macro away and if you restrict the user to having constant strings (probably not arduous) to match against, you can (compile-time) compute a minimal sequence of tests to determine what case matches (or use a hash table, storing closures, maybe).

While it may be possible to express that as a function (comparison string, a list of cases and closures to execute), it would probably not look like "normal code" and that is where lisp macros have a definite win. You've probably used quite a few macros or special forms taht are macro-like, like defun, defmacro, setf, cond, loop and many more.

Answer 7

This is the best explanatory article I've found that takes the reader from the surface of Lisp advocacy to show some of the deeper implications of the concepts being used:

http://www.defmacro.org/ramblings/lisp.html

I recall reading elsewhere an idea like this: Other languages have adopted various features of Lisp; garbage collection, dynamic typing, anonymous functions, closures to produce a better C++/C/Algol. However to get the full power of Lisp you need all of its essential features, at which point you have another dialect of Lisp, a distinct family of languages that has been around in one form or another for over 50 years.