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

321–330 of 339 posts

Re: Why Lisp?

#321

Post by thorondor83 »

ravi-delia wrote: post #288
freilanzer wrote: post #221

Earlier quoted context omitted.

> Once I opened up a project and realized I wanted one of them, but it was lost when the REPL closed. You don't type directly in the REPL most of the time. Send lines and functions to it instead.

Ohhh, I wondered why people were so hyped about that! In my head I rounded it off to not wanting to recompile the whole file- I should have realized how dumb that was. This actually makes a lot of sense. When I helped a friend set up Calva, a part of me was really just assuming it was misconfigured- but no, it's designed to facilitate this kind of editing. Though, I must ask, is it really that much better? I do keep…

> Though, I must ask, is it really that much better?

Yes, it is.

> Obviously it's handy to edit it in place, but it's nice having multiple versions, even multiple trees, without having to relocate a cursor or undo unrelated changes.

You can do both.

Re: Why Lisp?

#322

Post by ravi-delia »

pmarreck wrote: post #318
ravi-delia wrote: post #297

Earlier quoted context omitted.

Yeah, taste is taste. I do get it- it's why I like Clojure's syntax more than CLs, but man I don't get commas. Or even Elixir, I love the language but its always painful to come back to the syntax. Pipe operator aside, that is.

Speaking of the pipe operator, do Lisplikes have anything like that, or like pattern-matching, or complex value deconstruction, yet? One very nice thing in Elixir that ends up removing a ton of (possibly buggy) boilerplate logic on function entry is that the function heads pattern-match deeply on the structure of the input while also doing inline assignments.

I mean depending on what you mean by "have", yes? But also that's been true since the 90s. Out of the box, less so. Clojure has destructuring assignment, but no matching. A lot of little lisps downstream of Clojure (Janet, Fennel I think) do have matching, though not for function calls. I think that destructuring is most of the value add of pattern matching for me- that's not to say matching isn't great, just that destructuring is such a no-brainer value add that its hard to compete with. I do find myself missing the {:error, ...}, {:ok, ...} pattern in other languages. Nil punning doesn't give you anything close to as much, and at significant cost.

For pipes, the answer is definitely yes though. Clojure has arrow macros, which let you compose without nesting just like Elixir.

  (->> [1 2 3] (map inc) (filter even?) (reduce +)) => 6
There's one for threading through the first argument, and another for threading through the last, and various others for specific situations. Because they're pretty simple macros to write, I also use similar macros extensively in my CL code. In fact, I actually learned CL after getting used to Elixir so the first entry to my utilities package was a threading macro.

Re: Why Lisp?

#323

Post by fulafel »

ravi-delia wrote: post #322
pmarreck wrote: post #318

Earlier quoted context omitted.

Speaking of the pipe operator, do Lisplikes have anything like that, or like pattern-matching, or complex value deconstruction, yet? One very nice thing in Elixir that ends up removing a ton of (possibly buggy) boilerplate logic on function entry is that the function heads pattern-match deeply on the structure of the input while also doing inline assignments.

I mean depending on what you mean by "have", yes? But also that's been true since the 90s. Out of the box, less so. Clojure has destructuring assignment, but no matching. A lot of little lisps downstream of Clojure (Janet, Fennel I think) do have matching, though not for function calls. I think that destructuring is most of the value add of pattern matching for me- that's not to say matching isn't great, just that de…

I think Clojure has benefited from matching being kept out of the built-in stdlib. https://github.com/clojure/core.match is a plug-in and as a result we've had lots of cool data traversal/matching DSLs come around and evolved user communities with time such as Meander and Datascript not to mention the parsing applications of the schema systems (spec & malli).

Re: Why Lisp?

#324

Post by Pay08 »

leethomas wrote: post #91

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

Common Lisp has the declare form and it's siblings. It's not exactly static typing but it's close. Unfortunately, it does make the code a bit uglier.

Re: Why Lisp?

#325

Post by eimrine »

lispm wrote: post #216
latenightcoding wrote: post #211

Earlier quoted context omitted.

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

Am I understand right that Janet becames a Lisp (in your understanding of Lisp) if two conditions will be fullfilled: if everything will be reimplemented on linked lists with CAR/CDR everywhere and also a byte code interpreter will somehow coerce all the C syntax with ability to recompile all C code in such a way to fullfill a "no compile time" condition and that's it?

Sorry for speaking about things I do not understand, just I am searching for a comprehensive answer in "C vs Janet" question. I have a feel that there is something beautiful in Janet but I don't know what, so I have started this tree of discussion.

Re: Why Lisp?

#326

