Lisp Machine Manual (1984) • Hacker News Board

Re: Lisp Machine Manual (1984)

#61

Post by [deleted] » Wed, Sep 06, 2017, 9:01 PM UTC

Jach wrote: post #59

dwheeler wrote: post #21

Earlier quoted context omitted.

Asbestos suit on. There are many positive things you can say about Lisp. However, many day-to-day developers, and their managers, believe that Lisp's syntax creates nigh-unreadable programs. For example, there's no built-in infix syntax, as opposed to practically all other programming languages, and many modern programmers today expect infix as minimum table stakes for a language. Lisp syntax is extremely simple , bu…

Lacking infix syntax out of the box is a problem, though not hard to add as a sibling mentioned; for those curious I like linking to this gem dating back to '93 since it's part of quicklisp now https://github.com/rigetticomputing/cmu-infix The rest of the syntax being somewhat alien-ish is also a problem, but it goes away with practice. ( https://www.thejach.com/imgs/lisp_parens.png ) But I don't think syntax alone i…

[deleted]

Re: Lisp Machine Manual (1984)

#62

Post by AnimalMuppet » Wed, Sep 06, 2017, 9:02 PM UTC

fusiongyro wrote: post #54

AnimalMuppet wrote: post #49

Earlier quoted context omitted.

> C had a head start on high-end mainframes for actual work. No. C started on low-end minicomputers, not high-end mainframes. And why didn't Lisp take over the low-end minicomputers? Because Lisp was too resource-hungry, and those low-end minicomputers didn't have the muscle to run Lisp well. They ran C just fine, though.

So how did Lisp have the home court advantage then? :)

Because it existed, and C didn't. Because it had a decade of code already written, and C didn't. Because it ran on many machines, and C initially ran on one.

Re: Lisp Machine Manual (1984)

#63

Post by fusiongyro » Wed, Sep 06, 2017, 9:07 PM UTC

AnimalMuppet wrote: post #62

fusiongyro wrote: post #54

Earlier quoted context omitted.

So how did Lisp have the home court advantage then? :)

Because it existed, and C didn't. Because it had a decade of code already written, and C didn't. Because it ran on many machines, and C initially ran on one.

It ran on several machines, but not the ones that mattered. The existing code was irrelevant and not portable.

I'm not denigrating Lisp. I'm saying the network effects favored C because the PC happened to take off.

Re: Lisp Machine Manual (1984)

#64

Post by xfer » Wed, Sep 06, 2017, 9:11 PM UTC

dwheeler wrote: post #21

hoodoof wrote: post #2

There seems to be plenty of people who think Lisp is awesome. If so, then why hasn't it become "mainstream"?

Asbestos suit on. There are many positive things you can say about Lisp. However, many day-to-day developers, and their managers, believe that Lisp's syntax creates nigh-unreadable programs. For example, there's no built-in infix syntax, as opposed to practically all other programming languages, and many modern programmers today expect infix as minimum table stakes for a language. Lisp syntax is extremely simple , bu…

No infix operators is an advantage. I don't like memorizing precedence tables; most of the time people use parens just to be on safe-side anyways. It's even considered good practice in most cases.

I can see how lots of parentheses can look irritating (particularly at the end of expressions). But once you are familiar with it(it's not that hard) you can just read between parens and you don't see them anymore(most lisp code is well-indented). There is also a thing called sweet-exp that is supported by some popular lisps.

Re: Lisp Machine Manual (1984)

#65

Post by ScottBurson » Wed, Sep 06, 2017, 9:14 PM UTC

dwheeler wrote: post #21

hoodoof wrote: post #2

There seems to be plenty of people who think Lisp is awesome. If so, then why hasn't it become "mainstream"?

Asbestos suit on. There are many positive things you can say about Lisp. However, many day-to-day developers, and their managers, believe that Lisp's syntax creates nigh-unreadable programs. For example, there's no built-in infix syntax, as opposed to practically all other programming languages, and many modern programmers today expect infix as minimum table stakes for a language. Lisp syntax is extremely simple , bu…

The odd thing about the fully parenthesized syntax is that it's offputting at first, but once you've been doing it for a little while, in an editor that does parenthesis matching and auto-indentation, it gets to be just as easy and pleasant to work with as more common languages, or even more so. (Packages like Emacs 'paredit' make it even better. (I haven't tried 'parinfer'.))

I understand this is hard to believe if you haven't tried it, and it certainly does take some getting used to. Lisp is, in short, an acquired taste. Think of it like very spicy food: many people avoid it, but those of us who like it, like it a lot.

Re: Lisp Machine Manual (1984)

#66

Post by nocman » Wed, Sep 06, 2017, 9:16 PM UTC

AdeptusAquinas wrote: post #32

dwheeler wrote: post #21

Earlier quoted context omitted.

Asbestos suit on. There are many positive things you can say about Lisp. However, many day-to-day developers, and their managers, believe that Lisp's syntax creates nigh-unreadable programs. For example, there's no built-in infix syntax, as opposed to practically all other programming languages, and many modern programmers today expect infix as minimum table stakes for a language. Lisp syntax is extremely simple , bu…

As a day-to-day developer, but one who wants to learn as much as I can outside of my domain, you are spot on. I generally work in an OO language (C# specifically) and have long wanted to get into functional programming. I am finally making headway, but after false starts in lisp (racket, clojure) ultimately I am using F#. Partially, admittedly, due to the .NET aspect (its even shipped as part of default dotnet core)…

"replacing every curly bracket with 20 parenthesis (minor hyperbole)"

It isn't even minor hyperbole, it's just plain false.

It has been my experience that, generally speaking, the combination of curly brackets { }, square brackets [ ], and parens ( ) in languages with C-like syntax is at worst roughly equivalent to the number of parens in most lisp dialects.

Some people freak out because they see a function in a lisp that ends with:

  some-final-expression)))))

