
Lisp is sin - iamelgringo
http://blogs.msdn.com/sriram/archive/2006/01/15/lisp_is_sin.aspx
======
semmons
> But I'm willing to bet that a lot more developers will be able to understand
> this since this is in a programming language they understand well.

This is one argument I don't buy. He talks about the Mort programmers never
being able to understand Lisp. I am willing to bet, any Mort programmer who
looked at this C# would not be able to understand it. I'm sure they could take
advantage of it, but write it themselves, I don't think so. And anyone who
could write this, can grasp Lisp themselves.

~~~
arakyd
Yeah, he says that Lisp is too hard for the common man, and then sort of
implies that this is because it doesn't use ALGOL derived syntax. I don't
think that's the issue. It's not Mort who's fallen in love with ALGOL syntax,
it's the CS graduate Elvis's who cling to their expensively acquired "skills"
(priesthood memberships) with religious fervor (he says, as a CS student).

I program in C#, and lambdas and delegates are nice (I can't use expression
trees because the company I work for standardizes on .NET 2.0). But the system
is too gnarly, still verbose as fuck, and nowhere near as nice as Lisp (as
Krishnan freely admits). This just increases the need for sophisticated
developer tools and makes things more obscurantist, not less. C# is just
another variation on Java, i.e. a way to drag Elvis types 10% closer to Lisp
without depriving them of their oh so precious ALGOL syntax.

Fuck the priesthood, seriously.

~~~
yummyfajitas
Something I've never gotten around to is building an algolish-lisp -> lisp
translator.

    
    
        [a, b, c] -> '(a b c)
    
        f(x) -> (f x)
    

These two translations are strictly syntatic modifications to lisp.

Some syntactic sugar:

    
    
        {
            f(x)
            g(x)
        } ->
        (progn
            (f x)
            (g x)
        )
    

With these three tweaks, we are probably 90% of the way to recruiting the
common man (if syntax is really what puts them off).

~~~
KirinDave
You can do these within PLT scheme quite easily. In fact, PLT Scheme comes
with an Algol 60 reader that reads Algol 60 and turns it into scheme forms
which are then executed. It's a cute trick.

<http://docs.plt-scheme.org/algol60/index.html>

------
radu_floricica
> I know that if I write a C# program today that it can be called by a Boo
> program which in turn can be called by IronPython.

This is another reason we should be grateful for Clojure. It will have a .Net
implementation soon, too.

~~~
KirinDave
I see two problems with this statement:

1\. This only works if you're willing to seclude yourself in the Microsoft
Yurt and never leave. Technical benefits aside, history has shown MS is not
afraid to abandon projects. It's a dangerous position to take, in my opinion.

And I sincerely doubt a port of Clojure to .NET would result in a 0-difference
result. We're back to the exact same problem that plagues other lisp
implementations right now, which is to say we haven't really bought much.

2\. It's not that different from how things are in the C world, save that
you'd share more of your runtime infrastructure. My job has been full of
instances where an executable interacts with a diverse set of languages. One
example I work on daily includes Erlang, Ruby, Prolog, and C++ all in one
space, calling around (in a structured way, of course). The implication that
you cannot make modern languages communicate without a single umbrella runtime
is demonstrably false.

~~~
radu_floricica
What I meant was now you have an ecology of languages on the jvm (Clojure,
JRuby, JPython, Scala, Groovy...), and on top of this a .NET port is in the
works. Sorry if I was a bit unclear.

------
TallGuyShort
>> one of the driving forces was to let non-geeks build software

He makes the extremely important point that the technology has failed if
ordinary people can't use it to get their own work done. However, I've
personally seen a project where the aim was essentially to let non-programmers
program, and the result was horrendously messy. In large part, I think that's
because a lot of people ended up developing that had no understanding of the
underlying concepts, and as a result the output was extremely hacked together
and unintuitive. I think it's great when people realize that the whole point
of most software is to enable regular users to complete a task without
worrying about the internal computation, but it's just as important to realize
the need to _understand_ what is happening.

~~~
KirinDave
Shouldn't we ask ourselves if this goal is reasonable? Making arbitrary
software is at the limits of our capacity right now, even if people devote
their lives to it as a profession, passion, and an art.

It's one thing to take an approach like Apple Automator (a much beloved
automation environment), but it's another entirely to say, "General Purpose
Software should be within the grasp of the 'average person.'" It's not clear
that the goal is even reasonable! A lot of software, to do what it does,
requires the use of complex mathematics, algorithms, and cryptography that
frequently even the implementors only vaguely understand. Manipulating those
in an abstract and correct fashion is difficult in the extreme (e.g., the
morass of timing attacks that have plagued modern implementations of
cryptographic protocols). We can barely make software with smart people!

~~~
itgoon
Horse hockey.

While I know that there are a lot of horror stories (and I can tell a few),
some of the most productive "programmers" I've ever met used MS Access or
Excel.

If you don't consider advanced usage of these applications as a form of
programming, then you are illustrating the point: It is not only possible to
"dumb down" programming, it is inevitable. So much so that you haven't even
noticed it happening.

~~~
tnovelli
Heh... I know a guy who thinks he's too dumb to program in anything _except_
Lisp (ALGOL syntax is hard! It's like math! :-)

~~~
licoresse
I think you are talking about me

------
rplevy
This article is a couple years old. The author probably would have tried
Clojure for his foray into Lisp had this been written today.

------
tnovelli
He rambles a lot, but he's right about the need for a new Lisp, and refers to
the ILC'05 presentations by Dussud, Baker, and McCarthy on "Re-inventing
Lisp". Those are some pretty radical proposals. (Summaries:
[http://www.findinglisp.com/blog/2005/06/ilc-2005-wednesday-r...](http://www.findinglisp.com/blog/2005/06/ilc-2005-wednesday-
report-late.html)).

