Live data from Hacker News

Why Lisp?

nyxt.atlas.engineer

301–310 of 339 posts

Re: Why Lisp?

#301
post #263

Earlier quoted context omitted.

sure taken separately that looks more elegant. but, provided your whole program is complex enough, i think if you take a step back your language of choice is gonna look like a pigs sty compared to the same thing written in common lisp. i think the amazing thing about common lisp as a high level language is that it can be a low language also. imo it is an unmatched balance of a high/low level language

Are there any examples of elegant CL code that performs lots of vector geometry calculations? I'm skeptical that this sort of code would come out elegantly in CL (at least if it had to perform reasonably well).

[deleted]

Re: Why Lisp?

#302
post #142

I like lisps syntactically. The only thing stopping me from using it more frequently is the lack of static typing. I wasn't always a stickler for static typing, but I've spent a lot of time working with Scala and TS and the main advantage for me is ease of refactoring and avoiding NPEs. EDIT: What I'm continuously evaluating for myself is Clojure specifically

Check out Coalton.

Coalton static typing doesn't actually work, there's an issue filed that it breaks as soon as you do any mutation.

Re: Why Lisp?

#303
post #273

Earlier quoted context omitted.

JavaScript and R are more Lisp-inspired to me. I tend to think of the Lisp family as containing Scheme, Clojure, and other languages with a fairly close resemblance. Common Lisp, its predecessors, and a few other languages like uLisp are more closely related still and are practically, if not strictly, the same language. I’m not sure this informal taxonomy is “right,” but it seems to be useful and in line with common…

what is this fairly close resemblance? Parentheses? There are a bunch of Lisp like languages without s-expression syntax: Lisp 2, Logo, MDL, RLISP, CLISP (not the CL implementation), Dylan, Racket with its new syntax (Racket2, Rhombus), Skill, ... For example Dylan is based on Scheme & CLOS + a different syntax + some other influences. https://opendylan.org https://github.com/dylan-lang/opendylan/blob/master/sources/…

Expression-based and supporting macros are two big features JavaScript lacks that the ones with the close resemblance have. Subjectively, they also have constructs in common that make coding relatively similar (although the presence of features like CLOS, continuations, and multimethods can have a pretty big effect). And yes, they use the same S-expression syntax. (Although you can be a Lisp without it.)

In fairness, R might be closer than I realized since I’ve never done extensive programming in it.

Re: Why Lisp?

#304

Earlier quoted context omitted.

The first two links, when it comes to green threads, have nothing that fit the bill. They are not transparent. They have all the problems of clojure's core.async. What you need is to be able to call existing blocking code and have the runtime take care of it. A macro based solution cannot do this, because macros are purely source to source transforms. If it can't access the source, it can't modify it. It must be done…

> They are not transparent what does this mean?

I mean "can it call blocking code without bringing everything to a screeching halt".

Re: Why Lisp?

#306

Earlier quoted context omitted.

> Very rarely do I feel like I'm missing something in elisp, with the exception of concurrency support! I have some good news for you, then! Cooperative threading was added in Emacs 26: https://www.gnu.org/software/emacs/manual/html_node/elisp/Th... https://www.emacswiki.org/emacs/NoThreading I've never used it, but the big disadvantage seems to be that unless you're going to do some super advanced macrology, any fun…

Didn't emacs add actual support for OS threads recentishly?

Not to my knowledge. Apparently, according to https://www.emacswiki.org/emacs/NoThreading, dynamic scope makes it devilishly difficult to implement os-level threading. It is, apparently, possible to automatically translate elisp into a lexically scoped lisp dialect, and rebuilt emacs on that foundation, but, again, to my knowledge, nobody's done that. And, there are occasional mutterings about making a new, natively multithreaded emacs, but nothing's ever made it into the GNU emacs repo, AFAIK.