But they think that it is totally fine when a C-like langauge ends with:

          some_statement_or_expression
        }
      }
    }
  }

}

If the stacks of parens at the end bother you so much, there is nothing in most lisps preventing you from indenting them on lines too:

  some-final-expression
        )
      )
    )
  )

)

I wouldn't advise it, but you can do it.

I think more than anything, people are just unwilling to accept that lisps look different than the X number of curly-bracket-style languages they are used to. It looks weird to them at first, because of past experience, so to some degree they are looking for a reason to write them off from the beginning.

When I was in college, I had this initial reaction, and didn't even consider anything lisp-like for many years. It was only my frustration with the limitations of C-like langauges that led me to reconsider lisps years later, and man am I ever glad I did.

[EDIT for additional comment]:

and btw, I'm a "day-to-day developer" also.

Re: Lisp Machine Manual (1984)

#67

Post by xfer » Wed, Sep 06, 2017, 9:18 PM UTC

davexunit wrote: post #27

e40 wrote: post #23

Earlier quoted context omitted.

but it had a killer feature: it ran on commodity hardware, the PDP-11 That is not the essence of worse is better . UNIX won over the others because it was simple and regular, and was built from components that could be reassembled into more complex things. Pipes were a big part of that.

UNIX had a weak design. It won not because it was good, but because it ran on more computers. There are many other OSes of that time period that had superior designs. The Lisp Machine had way better composition primitives than UNIX's pipes passing plain text around.

The part of the problem they were hard to implement efficiently back then.

Re: Lisp Machine Manual (1984)

#68

Post by kazinator » Wed, Sep 06, 2017, 9:19 PM UTC

dwheeler wrote: post #21

hoodoof wrote: post #2

There seems to be plenty of people who think Lisp is awesome. If so, then why hasn't it become "mainstream"?

Asbestos suit on. There are many positive things you can say about Lisp. However, many day-to-day developers, and their managers, believe that Lisp's syntax creates nigh-unreadable programs. For example, there's no built-in infix syntax, as opposed to practically all other programming languages, and many modern programmers today expect infix as minimum table stakes for a language. Lisp syntax is extremely simple , bu…

Here is the thing about infix: the lack of infix probably does hurt, but not lack of the arithmetic infix. There is various syntactic sugar used in programming languages that is front-and-centre, expressing program and data structure, used everywhere.

I believe that most programmers won't have that much problem with (+ (* x x) (* y y)), but even those who don't will balk at cruft like (aref a 3), and (slot-value obj 'foo).

In the TXR Lisp language, I provide a set of well-targeted syntactic sugars for things like this; sugars which do not disturb the surrounding Lisp expressions and don't introduce ambiguities (precedence and associativity).

Re: Lisp Machine Manual (1984)

#69

Post by AdeptusAquinas » Wed, Sep 06, 2017, 9:35 PM UTC

nocman wrote: post #66

AdeptusAquinas wrote: post #32

Earlier quoted context omitted.

As a day-to-day developer, but one who wants to learn as much as I can outside of my domain, you are spot on. I generally work in an OO language (C# specifically) and have long wanted to get into functional programming. I am finally making headway, but after false starts in lisp (racket, clojure) ultimately I am using F#. Partially, admittedly, due to the .NET aspect (its even shipped as part of default dotnet core)…

"replacing every curly bracket with 20 parenthesis (minor hyperbole)" It isn't even minor hyperbole, it's just plain false. It has been my experience that, generally speaking, the combination of curly brackets { }, square brackets [ ], and parens ( ) in languages with C-like syntax is at worst roughly equivalent to the number of parens in most lisp dialects. Some people freak out because they see a function in a lisp…

You might be right in aggregate counts, but the difference is that in a C-style language you have different types of fluff: curly braces, parenthesis, semi colons etc. So the count of any one type is not overwhelming (unless you let your cyclomatic complexity get away from you). In Lisp its almost all parenthesis, so yes it is more.

Besides which my point is more that why have any of this at all? Only the insane write code without tab or space indentation, and if you are doing that anyway then an OCaml-esque language like F# where that serves as your grouping syntax is the saner option.

Re: Lisp Machine Manual (1984)

#70

Post by craigsmansion » Wed, Sep 06, 2017, 9:36 PM UTC

nocman wrote: post #66

AdeptusAquinas wrote: post #32

Earlier quoted context omitted.

As a day-to-day developer, but one who wants to learn as much as I can outside of my domain, you are spot on. I generally work in an OO language (C# specifically) and have long wanted to get into functional programming. I am finally making headway, but after false starts in lisp (racket, clojure) ultimately I am using F#. Partially, admittedly, due to the .NET aspect (its even shipped as part of default dotnet core)…

"replacing every curly bracket with 20 parenthesis (minor hyperbole)" It isn't even minor hyperbole, it's just plain false. It has been my experience that, generally speaking, the combination of curly brackets { }, square brackets [ ], and parens ( ) in languages with C-like syntax is at worst roughly equivalent to the number of parens in most lisp dialects. Some people freak out because they see a function in a lisp…

> I wouldn't advise it, but you can do it.

That's basically how I write functions in Lisp, with indentation levels and every closing parenthesis on a separate line.

The thing is, when you're done writing a (leaf)function in Lisp, you're done: it works. Since you won't need to revisit it (unless the functional design changes), you clean it up for compactness by grouping all closing parenthesis together.

I could be the only one, but I've always found it normal and practical to develop with indentation, and regroup when I'm done.