Live data from Hacker News

Ooh Ooh My Turn Why Lisp? (2008)

smuglispweeny.blogspot.com

51–60 of 160 posts

Re: Ooh Ooh My Turn Why Lisp? (2008)

#51
post #44

I want to see people's list of reasons for why not lisp. Edit: Ok, this is not trolling. I quite liked Lisp and actually had implemented a version of common lisp from scratch based the Guy Steele's CL reference back in the undergrad time. I just found that beyond academic and a few Emacs packages, I didn't use Lisp at all, for one reason or the other. I just want to hear people's reason for not picking Lisp for their…

I dislike Lisp (and Lisp-inspired languages like Scheme and Clojure) for two reasons:

1. their weak and dynamic type system, and 2. they don't control side-effects.

Re: Ooh Ooh My Turn Why Lisp? (2008)

#52
post #12

> most Common Lisp implementations are native compiled. ... isn't it nice to compile down to the metal? Is just the interpreter native or does cl compile your app to native as well?

To native with elegance [1] and even closer to the metal "because sometimes C abstracts away too much" [2].

[1] https://www.pvk.ca/Blog/2014/08/16/how-to-define-new-intrins...

[2] http://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly...

Re: Ooh Ooh My Turn Why Lisp? (2008)

#53

Earlier quoted context omitted.

> What I mean by “code in an object language is data in the metalanguage” is that, in the metalanguage in which you're writing a compiler or interpreter, the object language program that you're processing is represented as a data structure (say, as a syntax tree). It's just a triviality, I'm not saying anything really deep. I understood what you were saying, and didn't ask for an explanation. I just don't see why you…

> I just don't see why you felt the need to correct me on my calling first=class functions "code as data" Because first-class functions aren't “code as data”. When you have a first-class function, the only thing you can do with it is call it. If it were a data structure, you could analyze its constituent parts. > You're basically interrupting me to tell me I'm not using the same definitions of words as you are, The W…

> Because first-class functions aren't “code as data”. When you have a first-class function, the only thing you can do with it is call it. If it were a data structure, you could analyze its constituent parts.

There are lots of ways in which you can treat a first class function as data, even if it can't be treated 100% equivalently to data in every single situation. You can, for example, pass it to other functions like data. Sure, most languages don't let you inspect the internals, but that's only one way of treating code as data.

> The emphasized part is just what I said. That a mathematical function is a mapping from values to values is unquestionable - it's not something I'm saying, it's a mathematical fact. So if you can't express compound values, you're limited to a world where mathematical functions can only manipulate primitive values.

I said, "And to be honest, other languages have done a lot better things with the functional programming aspects of Common Lisp." Common Lisp isn't a purely functional language, but it does have functional aspects. Note in the article I quoted, that Common Lisp is the first language listed in the "prominent programming languages which support functional programming such as" section.

You're literally not even disagreeing with me, you're just defining "functional programming language" as "purely functional programming language", when I literally never even called Common Lisp a functional programming language.

Insisting on your definitions instead of trying to understand what I said doesn't make me want to engage with you further.

Re: Ooh Ooh My Turn Why Lisp? (2008)

#54
post #18

"The question is where will we be in five years, the answer is using Common Lisp, because of language features" says the author in the comments. This was 8 years ago. Kind of rude of me to take that potshot, but it's there. I've been reading these "Why Lisp?" Arguments for years and yet it still remains pretty niche. The longer this goes on the more I am unable tell Lisp advocates apart from Perl advocates. They both…

Hmm. In many walks of life, popular != best. In fashion, cars, investing, and to some extent cooking, for example, the top performing adherent is doing things differently than the crowd.

Lisp code can be very readable, but it takes a few years to learn how to write it that way. I spent many years in Perl 5 myself, and I found Common Lisp tricky at first but ultimately very satisfying.

Two jedi mind tricks for the beginner:

