Modern, functional Common Lisp: myths and best practices • Hacker News Board

Re: Modern, functional Common Lisp: myths and best practices

#121

Post by lispm » Tue, Feb 25, 2020, 8:02 PM UTC

mikelevins wrote: post #117

lispm wrote: post #77

Earlier quoted context omitted.

I learned much of my initial Lisp programming decades ago with Macintosh Common Lisp. I found it to be incredible fun to work with a tight interactive environment on my Mac.

So did I--or, rather, I started with Coral Common Lisp, which is what it was called before Apple bought Coral Software. I found it hugely fun--so much so that it took over my brain. I've been primarily a Lisp programmer ever since. Coral Common Lisp offered an extremely easy way in to Lisp programming that was also tons of fun to work with, and an industrial-strength development environment for the full panoply of Ma…

I used MacScheme earlier, which also was a huge amount of fun - even though I did not have the extension to access the Mac Toolbox (Toolsmith, IIRC).

MCL was a whole new world then. First with Object Lisp and later with CLOS. I used MCL before it was owned by Apple - at one time it was called MACL (from a market agreement with Franz, IIRC). But later LispWorks was another step up, because it was a big grown up full extended Common Lisp with everything from the commercial UNIX workstation Lisps (like Allegro CL, Lucid CL, LispWorks): it suddenly ran on small and simple to use Apple or Windows laptops, plus it had a Cocoa port.

But, as you describe, the simplicity and integration of MCL into the early MacOS was a lot of fun and there was a lot of tinkering by users. Some friends were still using MCL years after it was obsolete...

Re: Modern, functional Common Lisp: myths and best practices

#122

Post by ThJ » Tue, Feb 25, 2020, 8:06 PM UTC

reikonomusha wrote: post #92

mumblemumble wrote: post #58

Assuming that the subtext here is wanting to address potential reasons for Lisp's chronic underpopularity, I think that all conversations like this miss the mark. Lisp was never failing to attract many users because people hadn't experienced sufficient evangelism about all its advanced features. It fails to attract many people because it's not a fun language to get started in. A year or so back I picked up a copy of…

As a professional user of lisp that works with it on a team and delivers products, I agree with the sentiment. Nobody I’ve had the pleasure of working with to on-board has had issues given about two weeks, but that’s in a different environment than a curious somebody who is just poking around from the internet. The effort to get an editor going and to open a file and load a package (“system” in CL) is a lot. Of cours…

They’re not? Take a look at at a Final Cut Pro.

Re: Modern, functional Common Lisp: myths and best practices

#123

Post by mikelevins » Tue, Feb 25, 2020, 8:26 PM UTC

lispm wrote: post #121

mikelevins wrote: post #117

Earlier quoted context omitted.

So did I--or, rather, I started with Coral Common Lisp, which is what it was called before Apple bought Coral Software. I found it hugely fun--so much so that it took over my brain. I've been primarily a Lisp programmer ever since. Coral Common Lisp offered an extremely easy way in to Lisp programming that was also tons of fun to work with, and an industrial-strength development environment for the full panoply of Ma…

I used MacScheme earlier, which also was a huge amount of fun - even though I did not have the extension to access the Mac Toolbox (Toolsmith, IIRC). MCL was a whole new world then. First with Object Lisp and later with CLOS. I used MCL before it was owned by Apple - at one time it was called MACL (from a market agreement with Franz, IIRC). But later LispWorks was another step up, because it was a big grown up full e…

I started with the full version of MacScheme about the same time that I started with CCL. I loved them both, and at first I liked MacScheme better because Scheme was a smaller, simpler language, and easier to learn. CCL won me over in the end because it was just so much easier to get things done.

Later on, John Ulrich, who owned Lightship Software, the publisher of MacScheme, came to work at Apple and became a friend and colleague. I continued to use MacScheme off and on for years.

I’ve happily paid for Lispworks licenses many times now, but even Lispworks isn’t a good solution for everything I want to use Lisp for. A modern version of CCL’s graphical environment would still be a nicer place for newbies to start. You could even use Lispworks to build a product like that, if the license didn’t prevent it. (Lispworks doesn’t allow their product to be used to make Lisp development systems, which is understandable. They’re a small company who don’t want to put themselves out of business by enabling a customer to give their Crown Jewels away.)