I think the trouble with Lisp (and Scheme) is that there's so much cruft and
inconsistency beneath the veneer of simplicity (see
<http://tnovelli.blogspot.com/2009/08/lisp-crisis.html>). Lisp is a great
language to study; I just wish it was more practical and popular. It sucks
having to choose between awkward (Lisp) and inflexible (everything else). :-(

~~~
KirinDave
Your resources are pretty old, the "crisis" of car/cadr is just not there with
modern, updated lisp implementations like PLT Scheme.

PLT Scheme is competitive in every way with Python and Ruby, I don't know why
people keep ignoring it.

~~~
tnovelli
Umm... what's this _scheme_make_pair(car,cdr)_ function in
plt/src/mzscheme/src/list.c? That's a wart (the crisis is in my mind :-)

It doesn't have to be that way: Clojure has abstract sequence types, with
cons/car/cdr wrappers in case you want them.

~~~
KirinDave
I fail to see how having a linked list datatype is a crisis. Use vectors if
you don't like them. You can write a very large amount of complex, fully-
functional scheme code without ever typing in any expression matching
"c[ad]+r". PLT Scheme also comes with a host of sequence-agnostic (or sequence
aware for performance) comprehensions:

Please refer to: <http://doc.plt-scheme.org/guide/for.html>

------
justinhj
Compare the C# version of memoize to this one (from On Lisp). The C# one looks
very long and ugly in comparison, so I hope it isn't the new Common Lisp.

(defun memoize (fn) (let ((cache (make-hash-table :test #'equal))) #'(lambda
(&rest args) (multiple-value-bind (val win) (gethash args cache) (if win val
(setf (gethash args cache) (apply fn args)))))))

~~~
snprbob86
Lisp certainly has many advantages, but general readability is not one of
them. Maybe when talking about complex algorithms with a sufficiently designed
DSL... Here's your code reformatted:

    
    
      (defun memoize (fn)
          (let ((cache (make-hash-table :test #'equal)))
          #'(lambda (&rest args)
              (multiple-value-bind (val win) (gethash args cache)
              (if win val
                  (setf (gethash args cache) (apply fn args)))))))
    

And here is a prettier (use of TryGetValue), C# 3.0 (Func types, local
variable type inference) version:

    
    
      static Func<TParam, TReturn> Memoize<TParam, TReturn>(Func<TParam, TReturn> func)
      {
          var memoDict = new Dictionary<TParam, TReturn>();
          return arg =>
          {                
              TReturn result;
              if (!memoDict.TryGetValue(arg, out result))
              {
                  result = func(arg);
                  memoDict[arg] = result;
              }
              return result;
          };
      }
      

The C# version is clearly longer, but less dense. Most of the noise in the C#
version comes from the verbose type declarations. Almost anyone could read the
C# code, provided they know that => means lambda and at least heard of a
closure. That is not true of the Common Lisp version. As with everything in
engineering, it is a balance. Lisp is absurdly powerful and C# is absurdly
clear to read. As a programmer who does _a lot_ of maintainence programming at
work, I highly appreciate that attribute of the language.

~~~
lispm
I would format the function like this:

    
    
        (defun memoize (fn)
          (let ((cache (make-hash-table :test #'equal)))
            (lambda (&rest args)
              (multiple-value-bind (val win)
                                   (gethash args cache)
                (if win
                  val
                  (setf (gethash args cache) (apply fn args)))))))
    

I'm a Lisp programmer and the C# arglist is already hard to parse with lots of
noise - for me.

Second I don't look for { or ( but for the block indentation, so a { on a
single line does not give me enough visual clues.

The 'return arg =>' form is not obvious to me. What does it do? Where dies
TReturn come from, TParam?

Why is there }; and } ?

~~~
pyre
> _Second I don't look for { or ( but for the block indentation, so a { on a
> single line does not give me enough visual clues._

We could argue for days about these sort of issues, and there are passionate
ideas on either side of the fence.

    
    
      function
      {
        code;
        code;
      }
    

In that form, you have the beginning { and ending } for explicitly define the
beginning and ending of the code block, and all of the code inside is also
indented for good measure. Maybe it's redundant, but I don't see how it's
_wildly_ different from:

    
    
      function
        code;
        code;
    

> _Why is there }; and } ?_

Have you never programmer outside of lisp? I've never programmed in C#, but if
'arg =>' is the beginning of lambda, then it's because the definition of that
line is _return EXPRESSION;_.

And in that case EXPRESSION = 'arg => { code }'. That's where the ';' comes
from.

------
billswift
If I remember it right, Joel's "Perils of Java Schools" was about college CS
programs which should be a lot more fundamental than just practical. This
guy's essay conflates the equivalent of weekend carpenters, building
maintenance, and civil engineers into one set of "programmers".

------
erikb85
Hm. If Lisp would be an "everybodys" language, what would be the Lisp then?
Actually, the main success of lisp comes from its purity its scientific
deepness. If you try to follow another goal, you just lose vision for your
actual one. If somebody really needs an "everybodys" language, for example
because he is a lawyer or something else, okay. There is Python, Javascript,
Java and many other languages who try in different ways to be for everybody.
And all of them are important. As is Lisp, how it is.

