Lisp implementation in sed • Hacker News Board

Re: Lisp implementation in sed

#51

Post by lispm » Sat, Jun 28, 2014, 8:58 AM UTC

rtpg wrote: post #48

KC8ZKF wrote: post #44

Earlier quoted context omitted.

Another theory is that there are far fewer symbols in Lisp than python or coffeewhatever, making it easier to read.

this is more of a "symbols per line" argument rather than "symbols in the language" argument. grade = (student) -> if student.excellentWork "A+" else if student.okayStuff if student.triedHard then "B" else "B-" else "C" (from coffescript examples) Imagine how many more symbols that would have in any lisp dialect

    (defun grade (student)
      (cond ((excellent-work student) :a+)
            ((okay-stuff     student) (if (tried-hard student) :b :b-))
            (t                        :c)))

Re: Lisp implementation in sed

#52

Post by bad_login » Sat, Jun 28, 2014, 9:25 AM UTC

rtpg wrote: post #48

KC8ZKF wrote: post #44

Earlier quoted context omitted.

Another theory is that there are far fewer symbols in Lisp than python or coffeewhatever, making it easier to read.

this is more of a "symbols per line" argument rather than "symbols in the language" argument. grade = (student) -> if student.excellentWork "A+" else if student.okayStuff if student.triedHard then "B" else "B-" else "C" (from coffescript examples) Imagine how many more symbols that would have in any lisp dialect

   ;; comparing with racket:

   (define (grade student)
     (cond 
      [(excellent-work student) "A+"]
      [(and (okay-stuff student) (tried-hard student)) "B"]
      [(okay-stuff student) "B-"]
      [else "C"]))

   ;; Or

   (require racket/match)

   (define (grade student)
     (match (map (lambda (fn) (fn student)) 
                 '(excellent-work okay-stuff tried-hard))
       [(list #t _ _)  "A+"]
       [(list _ #t #t) "B"]
       [(list _ #t _)  "B-"]
       [else           "C"]))

Re: Lisp implementation in sed

#53

Post by asgard1024 » Sat, Jun 28, 2014, 9:32 AM UTC

Wouldn't the opposite - stream editor (programmable) in Lisp - be more useful?

Re: Lisp implementation in sed

#54

Post by illo » Sat, Jun 28, 2014, 9:33 AM UTC

lispm wrote: post #51

rtpg wrote: post #48

Earlier quoted context omitted.

this is more of a "symbols per line" argument rather than "symbols in the language" argument. grade = (student) -> if student.excellentWork "A+" else if student.okayStuff if student.triedHard then "B" else "B-" else "C" (from coffescript examples) Imagine how many more symbols that would have in any lisp dialect

(defun grade (student) (cond ((excellent-work student) :a+) ((okay-stuff student) (if (tried-hard student) :b :b-)) (t :c)))

Erlang, just for fun:

  grade(#student{work=Work, tried_hard=Tried}) -> grade1(Work, Tried).
  grade1(excellent_work, _) -> 'a+';
  grade1(okay_stuff, yes) -> b;
  grade1(okay_stuff, _) -> 'b-';
  grade1(_, _) -> c.

Edit: formatting.

Re: Lisp implementation in sed

#55

Post by dghf » Sat, Jun 28, 2014, 10:13 AM UTC

rtpg wrote: post #48

KC8ZKF wrote: post #44

Earlier quoted context omitted.

Another theory is that there are far fewer symbols in Lisp than python or coffeewhatever, making it easier to read.

this is more of a "symbols per line" argument rather than "symbols in the language" argument. grade = (student) -> if student.excellentWork "A+" else if student.okayStuff if student.triedHard then "B" else "B-" else "C" (from coffescript examples) Imagine how many more symbols that would have in any lisp dialect

Clojure:

    (defn grade [student]
      (cond
        (excellent-work student)  "A+"
        (okay-stuff student)      (if (tried-hard student) "B" "B-")
        :else                     "C"))

Re: Lisp implementation in sed

#56

Post by mbrock » Sat, Jun 28, 2014, 10:36 AM UTC

Crito wrote: post #28

catshirt wrote: post #23

Earlier quoted context omitted.

i am not particularly gifted at computer science and especially not programming languages. by necessity, the only languages i know are JavaScript and lisp. so I am always surprised to hear lisp is "unreadable" as opposed to "unfamiliar".

I think that Lisp got a reputation for being unreadable because some Lisp programmers have the tendency to get too far into macros to extend the language, resulting in a language that other developers have not seen before.

I think that's pretty much a straw man. Where is all this terrible macro-laden Lisp code? Well, it's probably not totally made up, but you run into overcomplicated abstractions in every language.

Somehow it seems more likely that people are put off by the slightly "isolationist" culture of Lisp, or the historical clash between Lisp and Unix, or whatever, and then this "unreadable" idea is like a rationalization for not liking the language? This is just a hunch...

You could make all kinds of arguments for the difficulty and obscurity of Haskell, yet it's winning ground quite effectively. I think this basically started with the success of GHC and Cabal/Hackage in creating an infrastructure that's familiar and efficient.

The Lisp world always had good infrastructure engineering. The main compilers (SBCL, CMUCL, etc) are very impressive! But it takes a very intensive kind of community engagement nowadays to stay up to date.

I still think Lisp could have a renaissance. Maybe it's already going on with Clojure. And of course Emacs is quite strong.

The ideal of programming seems to be software architectures based on layers of coherent abstraction. That's very, um, abstract, and there are different ways to do it. With OO, you imagine objects cooperating in layers. With Haskell-like functional programming, you use a mathematical style of abstraction, trying to find theories and algebras that make sense and compose, building applications out of combinations of well-typed values, etc.

Paul Graham describes the Lisp style in his texts on Lisp. You can see it in Emacs's various DSLs (for defining customization parameters, for traversing buffers, etc). It encourages abstraction layers built so as to form mini-languages. So a library can easily provide custom syntactic forms. Instead of having a small number of syntactic forms (if, for, etc) and an expression language based on function application, Lisp is syntactically extensible.

Programming is not a solved problem! We still aren't really sure about how to design programs, how to create coherent abstraction layers. The Haskell approach is very interesting, but not totally fleshed out. People are still working out the best way to structure concurrent I/O pipelines with error handling, for example. I sort of lost my train of thought, but Lisp is very interesting!

Re: Lisp implementation in sed

#57

Post by aaronem » Sat, Jun 28, 2014, 1:34 PM UTC

asgard1024 wrote: post #53

Wouldn't the opposite - stream editor (programmable) in Lisp - be more useful?

Well, if you count Emacs in batch mode, such a thing already exists.

Re: Lisp implementation in sed

#58

Post by sfk » Sat, Jun 28, 2014, 2:02 PM UTC

lispm wrote: post #51

rtpg wrote: post #48

Earlier quoted context omitted.

this is more of a "symbols per line" argument rather than "symbols in the language" argument. grade = (student) -> if student.excellentWork "A+" else if student.okayStuff if student.triedHard then "B" else "B-" else "C" (from coffescript examples) Imagine how many more symbols that would have in any lisp dialect

(defun grade (student) (cond ((excellent-work student) :a+) ((okay-stuff student) (if (tried-hard student) :b :b-)) (t :c)))

I'm always amazed that I hardly ever program in Lisp and yet these short snippets are more readable than any other language.

Re: Lisp implementation in sed

#59

Post by JadeNB » Sat, Jun 28, 2014, 5:47 PM UTC

illo wrote: post #54

lispm wrote: post #51

Earlier quoted context omitted.

(defun grade (student) (cond ((excellent-work student) :a+) ((okay-stuff student) (if (tried-hard student) :b :b-)) (t :c)))

Erlang, just for fun: grade(#student{work=Work, tried_hard=Tried}) -> grade1(Work, Tried). grade1(excellent_work, _) -> 'a+'; grade1(okay_stuff, yes) -> b; grade1(okay_stuff, _) -> 'b-'; grade1(_, _) -> c. Edit: formatting.

Or, if we're going to go with Prolog-inspired syntax, then why not Prolog?

    grade(Student, Grade) :-
        worked(Student, Work), work_grade(Work, Student, Grade).
    work_grade('Excellent', _, 'A+').
    work_grade('Okay', Student, 'B') :- tried_hard(Student).
    work_grade('Okay', _, 'B-').
    work_grade(_, _, 'C').

I'm a bit rusty, and I don't have a Prolog interpreter to hand to test, so I might have got some syntax wrong.

Re: Lisp implementation in sed

#60

Post by Blackthorn » Sat, Jun 28, 2014, 5:51 PM UTC

mbrock wrote: post #56

Crito wrote: post #28

Earlier quoted context omitted.

I think that Lisp got a reputation for being unreadable because some Lisp programmers have the tendency to get too far into macros to extend the language, resulting in a language that other developers have not seen before.

I think that's pretty much a straw man. Where is all this terrible macro-laden Lisp code? Well, it's probably not totally made up, but you run into overcomplicated abstractions in every language. Somehow it seems more likely that people are put off by the slightly "isolationist" culture of Lisp, or the historical clash between Lisp and Unix, or whatever, and then this "unreadable" idea is like a rationalization for n…

It's not a straw man for me -- it's what I think of a lot of Lisp code.

I think it's really instructive to compare things written in the early days of Clojure to Clojure right now. Some times I just want to find the author of some code block, shake them, and yell "No! The only reader macros you are allowed to use are ', `, and #() !". Absolutely beautiful language, but way too easy to make unreadable.