Re: Modern, functional Common Lisp: myths and best practices

#124

Post by jacobwilliamroy » Tue, Feb 25, 2020, 8:43 PM UTC

ThJ wrote: post #122

reikonomusha wrote: post #92

Earlier quoted context omitted.

As a professional user of lisp that works with it on a team and delivers products, I agree with the sentiment. Nobody I’ve had the pleasure of working with to on-board has had issues given about two weeks, but that’s in a different environment than a curious somebody who is just poking around from the internet. The effort to get an editor going and to open a file and load a package (“system” in CL) is a lot. Of cours…

They’re not? Take a look at at a Final Cut Pro.

Final Cut 10 is a prank, I'm sure of it.

Re: Modern, functional Common Lisp: myths and best practices

#125

Post by [deleted] » Tue, Feb 25, 2020, 8:47 PM UTC

abrax3141 wrote: post #61

mumblemumble wrote: post #58

Assuming that the subtext here is wanting to address potential reasons for Lisp's chronic underpopularity, I think that all conversations like this miss the mark. Lisp was never failing to attract many users because people hadn't experienced sufficient evangelism about all its advanced features. It fails to attract many people because it's not a fun language to get started in. A year or so back I picked up a copy of…

First off, Lisp is chronically POPULAR not unpopular. (It is critically unpopular.) Secondly, Lisp is the most fun you can have programming, yeah from the start. You apparently had either a very poor teacher, or taught yourself Lisp ... same thing.

[deleted]

Re: Modern, functional Common Lisp: myths and best practices

#126

Post by nybble41 » Tue, Feb 25, 2020, 8:50 PM UTC

lispm wrote: post #119

nybble41 wrote: post #113

Earlier quoted context omitted.

I agree with you on the first point. There are good technical reasons why TCO can't be implemented on some platforms. However, that just punts the issue one level down the stack: These platforms should have built in support for guaranteed TCO. As for language features like dynamic scoping, I would say that a function call which needs to be followed by some cleanup activity is not in tail position, so TCO would not ap…

They are often explicit, but they are widely used and often generated behind the scenes by macros or declarations.

Macros would need to specify whether any expressions will be evaluated in tail position. However, expressions in macros don't look like they should be subject to TCO, so the default assumption should be that they aren't unless declared otherwise. Do you have any examples of cases that would be likely to cause confusion—in particular where a function call appears to occur in tail position in the code but can't be TCO'd because of a macro?

Re: Modern, functional Common Lisp: myths and best practices

#127

Post by jacobwilliamroy » Tue, Feb 25, 2020, 8:53 PM UTC

reikonomusha wrote: post #80

tombert wrote: post #73

I really need to learn CL one of these days; I know Clojure reasonably well, and enough Lisp-Flavour-Erlang, Chicken Scheme, and Racket to be dangerous, but for some reason I seem to have completely avoided CL. Based on the blog posts I've read, it seems like CL occupies the kind of space I want to be in: sort of the halfway point between theoretical and engineering. Is that a fair conclusion to draw?

It’s a practical language that sometimes chooses less elegant ways to do things in favor of a complete, robust engineering experience. For instance, the fact defined functions sit in a different namespace than values creates mostly aesthetic ugliness where named functions and named values have different treatments. (defun f (x) (* x x)) (setq g (compose f f)) (g 5) This is wrong in Common Lisp on many levels: f must…

I like it. But the really nice thing about lisp is if there's something I dont like, I can just hack the evaluator to fix it.

Re: Modern, functional Common Lisp: myths and best practices

#128

Post by lispm » Tue, Feb 25, 2020, 8:55 PM UTC

mikelevins wrote: post #123

lispm wrote: post #121

Earlier quoted context omitted.

I used MacScheme earlier, which also was a huge amount of fun - even though I did not have the extension to access the Mac Toolbox (Toolsmith, IIRC). MCL was a whole new world then. First with Object Lisp and later with CLOS. I used MCL before it was owned by Apple - at one time it was called MACL (from a market agreement with Franz, IIRC). But later LispWorks was another step up, because it was a big grown up full e…

