Live data from Hacker News

Lisp is sin

blogs.msdn.com

21–30 of 60 posts

Re: Lisp is sin

#21
post #7

Earlier quoted context omitted.

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…

I never did understand this averseness to anything not algol-derived... I personally like Lisps syntax (fuck off, even though it looks different and uses "s-expressions" and code as data and all the rest - ITS STILL SYNTAX) and I like point free syntax and forth-like syntax and prolog intrigues me and ML has interesting syntax too and ... My point is: ITS JUST SYNTAX! Syntax doesn't define the language, just the look…

Syntax does define the language. It's very difficult to write macros for an ALGOL-style language. It's possible but very difficult. Some people are put off by Common Lisp's LOOP macro or the FORMAT function and will try and avoid using the more complex features of them. Those are small examples of how the syntax encourages, or discourages, the use of language features.

Hell, I even hate doing any complex shell scripting because I can never remember the difference between [ ] and [[ ]] and ( ) when using conditionals.

Re: Lisp is sin

#22
post #14

Earlier quoted context omitted.

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 no…

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.

[deleted]

Re: Lisp is sin

#23

>> 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 n…

However, I've personally seen a project where the aim was essentially to let non-programmers program, and the result was horrendously messy.

So what? The goal of turning every user into a programmer is perfectly reasonable. Almost all users of the early systems and computers were also programmers. Even today, business users make use of Excel/Access and some macros to do some programming (even though it can be seen as basic).

Don't you remember a time when operating systems came with programming languages and compilers and actively promoted them to the user?

Oh, and HyperCard. There was another great example of "user's" programming. I've also seen some hideously ugly GIMP script-fu scripts but they worked and did the job of the "user" that wrote them.

In the end, the distinction between a user and a programmer is artificially created by software that doesn't view anybody else as smart enough to enter the monastary of the programmer.

Re: Lisp is sin

#24
post #7
post #4

> 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…

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…

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).

Re: Lisp is sin

#25

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... ). I think the trouble with Lisp (and Scheme) is that there's so much cruft and inconsistency beneath the veneer of simplicity (see http://tnovel…

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.

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.

Re: Lisp is sin

#26
post #4

> 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…

And anyone who could write this, can grasp Lisp themselves.

Write the memorizer? That's basic functional programming, but what does that have to do with Lisp? You could write it in JavaScript:

    function memoize(f) {
        var memory = {};
        return function memoized(arg) {
            return arg in memory ? memory[arg] : (memory[arg] = f(arg));
        }
    }
The big thing Lisp has left is reader and compile-time macros, and other systems [1] might be able to do both better pretty soon. Yes, Lisp has a lot to teach people who think that programming languages are passed down immutable from the superior minds of GvR or Stroustrup, but once you realize the enormous variety of decisions made in designing a language, it becomes clear that almost no number of languages will fill the space of possibilities.

A lot of ways, languages are like religions - they're part of social structure, and part of people's identity, and they tell you how to pray, when to fast, how to allocate and free memory, how to traverse the call stack, etc. But when you think about it hard enough, it's clear that all of these decisions are better made by individuals, not committees or institutions.

1. http://piumarta.com/software/cola/

Re: Lisp is sin

#27
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)))))))

Re: Lisp is sin

#28
post #7

Earlier quoted context omitted.

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…

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).

I've done things like this in Scheme - not robustly, but it's worth pursuing IMHO. I can't stand math formulas in SEXP notation. Array/slice/hash lookup notation would be nice too.

Lisp gets it right by excluding sugar from the language kernel, but a "batteries-included Lisp" should include it in a standard library.

Re: Lisp is sin

#29
post #14

Earlier quoted context omitted.

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.

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! :-)

(Raises hand)

Re: Lisp is sin

#30

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)))))))

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 Memoize(Func func)
  {
      var memoDict = new Dictionary();
      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.
Post reply on HN