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

221–230 of 339 posts

Re: Why Lisp?

#221

Post by freilanzer »

ravi-delia wrote: post #31
jgoodhcg wrote: post #15

Earlier quoted context omitted.

I work with clojure and test driven development is not nearly as productive as repl driven development imo.

There's a place for both even with a REPL I think. Sometimes when I'm tracking a bug down or writing a new function against an old one, I find that I'm writing little one-off functions or worse, replicating a function body line by line in a let block to simulate arguments. Once I opened up a project and realized I wanted one of them, but it was lost when the REPL closed. I literally got as far as opening another file…

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

Re: Why Lisp?

#222

Post by skissane »

thou24343434 wrote: post #213
skissane wrote: post #180

Earlier quoted context omitted.

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

Why not just something like (require ‘cl-2029) to indicate one’s code is written to the new “Common Lisp 2029” standard? Which does its best to retain backward compatibility with existing code, but breaks compatibility whenever doing so is really worth it.

Re: Why Lisp?

#223

Post by medo-bear »

Blackthorn wrote: post #131
medo-bear wrote: post #125

Earlier quoted context omitted.

https://github.com/CodyReichert/awesome-cl#parallelism-and-c... https://github.com/thezerobit/green-threads edit: static typing https://github.com/coalton-lang/coalton

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?

Re: Why Lisp?

#224

Post by freilanzer »

armitron wrote: post #119
eterevsky wrote: post #111

Earlier quoted context omitted.

You could write safe-ish C++ and Rust that is both readable and fast. Could you point me to some benchmarks of Lisp being comparable to C? Also, unless I am mistaken, Common Lisp doesn't have strong types. How can you make either fast or safe language without compiler knowing the types?

You are mistaken, CL is strongly typed.

Strongly, but not statically typed.

Re: Why Lisp?

#225

Post by foldr »

lukego wrote: post #207
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.

Yeah. Common Lisp has quirks and you need to adapt your abstractions to those. Sometimes it's easy, sometimes it's rewarding, sometimes it's just annoying. This week I'm scaling back some abstractions, writing more Fortran-like code on specialized arrays than individual objects, for the sake of zero cost. I appreciate a little bit of a headwind against inventing new abstractions too casually. But it does remind me of…

This one isn’t a quirk, it’s a fundamental constraint on the kind of code that you can write in CL. C++, Rust, Go (and even Java to some extent, with all the wizardry in Hotspot) all allow you to build a 2D vector abstraction without requiring you to box your vectors. In CL you simply can’t do this. Just look at the kind of bonkers workarounds my comment gave rise to: https://news.ycombinator.com/item?id=35855576

Re: Why Lisp?

#226

Post by Rochus »

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 never heard Stroustrup using the term "zero cost", but only "zero overhead".

Re: Why Lisp?

#227

Post by lukego »

foldr wrote: post #225
lukego wrote: post #207

Earlier quoted context omitted.

Yeah. Common Lisp has quirks and you need to adapt your abstractions to those. Sometimes it's easy, sometimes it's rewarding, sometimes it's just annoying. This week I'm scaling back some abstractions, writing more Fortran-like code on specialized arrays than individual objects, for the sake of zero cost. I appreciate a little bit of a headwind against inventing new abstractions too casually. But it does remind me of…

This one isn’t a quirk, it’s a fundamental constraint on the kind of code that you can write in CL. C++, Rust, Go (and even Java to some extent, with all the wizardry in Hotspot) all allow you to build a 2D vector abstraction without requiring you to box your vectors. In CL you simply can’t do this. Just look at the kind of bonkers workarounds my comment gave rise to: https://news.ycombinator.com/item?id=35855576

I don't really see the problem. If you want to define the bit layout of your objects then you define them using FFI. Support for FFI objects is comprehensive. It is exactly the tool for the job in Common Lisp.

Same for LuaJIT. I've spent years happily writing high-level Lua code that's actually operating on objects whose bit layout is explicitly defined using FFI at the C level of abstraction. It doesn't feel much different to objects or dictionaries to me.

Sure, it is great that those other languages have native support for inlining storage of structs into various containers, but the lack of such in Common Lisp only makes me write quirky code and doesn't really hold me back.

Re: Why Lisp?

#228

Post by foldr »

lukego wrote: post #227
foldr wrote: post #225

Earlier quoted context omitted.

This one isn’t a quirk, it’s a fundamental constraint on the kind of code that you can write in CL. C++, Rust, Go (and even Java to some extent, with all the wizardry in Hotspot) all allow you to build a 2D vector abstraction without requiring you to box your vectors. In CL you simply can’t do this. Just look at the kind of bonkers workarounds my comment gave rise to: https://news.ycombinator.com/item?id=35855576

I don't really see the problem. If you want to define the bit layout of your objects then you define them using FFI. Support for FFI objects is comprehensive. It is exactly the tool for the job in Common Lisp. Same for LuaJIT. I've spent years happily writing high-level Lua code that's actually operating on objects whose bit layout is explicitly defined using FFI at the C level of abstraction. It doesn't feel much di…

It’s not a problem if you don’t need zero cost abstractions (which indeed you may not, depending on your domain). But if you do, then using the FFI to define unboxed arrays of a simple 2D point class is considerably less attractive than writing

    struct Point { float x, y };
    Point points[10];
If you really can’t see this then I think we’re at an impasse.

Re: Why Lisp?

#229

Post by pjmlp »

foldr wrote: post #220
pjmlp wrote: post #209

Earlier quoted context omitted.

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…

Genera, TI and Xerox thought otherwise.

Unfortunely all of them messed up on management, and fighting against free UNIX source tapes.

"What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better."

Re: Why Lisp?

#230

Post by pjmlp »

Rochus wrote: post #226
pjmlp wrote: post #209

Earlier quoted context omitted.

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 never heard Stroustrup using the term "zero cost", but only "zero overhead".

Here is a kind of reference to the matter,

"What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better."

https://boats.gitlab.io/blog/post/zero-cost-abstractions/

Post reply on HN