It does have process-based concurrency, which is basically where you spawn off a whole new emacs, then run your code within that. I've never used it, so I don't know how it works, other than the obvious disadvantage of having a large startup time and potentially memory use to start up another instance of emacs.

Re: Why Lisp?

#307
post #275

Here's a question the article doesn't answer: why Common Lisp? I.e. why not Scheme? Scheme is a plenty powerful language these days with all the libraries it has available. Granted, it doesn't have history going back to the 1950s, but it does date back to the 1970s. There are also multiple implementations, each with its own set of strengths. And there are some solid standards written for the language that have good i…

I like Scheme, but prefer Common Lisp for its environments and the old-school feel of the language. > And there are some solid standards Good things don't come alone: R5RS, R6RS, R7RS, RNRS + SRFI X..Y, IEEE Scheme, Racket, ... > entry for 'kludges' That's a form of self-deprecating humor, if you missed it. There are many more funny index entries in CLtL. The core designers did not take themselves too serious. Especi…

> That's a form of self-deprecating humor, if you missed it.

No, of course, I didn't miss that. ;) Yes, it was funny! But the mere fact that it's a joke made by none other than Guy Steele, and that Lisp as a language goes back to 1960, which is old enough to make it eligible for a retirement pension in most countries, tells me that there's a bit of truth to it.

Re: Why Lisp?

#308
post #299
post #217

Earlier quoted context omitted.

> if I’m writing a machine learning application or a web application, then I’ll most likely reach for Python or JavaScript, respectively, due to the library ecosystems. This sounds eminently sensible but it never pans out that way in practice for me: How do you understand the ML algorithms if you haven't implemented them yourself? And if you have implemented them for the sake of understanding, in whatever language yo…

Do you drive a car you built from scratch? How can you drive from A to B without first understanding how a car works by building one? And since you already built one, why not just keep using that one? Or maybe you have built a car. But did you type your message on a computer you built yourself using some silicon and a home-baked x-ray lithography machine? I definitely think there can be value in reimplementing someth…

Fair point on general.

My limited experience with probabilistic sorts of programming though is that the risk of misunderstanding/misuse is very high relative to the implementation complexity. Cars and. X-ray machines don't have simple implementations.

Often very little code but a lot of opportunities to goof up one assumption or another.

But yeah I'm probably overgeneralizing from limited experience.

Re: Why Lisp?

#309

Earlier quoted context omitted.

What about Racket makes it not a Scheme?

Here’s the piece they wrote explaining the decision to rename: https://racket-lang.org/new-name.html Racket qua Racket (and PLT Scheme before the rename) didn't conform to any of the existing Scheme specs (it was something like R5RS minus some things it didn’t like, plus some things from R6RS, plus a whole bunch of its own stuff.)

After looking at the Racket website, from the POV of someone who wants to use or learn Scheme, that doesn't sound like a useful distinction. They have R5RS and R6RS implementations that look to have reasonable conformance with the corresponding standards. I don't see how the fact that the language called "Racket," which is a lispy language that implements (among other things) R5RS, R6RS, and mzscheme even matters. It sounds an awful lot like like saying "foo-scheme isn't a scheme because it's implemented partly in C."

Re: Why Lisp?

#310

Earlier quoted context omitted.

Didn't emacs add actual support for OS threads recentishly?

Not to my knowledge. Apparently, according to https://www.emacswiki.org/emacs/NoThreading , dynamic scope makes it devilishly difficult to implement os-level threading. It is, apparently, possible to automatically translate elisp into a lexically scoped lisp dialect, and rebuilt emacs on that foundation, but, again, to my knowledge, nobody's done that. And, there are occasional mutterings about making a new, natively…

You are indeed right. I had understood that actual preemptive threads had been added, but it seems that for now it is still cooperative and requires explicit yields.

Note that elisp has lexical scoping now, but it will be years of course before all packages will have been updated (and for many things you still want dynamic scoping).

Post reply on HN