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

101–110 of 161 posts

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

#101

Post by bibyte »

lispm wrote: post #97
bibyte wrote: post #93

Earlier quoted context omitted.

The word "compiler" is so overloaded that every time someone mentions one it turns into an argument. This is the whole transpiler vs compiler vs interpreter vs JIT argument. The trouble is that sometimes some programmers implement all of them (myself included). > CLISP has its own virtual machine, which is the target of its compiler Then CPython is also a compiler? and Lua?

Yes, generally any source to byte-code translator is a compiler. The byte-code then can either be interpreted or compiled, too. Since the default CPython implementation interpreted the byte code, it was said it's an interpreter - but strictly speaking it is not. Originally interpreters were implementations which execute source code - which in Lisp is widely available. For example SBCL for a long time only had a nativ…

Fair enough. My assumption was that you would consider a source to bytecode compiler an interpreter (to be fair most people do). The next time I say something about Common Lisp I will list all the implementations instead of saying something as simplistic as "compiler" or "interpreter".

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

#102

Post by tombert »

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?

Yeah, that's why the company I work for lets me use Clojure occasionally; we have a metric ton of libraries written in Java and being able to interop with them more-or-less seamlessly is a huge selling point for Clojure.

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

#103

Post by reikonomusha »

ithrow wrote: post #99
reikonomusha wrote: post #95

Earlier quoted context omitted.

Most adequate for what? Peer acceptance?

Are you just purposely ignoring them? adequate for most businesses (the JVM and its ecosystem its going to be accepted way faster than a CL runtime).

I read the comment in its entirety. The adequacy of tools is most often measured by their ability to solve the problems at hand. If the problems are primarily social or legacy, then I could see a completely valid argument that using something JVM-based is most adequate. But one might argue Lisp isn’t adequate at all at that point, and one ought to simply use Java.

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

#104

Post by vindarel »

Ambrevar wrote: post #5
pfdietz wrote: post #4

I've been doing some functional style programming in Common Lisp, and I was wondering what exactly should be considered functional programming. In particular, is object identity with EQ consistent with functional programming? Constructors do not act like functions if EQ is the equality. Or should that be more "immutable programming"? Common Lisp, because it has EQ and object identity, cannot perform some optimization…

Immutability is something I'm still exploring in Common Lisp. Any pointer, anyone?

https://github.com/smithzvk/modf like setf, but doesn't mutate the data (didn't try).

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

#105

Post by reikonomusha »

AnimalMuppet wrote: post #81
abrax3141 wrote: post #61

Earlier quoted context omitted.

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.

Chronically popular ? Unless you're using some weird definitions, I would expect to see Lisp used more if you were correct.

The time integral of usage is maybe greater than most languages. Admittedly that’s a conflation of longevity with popularity.

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

#106

Post by lispm »

bibyte wrote: post #101
lispm wrote: post #97

Earlier quoted context omitted.

Yes, generally any source to byte-code translator is a compiler. The byte-code then can either be interpreted or compiled, too. Since the default CPython implementation interpreted the byte code, it was said it's an interpreter - but strictly speaking it is not. Originally interpreters were implementations which execute source code - which in Lisp is widely available. For example SBCL for a long time only had a nativ…

Fair enough. My assumption was that you would consider a source to bytecode compiler an interpreter (to be fair most people do). The next time I say something about Common Lisp I will list all the implementations instead of saying something as simplistic as "compiler" or "interpreter".

It's also complicated because some implementations support several modes. ECL for example has a Lisp interpreter, a byte-code compiler&interpreter and a native compilation via C. All code variants can work together and call each other.

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

#107

Post by ska »

tom-thistime wrote: post #46
phoe-krk wrote: post #40

Earlier quoted context omitted.

These four things are common myths . It says so in the very line above them. This article is literally about debunking these myths.

Yeah, I read it. Can you explain how "red herrings" differ from "myths"? Is the distinction really that important? My point was that it is not just myths (or red herrings either) that are holding Lisp back. There are some issues based in reality as well.

I think the distinction is both easy to make and important.

Myths are widely held to be fundamental about a thing (but not necessarily true). Red herrings, on the other hand, are a distraction that draws your attention away from the actual matter at hand.

So that said, I think what you are trying to say is that contrary to the poster, you believe focusing on these myths is a red herring and there are other fundamental reasons that lisp popularity remains what it is. I suspect because you did not articulate the difference, your discussion got sidetracked into semantics because it sounded like you were saying they were "the same thing"

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

#108

Post by ska »

lukego wrote: post #15
pfdietz wrote: post #4

I've been doing some functional style programming in Common Lisp, and I was wondering what exactly should be considered functional programming. In particular, is object identity with EQ consistent with functional programming? Constructors do not act like functions if EQ is the equality. Or should that be more "immutable programming"? Common Lisp, because it has EQ and object identity, cannot perform some optimization…

I really enjoy Common Lisp being imperative enough to make iteration and collection orthogonal. You can freely mix-and-match functions for traversing data structures (dohash, maphash, etc) and ways to accumulate values (setf, push, ext:collect, etc.) I find that equivalent purely functional code often needs more functions to both traverse and collect at the same time e.g. fold, map, flatmap, etc. I know that the func…

I would far rather have CL's explicit representation of the different types of equality, than many languages approach of either a) "you can't do that" or b) just getting it wrong sometimes. So I would hardly call that behind the times, although the interface could be nicer I suppose.

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

#109

Post by tombert »

reikonomusha wrote: post #103
ithrow wrote: post #99

Earlier quoted context omitted.

Are you just purposely ignoring them? adequate for most businesses (the JVM and its ecosystem its going to be accepted way faster than a CL runtime).

I read the comment in its entirety. The adequacy of tools is most often measured by their ability to solve the problems at hand. If the problems are primarily social or legacy, then I could see a completely valid argument that using something JVM-based is most adequate. But one might argue Lisp isn’t adequate at all at that point, and one ought to simply use Java.

Clojure has some other selling points outside of interop though.

For example, Clojure's built-in concurrency primitives like Atoms and Refs are (in my opinion) substantially easier to work with than dealing with "synchronized" or anything like that in Java, and if you're willing to import a library for it, core.async gives you very pleasant Go-like concurrency with channels as well. This allows for a very reactive design that also happens to be safe and relatively easy to debug.

There's also the ability to use macros, which, depending on the use-case, can often replace the need for reflection that you occasionally might have with Java.

Last, it's relatively easy to hook into a running Clojure session with nrepl, meaning that you can use some very-nice runtime debugging and updating without downtime if you're clever.

---------

These features are in most functional languages in some capacity, but most functional languages don't have good interop with Java; the sales pitch for Clojure is comparatively easy: "We should use this language with all these neat features, but where we can use our current stuff just fine".

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

#110

Post by abrax3141 »

AnimalMuppet wrote: post #86
mumblemumble wrote: post #71

Earlier quoted context omitted.

Yes, thanks for putting it so concisely. Personally, I do think Lisp is fun, and was having fun pretty much from the start. But, with how many people I've watched just bounce off of it, I simply can't bring myself to imagine that my experience is anything but unusual. Nor am I inclined to console myself with self-congratulatory stories about Blub.

I suspect that certain styles fit the way certain people think, and don't fit the way that other people think. If Lisp fits the way you think, then learning it is a revelation - it's like being let out of prison. But if it doesn't fit, it's really hard. And those who find Lisp to be "the right way" (for them) expect that if everyone else really understood Lisp, they'd have the same magical experience. When everyone e…

I think that this is a function of how you were taught, not a personal preference. An excellent teacher can make pretty much anything interesting to pretty much anyone.
Post reply on HN