Post by aidenn0 »

ravi-delia wrote: post #284
hajile wrote: post #255

Earlier quoted context omitted.

Those REPLs aren’t even close to Common Lisp. Common Lisp borrowed parts of the smalltalk development strategy. You can start a process and gradually update it in very sophisticated ways as you live code against it. You wouldn’t dream of packaging up your Python REPL and shipping it to users. You certainly wouldn’t open a Python REPL on your production server and start redefining functions and data structures on the…

I know, I enjoy CL quite a bit. I actually currently have REPLs running for a few services, because I like managing them from the inside. But while you can , if you want, deploy major changes by redefining a bunch of stuff on production servers without version control or backups, you...should not. It's really nice to be able to redefine classes while you're playing around- but CL's handling of class redefinition just…

> If you had to pick between having REPL access in production and REPL access locally, would it be close? Because I value being able to mess around with a REPL while developing thousands of times as much as I like a neat toy in production. And that ability is exactly what Python or Ruby or Erlang give you. Technically lacking compared to the full suite? Perhaps. But we're talking 0.999, not 0.5.

I can't speak to Ruby or Erlang, but the Python REPL is much less than 0.999 because of the semantics of "import" making it very challenging to change code once it's been imported.

Re: Why Lisp?

#327

Post by aidenn0 »

sva_ wrote: post #94
dreamcompiler wrote: post #46

A point the authors didn't make is that Common Lisp compilers are quite fast compared to e.g. C++ compilers. So even in rare cases where you do need to recompile everything, the cycle time is short. CCL's compiler is lightning-fast. I can recompile an entire system in CCL almost as fast as I can load the compiled object code. SBCL's compiler is slower (while often generating faster code because it does more work at c…

Comparing it to C++ compilers... does Lisp have zero-cost abstractions?

Not quite to the degree that C++ does, but it's pretty good. There are several places in the standard that specifically allow for making a dynamism/performance tradeoff.

Re: Why Lisp?

#328

Post by lispm »

actuallyalys wrote: post #303
lispm wrote: post #273

Earlier quoted context omitted.

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

JavaScript started as a Scheme inspired language. It has runtime evaluation, a serialized data structure format, first class functions, garbage collection, dynamic typing, functional/imperative/object-oriented features, Many languages are not just looking at the syntax or the user-facing features of the language, but also at the implementation techniques of Lisp-like languages. An early example was Garbage Collection, which was invented for automatic and dynamic memory management of linked lists in the first Lisp implementation. R for example started as an attempt to reimplement S with a Scheme-like runtime.

Re: Why Lisp?

#329

Post by medo-bear »

foldr wrote: post #313
kazinator wrote: post #289

Earlier quoted context omitted.

The C++ that we have can only be used as an external tool: we write a character-level program into a pipe or file, which is read by an external program. This drops an object file that we have to process. I'm saying that we could have some Algol-like sublanguage with value semantics, and unboxed types. It could output code for a virtual machine, which could be further translated to native code. It would all be in Lisp…

That's all pie in the sky isn't it? I was talking about CL. The only practical suggestion I can take from this is that one could drop down to inline assembly in some CL implementations. It's unclear to me how that would help with the problem of defining unboxed arrays of structs.

I am not sure what you mean. If I want to use unboxed array of structs I can easily do so via FFI and create some sort of DSL for working with them. If this sounds like too much work for you, then yes we are at an impase. I think CL is great in this way in that writing FFIs is pretty natural. Also if you need performance code, why would you be worried too much about portability accross implementations. Maybe I am missing something

Anyway in Haskell you use unboxed arrays but without much of the high level benefits of the rest of the language. I fail to see how this is fundamentally different

Re: Why Lisp?

#330

Post by mmargerum »

Capricorn2481 wrote: post #264
reikonomusha wrote: post #259

Earlier quoted context omitted.

"Coalton doesn't actually work" is extremely disingenuous and easily misinterpreted to mean something that is not true. Coalton does work, and has been deployed for use in production on non-trivial, commercial problems. [1,2] Mutation is an issue with any Hindley-Milner system, because mutation is inherently impure and non-functional, violating principles that the Hindley-Milner algorithm relies on. The Coalton devel…

Honestly you're defending this a little too much. Nobody cares about an unfinished LISP spin-off that may be production ready some day. The OP's point still stands, CL lacks static types. This is frustratingly common with niche languages (and I am not saying CommonLisp is not productive, itself). If people are criticizing a missing feature in a language and the response is "Yeah, but we have some bespoke third-party…

I consider not having types a feature. One of the reasons i like clojure. spec > static types
Post reply on HN