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

231–240 of 339 posts

Re: Why Lisp?

#231

Post by gpderetta »

Paul-Craft wrote: post #161
chlorion wrote: post #159

Earlier quoted context omitted.

That's a very good question and the same thing I ask myself whenever I consider using some lisp (for hobby purposes mostly). I came to the conclusion that scheme is a better language from a technical standpoint and I enjoy using it more, but the primary issue is that lisp is already sort of niche, and scheme is like a niche inside of a niche, which in practice results in the "ecosystem" being very weak. By ecosystem,…

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

Re: Why Lisp?

#232

Post by foldr »

pjmlp wrote: post #229
foldr wrote: post #220

Earlier quoted context omitted.

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

My original comment talked about 'portable CL'.

I am interested though: how would you define an unboxed array of structs in Genera's dialect of Lisp?

Your quote clearly applies to my example. You can avoid the boxing by hand coding the dot product computation over flat arrays; you can't avoid the boxing if you use a 2D vector abstraction (in CL).

Re: Why Lisp?

#233

Post by kazinator »

foldr wrote: post #228
lukego wrote: post #227

Earlier quoted context omitted.

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.

In Lisp, we can embed a lower-level language, and macro over it. Like the defx86lapfunction forms in this file:

https://github.com/Clozure/ccl/blob/master/level-0/X86/x86-a...

It would be useful to have a more abstract, portable form of this (vaguely analogous to WebAssembly): a way to write code for a low level virtual machine that translates to native code.

Re: Why Lisp?

#234

Post by lukego »

foldr wrote: post #228
lukego wrote: post #227

Earlier quoted context omitted.

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.

I can meet you in the middle on "considerably less attractive" :-)

For what it's worth, if I wanted zero-cost then the way I'd probably write that in Common Lisp would be with a more spartan abstraction like:

  (deftype f () 'double-float)
  (deftype points () '(simple-array (2 *) f))

  (-> euclidian-distance (f f f f) f)
  (defun euclidian-distance (x1 y1 x2 y2)
    (sqrt (+ (expt (- x2 x1) 2) (expt (- y2 y1) 2))))

  (-> point@ (points integer) (values f f))
  (defun point@ (points i)
    (values (aref points 0 i)
            (aref points 1 i)))
I'll grant you that's a kludge compared with your example. It wouldn't hold me back though. And I wouldn't consider trading in my lovely late-bound programming environment for an issue of this magnitude.

Re: Why Lisp?

#235

Post by eviks »

> The Lisp designers do not assume what syntax, features or functions will be necessary in the future. The developers of Lisp give you the full powers that they had to develop the language.

Isn't that ~ abdicating responsibility for language design?

Re: Why Lisp?

#236

Post by Rochus »

pjmlp wrote: post #230
Rochus wrote: post #226

Earlier quoted context omitted.

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/

Here is the relevant paragraph from Stroustrup, B (2013): The C++ programming language, 4th edition. Pearson Education, page 10:

"What you don’t use you don’t pay for. If programmers can hand-write reasonable code to simulate a language feature or a fundamental abstraction and provide even slightly better performance, someone will do so, and many will imitate. Therefore, a language feature and a fundamental abstraction must be designed not to waste a single byte or a single processor cycle compared to equivalent alternatives. This is known as the zero-overhead principle."

I don't know who came up with "zero cost" abstractions, but it's wrong since there is no zero cost. For the people chanting "zero cost" the cost might not be obvious though.

Re: Why Lisp?

#237

Post by vindarel »

dataangel wrote: post #194
vindarel wrote: post #130

Earlier quoted context omitted.

> static strong typing Alright, here is it: https://github.com/coalton-lang/coalton/ > small efficient native binaries The numbers are: with SBCL's core-compression, a web app with dozens on dependencies will weight ±30 to 40MB. This includes the compiler, the debugger, etc. Without core compression, we reach ±150MB. > The actor runtime? the actor library : https://github.com/mdbergmann/cl-gserver > couldn't find a w…

Coalton doesn't actually work: https://github.com/coalton-lang/coalton/issues/84?s=09 This is why it's important to always look at the issues on a repo instead of just believing what's in the README. It fails to detect type errors in some of the most basic situations

Interesting. Fortunately, they are making clear Coalton didn't reach "v1.0".

Re: Why Lisp?

#238

Post by medo-bear »

foldr wrote: post #228
lukego wrote: post #227

Earlier quoted context omitted.

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.

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

Re: Why Lisp?

#239

Post by lincpa »

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?

[dead]

Re: Why Lisp?

#240

Post by pdimitar »

LispSporks22 wrote: post #191
pdimitar wrote: post #97

I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, a…

All that stuff you're worried about is just implemented in libraries. Lisp lets you do that. You don't have to wait around years for a ECMA committee or whatnot to provide you a "async" keyword, or any other keyword. The language is flexible enough to let you add it yourself. It's a whole change of mindset. In practice however, several people probably implemented "async" independently and the community as a whole jus…

Also in practice: no ready-baked solution and I am not gonna move the ecosystem when I just want to do some commercial work with it, because nobody is gonna pay me to evolve the ecosystem.

Maybe an article or two demonstrating step by step how does one invent their own async runtime exactly would be hugely helpful in terms of credibility.

Otherwise it's just handwaving and I am sure you can see it.

Post reply on HN