Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern, functional Common Lisp: myths and best practices

ambrevar.xyz

Post reply on HN
Print view View original

131–140 of 161 posts

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

#131

Post by btilly »

jacobwilliamroy wrote: post #129
btilly wrote: post #114

Earlier quoted context omitted.

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.

And that is the problem.

Lispers wind up with a myriad of incompatible Lisps, and a solution written for one may or may not be portable to the next. Sure, you can call them all Lisp. But Common Lisp, Emacs Lisp, Clojure, and Racket are, syntactic similarities notwithstanding, actually different languages. A library written for one will generally not work for the others.

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

#132

Post by lispm »

nybble41 wrote: post #126
lispm wrote: post #119

Earlier quoted context omitted.

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

For example I see sometimes macros which generate code with compilation quality (speed, ...) declarations for all or parts of their code. Depending on the combination of qualities TCO might be enabled or disabled in code sections.

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

#133

Post by jacobwilliamroy »

btilly wrote: post #131
jacobwilliamroy wrote: post #129

Earlier quoted context omitted.

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

And that is the problem. Lispers wind up with a myriad of incompatible Lisps, and a solution written for one may or may not be portable to the next. Sure, you can call them all Lisp. But Common Lisp, Emacs Lisp, Clojure, and Racket are, syntactic similarities notwithstanding, actually different languages. A library written for one will generally not work for the others.

Then its only a ten-minute diversion to modify that library to work with my lisp. Or to build a library in my lisp which can work with that library.

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

#134

Post by dgb23 »

btilly wrote: post #116
dgb23 wrote: post #112

Earlier quoted context omitted.

I can only speak from the perspective of using Clojure, I toyed around with Racket and have no experience with CL. That said, I disagree with some of the points you make: > availability of useful libraries Clojure is embedded in both JS runtimes and the JVM. Both feature massive ecosystems. In terms of getting things done: Languages like Python, JS and so on are fantastic at plumbing. But when it comes to modelling d…

Yes, Clojure is a special case. But still let's address your points. Languages like Python, JS and so on are fantastic at plumbing. But when it comes to modelling data-structures, manipulation and algorithms then they are far less expressive and productive than Clojure from my experience. My experience differs. It is hard to find a data structure that cannot be modeled with Python's native data structures with only a…

> My experience differs. It is hard to find a data structure that cannot be modeled with Python's native data structures with only a constant performance penalty. In fact I believe that I have only seen one, and I don't remember what it is.

My claim isn't that they don't exist or that one cannot implement them in for example Python (which is very false). I was imprecise there. What I was trying to say is that there is a higher degree of uniformity and generality to do the same in Clojure, which leads to more cleanliness and easier, more fluent abstractions. Clojure code (and I assume similar to true with other Lisps) feels more compatible with itself so to speak. Syntax plays a role here but also the fact that Clojure is designed to be primarily an FP language.

> I agree with the points that suck about Clojure. To them I must add, "It is hard to hire people who already know the ecosystem." For real businesses this is a non-trivial issue. (...)

I fully agree with this and with the rest of your points. I think there might also be factor of personal taste or way of thinking.

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

#135

Post by btilly »

jacobwilliamroy wrote: post #133
btilly wrote: post #131

Earlier quoted context omitted.

And that is the problem. Lispers wind up with a myriad of incompatible Lisps, and a solution written for one may or may not be portable to the next. Sure, you can call them all Lisp. But Common Lisp, Emacs Lisp, Clojure, and Racket are, syntactic similarities notwithstanding, actually different languages. A library written for one will generally not work for the others.

Then its only a ten-minute diversion to modify that library to work with my lisp. Or to build a library in my lisp which can work with that library.

I disbelieve.

A complex application written with CLOS will generally not be portable to Emacs Lisp. An application written in Emacs Lisp that takes advantage of dynamic scope won't be easy to port to Clojure. A library in Clojure that wraps something in the JVM ecosystem won't work in Racket. And something written in Racket using continuations or Pict generally won't be easy to port to Common Lisp.

And even with closer Lisps than that, I have enough experience of "that should be easy to port" then blowing up over minor details to be suspicious. Sometimes it will be 10 minutes. Sometimes it will be several weeks and incomplete even then. The latter happens often enough that, the developer's confidence notwithstanding, the average is waaaay longer than the estimated 10 minutes. (The phenomena of tasks being rarely faster than we thought, but roadblocks can be unlimited in extent is generally true in programming. This is one of the reasons why our time estimates tend to be systemically low.)

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

