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

Why Lisp?

nyxt.atlas.engineer

Post reply on HN
Print view View original

211–220 of 339 posts

Re: Why Lisp?

#211

Post by latenightcoding »

lispm wrote: post #208
latenightcoding wrote: post #205

Earlier quoted context omitted.

>> it does not use linked lists at its core does Clojure? I can implement a Scheme interpreter that passes most test suites using vectors instead of linked lists, would you not consider it a lisp?

> I can implement a scheme that passes most test suites using vectors instead of linked lists, would you not consider it a lisp? My Symbolics Lisp Machine has a Lisp implementation where some form of vectors are an optimization of lists (-> CDR coding). But that's an implementation detail. For most purposes the thing behaves as it uses linked lists - and even has primitive operators for linked lists as CPU instructio…

So if Janet refactored the interpreter to use linked lists, CONS/CAR/CDR everywhere in the C code but the language stayed the same (if possible) would it fit your definition of being a lisp ?

Re: Why Lisp?

#212

Post by robocat »

munch117 wrote: post #79
surfpel wrote: post #10

Earlier quoted context omitted.

The irony of this comment is that HN is written in Lisp.

I thought HN was written in Arc. I don't think the interoperability between Common Lisp implementations extends to Arc.

https://github.com/wting/hackernews/blob/master/news.arc

Out of date, but you can read the ARC code as HN was 11 years ago.

Re: Why Lisp?

#213

Post by thou24343434 »

skissane wrote: post #180
thou24343434 wrote: post #176

Earlier quoted context omitted.

Common Lisp (CL) is not the entirety of the Lisp world. However, CL does have a lot of limitations given its 30-year old design. 1. The typing is vague, annoying and its weird half-assed existence to a CLOS is a constant source of trouble 2. Code-walking is not completely deterministic and is not implementation independent. 3. The environment is not part of the standard. CL was written in a completely different time…

> CL was written in a completely different time when there was money to be made selling various bespoke implementations, and therefore there was a big need to vagueness in the spec. Today this need is much less so Part of the issue here is that the spec has essentially been abandoned, and frozen for the last almost 30 years. The committee which produced it decided to dissolve itself. If the surviving major commercial…

At this point you can't fix CL without creating a new language.

Re: Why Lisp?

#214

Post by funcDropShadow »

bjoli wrote: post #206
cutler wrote: post #174

Earlier quoted context omitted.

Clojure is head and shoulders above other lisps. Watch Rich Hickey's Sermons From the Mount in the years following Clojure's release and you may never be the same again. At least that was my experience. David Nolen's Clojurescript videos are similarly riveting. Clojure also has far more reach than any other lisp with implementations for JS, JVM, .Net and recently Dart/Flutter. It also has a library - libpython - for…

What about it is head and shoulders above other lisps? The ecosystem? The lack of first class continuations? All the things that can be portably implemented in any language?

Clojure makes simple code easy to write and maintain. It is more practical than most other Lisps by wisely choosing on which giants should to stand. E.g.

- make immutability the normal case, yet it is sufficiently performing that one rarely has to go back to mutability

- minimal syntax, uniformity, dynamic typing, macro-system, symbols from Lisp

- it extends Lisp with namespaces, even symbols get namespace

- access to the whole ecosystem of the JVM, of Javascript and mostly to Python's ecosystem

The price for accessing those ecosystems was omitting first class continuations. Which one is more valuable depends on your use case, but for many use cases I am considering that was the right choice.

Re: Why Lisp?

#215

Post by BaculumMeumEst »

kagevf wrote: post #201
BaculumMeumEst wrote: post #18

i cant even install this program on my system because of common lisp’s insane dependency management so count me as unconvinced

If you’re referring to Nyxt, I’ve been using guix to install it, and it takes care of all the dependencies, including getting them right so that connecting to Nyxt’s swank server can be done from emacs.

it's doable, on linux systems i don't mind doing that. but on my mac i don't want to use all that disk space, particularly for a for-funsies web browser (although i really do like the browser).

and for other programs, if CL CFFI bindings don't build on your platform then nix or guix can't save you

sucks because i love lisp but CL is just not good for program distribution

Re: Why Lisp?

#216

Post by lispm »

latenightcoding wrote: post #211
lispm wrote: post #208

Earlier quoted context omitted.

> I can implement a scheme that passes most test suites using vectors instead of linked lists, would you not consider it a lisp? My Symbolics Lisp Machine has a Lisp implementation where some form of vectors are an optimization of lists (-> CDR coding). But that's an implementation detail. For most purposes the thing behaves as it uses linked lists - and even has primitive operators for linked lists as CPU instructio…

So if Janet refactored the interpreter to use linked lists, CONS/CAR/CDR everywhere in the C code but the language stayed the same (if possible) would it fit your definition of being a lisp ?