1. Don't think of Common Lisp as the language you want. The language you want is one layer above CL, and fits the business domain you operate in. Build that. (Yes, this requires a little investment up front.) Then solve your problems in that "language". Because Lisp macros are powerful fully-transformative engines, you can do almost anything (less breaking a few simple syntax rules... but newbs often underestimate what can be broken/bent).

2. As silly as it sounds, the parentheses coming first does bother folks. Every editor does syntax highlighting now. Do two things: (a) color the parens close enough to your background color that they visually fade and "back off", but are still visible when you need to look at them - your code instantly looks a bit more like python, indentation sticks out; (b) used a structured editing mode that inserts closing parens, keeps parens balanced automatically, and offers neat structured editing hotkeys to copy/cut/paste/delete sexp's (expressions) as units. Both steps are extremely comfort-building and the ubiquitous parens remove a class of bugs.

The greatest compliment to Common Lisp that I've seen over the past 8 years is the constant pilfering of language features to other mainstream languages.

As for readability - like Perl, TIMTOWTDI, and even moreso in Lisp because one can write macros as utilities to greatly simplify the actionable code and have it blow out into lower-level code that does the mechanical dirty work.

As a result of what I've said above, people working in CL do tend to write it slightly differently. You can see some evidence of that if you study different open source libraries, etc. It's not so much a rigid code style as an interest and ethos that binds the community.

I'll leave with a little example of macros at work, via the old and venerable SERIES library, that allows one to specify loops in a semi-declarative style, that if executed literally would cause multiple passes; but which compiles to a single pass over the data sequence.

The input is stock market "bars":

  (defvar *spy2006*
    '(("29-Dec-06" 142.08 142.54 141.43 141.62 45461200 141.62)
      ("28-Dec-06" 142.41 142.70 141.99 142.21 37288800 142.21)
      ("27-Dec-06" 141.87 142.60 141.83 142.51 39727100 142.51)
      ;; ...
     ))