#136

Post by dreamcompiler »

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…

If I were doing the above a lot, I'd write compose as a macro (or better yet a compiler macro). In that case, the only thing above that needs to be changed is the setq, which would have to be written as

  (setf (fdefinition g) (compose f f))
Still different from Scheme, but some of the differences can be papered over with macros.

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

#137

Post by jacobwilliamroy »

btilly wrote: post #135
jacobwilliamroy wrote: post #133

Earlier quoted context omitted.

Then its only a ten-minute diversion to modify that library to work with my lisp. Or to build a library in my lisp which can work with that library.

I disbelieve. A complex application written with CLOS will generally not be portable to Emacs Lisp. An application written in Emacs Lisp that takes advantage of dynamic scope won't be easy to port to Clojure. A library in Clojure that wraps something in the JVM ecosystem won't work in Racket. And something written in Racket using continuations or Pict generally won't be easy to port to Common Lisp. And even with clos…

And if the library is not easy to port, then writing an interface which generates code that DOES work with that library is easy to do.

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

#138

Post by dreamcompiler »

Scarbutt wrote: post #85
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?

Just mentioning it for historical reasons (someone correct if this is wrong), Rich Hickey was enlightened by CL after doing lots of Java/C#/C++, after doing much CL he created Clojure. To answer your question, the JVM has wide acceptance in the industry and a big ecosystem of libraries, from a business and practical point of view, it seems the most adequate choice for a Lisp?

CL compiles down to the metal in most cases (ABCL being a notable exception). I've written device drivers in CL, realtime code in CL, and many CL implementations even allow you to write in assembler. I've done that too, in order to take advantage of SIMD hardware. The above would be -- problematic -- on top of the JVM.

There also might be an issue of speed, since CL is compiled to the metal. Modern JIT JVMs probably have mostly eliminated CL's speed advantage, but I'd still be surprised if some things in SBCL (arguably the best-optimized CL) didn't run faster than in Clojure.

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

#139

Post by btilly »

dgb23 wrote: post #134
btilly wrote: post #116

Earlier quoted context omitted.

Yes, Clojure is a special case. But still let's address your points. Languages like Python, JS and so on are fantastic at plumbing. But when it comes to modelling data-structures, manipulation and algorithms then they are far less expressive and productive than Clojure from my experience. My experience differs. It is hard to find a data structure that cannot be modeled with Python's native data structures with only a…

> My experience differs. It is hard to find a data structure that cannot be modeled with Python's native data structures with only a constant performance penalty. In fact I believe that I have only seen one, and I don't remember what it is. My claim isn't that they don't exist or that one cannot implement them in for example Python (which is very false). I was imprecise there. What I was trying to say is that there i…

I understand what you are saying. I am unable to back it up or refute it from my personal experience. I do not know Clojure well enough.

I do know from personal experience that programming in a familiar environment is significantly more productive than programming in an unfamiliar one. And that many, many programmers have mistaken their personal productivity for the productiveness of the environment.

This is one of the causes of a lot of "holy wars". Because everything from indentation style, to operating system, to text editor, to language feels critical. And indeed is...for the programmer who hasn't learned how to switch between these things.

If someone had an oracle that could give us the answer, I would happily take an even money bet that something of this at least contributes to how much you prefer Clojure.

I also agree with you that there is a lot of personal taste and way of thinking involved. And furthermore that our opinions usually match whatever environment(s) we imprinted on. (In the interests of full disclosure, my background is math, Perl and relational databases.)

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

#140

Post by btilly »

jacobwilliamroy wrote: post #137
btilly wrote: post #135

Earlier quoted context omitted.

I disbelieve. A complex application written with CLOS will generally not be portable to Emacs Lisp. An application written in Emacs Lisp that takes advantage of dynamic scope won't be easy to port to Clojure. A library in Clojure that wraps something in the JVM ecosystem won't work in Racket. And something written in Racket using continuations or Pict generally won't be easy to port to Common Lisp. And even with clos…

And if the library is not easy to port, then writing an interface which generates code that DOES work with that library is easy to do.

I still disbelieve.

I've done this. I've seen other people do this. Sometimes it works. Sometimes it doesn't. Sometimes it works fine for the demo but then has weird failure modes that you trip over in production months later.

It may be the right thing to do. It may be feasible. But a general "10 minute job" estimate is laughable.

Post reply on HN