> So if Janet refactored the interpreter to use linked lists

Which interpreter do you mean? A Lisp interpreter, which runs Lisp source code or a byte code interpreter?

Lisp is defined that it processes lists, either compiled or interpreted.

I'm looking at interpreted Lisp code in a debugger:

  CL-USER 19 : 1 > :lambda 
  (LAMBDA (A) (DECLARE (SYSTEM::SOURCE-LEVEL #)) (DECLARE (LAMBDA-NAME FOO)) (SETF A (+ 10 A)) (BREAK) (+ A 20))

  CL-USER 20 : 1 > (car (nthcdr 5 *))
  (BREAK)
The code which is interpreted, is Lisp code in the form of lists. Lists are processed in user programs and the implementation itself processes Lisp code in the form of lists. Both are using the same list data structure, the same representation of the list data structure and the same primitive operators for it.

For me that's the core of Lisp.

If the language and its implementation does not process lists, then don't call it to be a "List Processor".

Re: Why Lisp?

#217

Post by lukego »

linguae wrote: post #50
7thaccount wrote: post #40

After learning Python, I wanted to take the next step and find what was better. I looked into a lot of languages reading books on Haskell and Lisp and many others. At least for my use cases (desktop scripting, numerical work... etc) I didn't find Lisp to be superior. Most of what I actually needed to do could be done simpler in Python. Python's REPL isn't near as good as CL, but it's good enough. Then the batteries i…

As a Lisp fan who sometimes codes in Scheme and Common Lisp whenever I get the chance, I agree with you. The gap has certainly narrowed in the past 20 or so years between Lisp and widely-used programming languages. In addition, the rise of statically-typed functional programming languages like OCaml and Haskell provide another alternative for those who love functional programming but want Hindley-Milner types. I stil…

> 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 you fancied, why not just keep using that implementation?

The reason I'd choose Python in practice would be as a social compromise with collaborators.

(I say this having recently switched from Julia to Common Lisp because I didn't feel the ecosystem was giving me much practical benefit.)

Re: Why Lisp?

#218

Post by bjoli »

Hammershaft wrote: post #86
tiffanyh wrote: post #71

Reminder, HN is built/runs-on a dialect of Lisp (Arc). On a single server. On a single core.

genuinely amazing, is there a writeup on this?

Is it? HN is mostly static content. Ten years ago I wrote a simple web application using twister (python) that did well over a thousand requests per second. If we count just handling requests (and not churning out much data or doing anything fun processing) japronto for python claims to handle something like 1.2 million req/s on a single thread.

Re: Why Lisp?

#219

Post by kagevf »

BaculumMeumEst wrote: post #215
kagevf wrote: post #201

Earlier quoted context omitted.

If you’re referring to Nyxt, I’ve been using guix to install it, and it takes care of all the dependencies, including getting them right so that connecting to Nyxt’s swank server can be done from emacs.

it's doable, on linux systems i don't mind doing that. but on my mac i don't want to use all that disk space, particularly for a for-funsies web browser (although i really do like the browser). and for other programs, if CL CFFI bindings don't build on your platform then nix or guix can't save you sucks because i love lisp but CL is just not good for program distribution

In the off-chance you're not aware, their download page has links for macOS - https://nyxt.atlas.engineer/download

One each for docker and MacPorts.

Re: Why Lisp?

#220

Post by foldr »

pjmlp wrote: post #209
foldr wrote: post #113

Earlier quoted context omitted.

Sure, there may be reasons for it, but it means you can’t really build zero cost abstractions. For example, you can’t make a simple 2D vector object with the standard operations defined over it and then store those vectors in flat arrays. This is something that can trivially be done in C++, Rust, etc.

That isn't what Bjarne means by zero cost abstractions. It means the abstractions produce the same code as having written the same manually without the abstraction, e.g. having a class with virtual methods versus having a struct with function pointers as fields.

I interpret the term compostitonally. But CL doesn’t have zero cost abstractions in that sense either.

Take the example I mentioned. Say that you’re looping through an array of pairs of 2D vectors and calculating the dot product of each pair. In C++ you can use your 2D vector class without any additional cost. In CL you either need to remove that abstraction (and deal with flat arrays of scalars) or incur the cost of boxing.

More generally, if every object with its own methods requires a boxed representation, then that severely limits the range of zero cost abstractions that you can create. If using the abstraction requires boxing then it’s not zero cost. (If Bjarne disagrees on that point, then I disagree with him!)

Anyway, I’m sure you know all this, so I’m not really sure what point you’re trying to make here. I don’t think anyone would suggest that CL is a good language for building zero cost abstractions, whatever the precise definition of the term.

Post reply on HN