This is what you might code, which I humbly submit to you is very readable:

  (defpackage iteration-testing-series (:use :cl :series))
  (in-package :iteration-testing-series)

  (defun combine-bars (bars)
    "Summarize a sequence of BARS into one bar."
    (series::let ((zbars (scan 'list bars)))
      (list (first (first bars))
            (second (first bars))
            (collect-max (map-fn 'float #'third zbars))
            (collect-min (map-fn 'float #'fourth zbars))
            (fifth (car (last bars)))
            (collect-sum (map-fn 'integer #'sixth zbars)))))
That function is very easy for me to read. Partially expanded, it becomes the following, which is itself further expanded. Note that it was trivial for me to request this expansion, and that multiple macros are composable so that many features can be engage at once. I can write something high-level, but also observe the expansion down to low-level code all the way (SBCL can even trivially show me the resulting assembler code for my CPU). I am freed up to think at a high level - but I don't lose control over the low level.

The following block may be daunting in size but if you know that SETQ is an assignment, and within the TAGBODY there are labels for GO which is like a goto, it should be possible for a programmer of other languages to follow. Not also the type declarations carried over for me automatically, which will allow for speed and debugging optimization, which in CL is a knob that I can turn - something I don't know exists in other languages.

  (LET* ((#:OUT-1014 BARS))
    (LET (ZBARS
          (#:LISTPTR-1012 #:OUT-1014)
          (#:ITEMS-1019 0.0)
          (#:NUMBER-1017 NIL)
          (#:ITEMS-1026 0.0)
          (#:NUMBER-1024 NIL)
          (#:ITEMS-1032 0)
          (#:SUM-1030 0))
      (DECLARE (TYPE LIST #:LISTPTR-1012)
               (TYPE FLOAT #:ITEMS-1019)
               (TYPE FLOAT #:ITEMS-1026)
               (TYPE INTEGER #:ITEMS-1032)
               (TYPE NUMBER #:SUM-1030))
      (TAGBODY
       #:LL-1035
        (IF (ENDP #:LISTPTR-1012)
            (GO SERIES::END))
        (SETQ ZBARS (CAR #:LISTPTR-1012))
        (SETQ #:LISTPTR-1012 (CDR #:LISTPTR-1012))
        (SETQ #:ITEMS-1019 (THIRD ZBARS))
        (IF (OR (NULL #:NUMBER-1017) ( #:NUMBER-1024 #:ITEMS-1026))
            (SETQ #:NUMBER-1024 #:ITEMS-1026))
        (SETQ #:ITEMS-1032 (SIXTH ZBARS))
        (SETQ #:SUM-1030 (+ #:SUM-1030 #:ITEMS-1032))
        (GO #:LL-1035)
       SERIES::END)
      (IF (NULL #:NUMBER-1017)
          (SETQ #:NUMBER-1017 NIL))
      (IF (NULL #:NUMBER-1024)
          (SETQ #:NUMBER-1024 NIL))
      (LIST (FIRST (FIRST BARS)) (SECOND (FIRST BARS)) #:NUMBER-1017
            #:NUMBER-1024 (FIFTH (CAR (LAST BARS))) #:SUM-1030)))

Re: Ooh Ooh My Turn Why Lisp? (2008)

#55
post #18

"The question is where will we be in five years, the answer is using Common Lisp, because of language features" says the author in the comments. This was 8 years ago. Kind of rude of me to take that potshot, but it's there. I've been reading these "Why Lisp?" Arguments for years and yet it still remains pretty niche. The longer this goes on the more I am unable tell Lisp advocates apart from Perl advocates. They both…

Hmm. In many walks of life, popular != best. In fashion, cars, investing, and to some extent cooking, for example, the top performing adherent is doing things differently than the crowd. Lisp code can be very readable, but it takes a few years to learn how to write it that way. I spent many years in Perl 5 myself, and I found Common Lisp tricky at first but ultimately very satisfying. Two jedi mind tricks for the beg…

>This is what you might code, which I humbly submit to you is very readable:

It's not, if that's a real life example. There is no context for what the data is, like a variable names.

Re: Ooh Ooh My Turn Why Lisp? (2008)

#56

Earlier quoted context omitted.

> I just don't see why you felt the need to correct me on my calling first=class functions "code as data" Because first-class functions aren't “code as data”. When you have a first-class function, the only thing you can do with it is call it. If it were a data structure, you could analyze its constituent parts. > You're basically interrupting me to tell me I'm not using the same definitions of words as you are, The W…

> Because first-class functions aren't “code as data”. When you have a first-class function, the only thing you can do with it is call it. If it were a data structure, you could analyze its constituent parts. There are lots of ways in which you can treat a first class function as data, even if it can't be treated 100% equivalently to data in every single situation. You can, for example, pass it to other functions lik…

> There are lots of ways in which you can treat a first class function as data, even if it can't be treated 100% equivalently to data in every single situation. You can, for example, pass it to other functions like data.

Strictly speaking, you can't pass functions as data. You can only pass thunks that, when forced, yield functions. A thunk is data, but a function is a computation. Computations are “too active” to be stored or passed around unthunked. The technical details are here: http://www.cs.bham.ac.uk/~pbl/cbpv.html, http://www.cs.bham.ac.uk/~pbl/papers/. (I am not the owner of the website, just in case.)

> Sure, most languages don't let you inspect the internals, but that's only one way of treating code as data.

What are the others?

> You're literally not even disagreeing with me, you're just defining "functional programming language" as "purely functional programming language",

How did you conclude that? I never said anything of the sort. What I said is “functional programming is programming with procedures that compute mathematical functions whenever possible”. Pure functional programming imposes further requirements, like effect segregation (as in Haskell) or even the total absence of effects (obviously unsuitable for a general-purpose language). FWIW, I'd count ML, Racket, Clojure and Erlang as functional languages.

> when I literally never even called Common Lisp a functional programming language.

You said Common Lisp has “functional aspects”. Well, closures make a language higher-order, but so do Java-style objects! For a language to be called “functional”, however, it has to make functional programming actually pleasant. I showed one fundamental limitation of Common Lisp in this regard: you can't define functions that take or return compound values, because Common Lisp doesn't have compound values in the first place.

Re: Ooh Ooh My Turn Why Lisp? (2008)

#57
post #18

"The question is where will we be in five years, the answer is using Common Lisp, because of language features" says the author in the comments. This was 8 years ago. Kind of rude of me to take that potshot, but it's there. I've been reading these "Why Lisp?" Arguments for years and yet it still remains pretty niche. The longer this goes on the more I am unable tell Lisp advocates apart from Perl advocates. They both…

Hmm. In many walks of life, popular != best. In fashion, cars, investing, and to some extent cooking, for example, the top performing adherent is doing things differently than the crowd. Lisp code can be very readable, but it takes a few years to learn how to write it that way. I spent many years in Perl 5 myself, and I found Common Lisp tricky at first but ultimately very satisfying. Two jedi mind tricks for the beg…

Regarding the hate for parens: rainbow coloring helps out big time. When each pair of parens has it's own color, it is very easy to see exactly how they are grouped in the more complex statements. For Vim, that would be Rainbowtags. It's actually an improvement for any languages, imo.

Re: Ooh Ooh My Turn Why Lisp? (2008)

#58
post #51
post #44

I want to see people's list of reasons for why not lisp. Edit: Ok, this is not trolling. I quite liked Lisp and actually had implemented a version of common lisp from scratch based the Guy Steele's CL reference back in the undergrad time. I just found that beyond academic and a few Emacs packages, I didn't use Lisp at all, for one reason or the other. I just want to hear people's reason for not picking Lisp for their…

I dislike Lisp (and Lisp-inspired languages like Scheme and Clojure) for two reasons: 1. their weak and dynamic type system, and 2. they don't control side-effects.

Haskel programmers: you can spot them by that constant pained look, as if they have to step in horse poop whenever they go outside.

Re: Ooh Ooh My Turn Why Lisp? (2008)

#59
post #18

"The question is where will we be in five years, the answer is using Common Lisp, because of language features" says the author in the comments. This was 8 years ago. Kind of rude of me to take that potshot, but it's there. I've been reading these "Why Lisp?" Arguments for years and yet it still remains pretty niche. The longer this goes on the more I am unable tell Lisp advocates apart from Perl advocates. They both…

I like niche stuff.

What language doesn't result in unmaintainable code, really?

And let me just say... it's a bit rude to spread this rumor that Lisp is anti-social and bad for business when you've barely even tried it. Seriously.

"Prove me wrong" is not a good way to discuss. See for yourself instead: learn Lisp and try to use it to write maintainable code.

Re: Ooh Ooh My Turn Why Lisp? (2008)

#60
post #46
post #37

Earlier quoted context omitted.

You confuse powerful with popular. Many startups don't need powerful tools, other than a CRUD framework and JQuery. Also, existence and abundance of libraries is a factor, and Lisp didn't get much love from the OSS web folks til recently.

Well, no, I'm not confusing powerful and popular. I'm asking why, for all lisp's power, there's almost no examples of that power actually doing anyone any good. Is it because most projects don't need something powerful? The benefits of that power aren't actually that great compared to the rest of the lisp baggage? We have this trope of the smug lisp weenie and there's definitely a whiff of high wizardry around lisp,…

> doing anyone any good

There's a difference between doing and talking about. Compare an amount of noise from Rust crowd to anything useful being done in Rust.

Let's look at only one product implemented in Lisp, by only one vendor, and it's users in only one industry - http://allegrograph.com/healthcare/. Pfizer, Mayo Clinic, GSK, Novartis - should we stop with that 'doing anyone any good' mantra?

Post reply on HN