I started with the full version of MacScheme about the same time that I started with CCL. I loved them both, and at first I liked MacScheme better because Scheme was a smaller, simpler language, and easier to learn. CCL won me over in the end because it was just so much easier to get things done. Later on, John Ulrich, who owned Lightship Software, the publisher of MacScheme, came to work at Apple and became a friend…

yes, building a product to include development tools (compiler, ...) of LispWorks or Allegro CL would be expensive and not really attractive. I think Franz, Inc. has such a licensing agreement for Allegro CL, but their licensing model is different anyway.

In former times there was a market for add-one GUI or IDE tools. Lucid CL made money from licensing their Lisp to other companies, which then resold those with tools added on (like the SUN Common Lisp IDE). The Action! GUI designer was available for MCL. CLIM was an add-on product. The big Expert System development environments were available as add-on products to Lisp systems.

For a commercial customer something like LispWorks or Allegro CL might still be worth it - they are technically very stable platforms.

Re: Modern, functional Common Lisp: myths and best practices

#129

Post by jacobwilliamroy » Tue, Feb 25, 2020, 8:58 PM UTC

btilly wrote: post #114

reikonomusha wrote: post #100

Earlier quoted context omitted.

I don’t like this argument and paints a picture that Lispers are overly concerned by some academic aspect of programming. Many people, myself included, use Lisp because it lets us get something done more quickly, more efficiently, more easily, or all three. It’s true. Importing flask in Python and starting a server takes about 1/2 as much code as in Lisp. Some extraordinarily routine stuff Python has down to a one-li…

The following phrase is telling. " But after a certain very short prototyping period, I end up fighting Python’s terrible deployment, terrible efficiency, and slapdash language implementation when trying to build something robust. " How many programmers would see Python's language implementation as "slapdash" or care? The fact that you both see it that way and care speaks volumes towards you fitting my characterizati…

>cant agree on which unpopular language everyone should use

All lispers agree everyone should use lisp. Any lisper that doesnt like lisp is welcome modify that lisp to make it something the lisper does like.

Re: Modern, functional Common Lisp: myths and best practices

#130

Post by mikelevins » Tue, Feb 25, 2020, 9:27 PM UTC

lispm wrote: post #128

mikelevins wrote: post #123

Earlier quoted context omitted.

I started with the full version of MacScheme about the same time that I started with CCL. I loved them both, and at first I liked MacScheme better because Scheme was a smaller, simpler language, and easier to learn. CCL won me over in the end because it was just so much easier to get things done. Later on, John Ulrich, who owned Lightship Software, the publisher of MacScheme, came to work at Apple and became a friend…

yes, building a product to include development tools (compiler, ...) of LispWorks or Allegro CL would be expensive and not really attractive. I think Franz, Inc. has such a licensing agreement for Allegro CL, but their licensing model is different anyway. In former times there was a market for add-one GUI or IDE tools. Lucid CL made money from licensing their Lisp to other companies, which then resold those with tool…

I tried to work out a way to reimplement my old programmable WYSIWIG word-processor, Alpaca, using Lispworks, but we've been unable to reach an agreement that works for me and for Lispworks. They don't want me to make something that someone could use to compete with their product, and I don't want to make a crippled version of Alpaca.

I wrote the original Alpaca in CCL, using its Cocoa interface. I used it to write a book, and a Japanese company approached me about licensing it for a product, but I fell ill before I could do anything more with it. By the time I recovered enough to look at it again, it had bitrotted. The macOS interfaces had changed out from under it.

I imagine I could fix it up and get it going again, but I'd really like to make a version of Alpaca that works on Linux and Windows as well as macOS. The obstacle is that I need a rich-text engine that can do a good job with page layout, and I don't know whether there's a suitable one, or which Lisp (that isn't Lispworks) would be best to use with it. Qt maybe? Perhaps with ECL? I guess I'd rather use CCL or SBCL. Anybody know of a text-and-page-layout engine or collection of libraries that will work well on macOS, Linux, and Windows with CCL or SBCL?