Lisp syntax is awesome. It's a mindset shift, and most folks don't want to make that jump. Once you get used to it though, Lisp is just as readable as any other kind of code.
Lisp syntax is awesome. It's a mindset shift, and most folks don't want to make that jump. Once you get used to it though, Lisp is just as readable as any other kind of code.
I've worked with and love Python and JavaScript. I always heard Lisp described as some Holy Grail of coding, and I kinda get it now. This article finally helped me understand the appeal of Lisp....
I've worked with and love Python and JavaScript. I always heard Lisp described as some Holy Grail of coding, and I kinda get it now. This article finally helped me understand the appeal of Lisp. Though I don't think I'll be trading Python for Lisp any time soon.
If you're interested in exploring a more functional language without making the whole jump to lisp yet, check into Elixir. I tried it out on the first few days of Advent of Code a couple of years...
If you're interested in exploring a more functional language without making the whole jump to lisp yet, check into Elixir. I tried it out on the first few days of Advent of Code a couple of years ago and was very surprised to discover that I got all the answers correct on the first try. Something about the way it forces you to decompose problems makes it super easy to build up a program that solves the problem correctly.
I think the idea of code as data is interesting, but the motivation offered seems lacking. In general, we do want to put bounds on what a user can do through a remote interface , so offering an...
I think the idea of code as data is interesting, but the motivation offered seems lacking. In general, we do want to put bounds on what a user can do through a remote interface , so offering an open pipe for arbitrary execution doesn't seem that attractive.
But…your spidey sense may already be tingling. What if the user was malicious ... Uh oh…our cookie would get sent to iwillp3wn.com, and the malicious user would indeed pwn us. We can’t use eval; it’s too dangerous.
Is there some way that sending arbitrary lisp that is (presumably) executed blindly by the remote any more safe?
I'd be interested if any Lispians can offer other applications that make lisp the "sweet spot".
As someone familiar with Lisp and has read this article multiple times over the years, I'd agree with your take. Using JavaScript to reinvent JSONified lisp-like execution is bizarre and I don't...
As someone familiar with Lisp and has read this article multiple times over the years, I'd agree with your take. Using JavaScript to reinvent JSONified lisp-like execution is bizarre and I don't know why anyone would do this in production.
In unix, code is data. We have a binary executable—that is a file on disc, same as any other—and we can run it, executing its contents 'blindly'. Various structural mechanisms are afforded for...
In unix, code is data. We have a binary executable—that is a file on disc, same as any other—and we can run it, executing its contents 'blindly'. Various structural mechanisms are afforded for access control. But you can do anything you like, given a 'remote connection' over ssh and a root password, can't you? The same thing applies uniformly here; the difference is that we have far more expressive tools.
I do find the statement that '[w]e can't use eval; it's too dangerous' specious. It is an incidental property of js that it does not provide first-class mechanisms for encapsulating untrusted code; and it is uniformly true that within any language we can make an implementation of another language (or the same one) which does not have that problem. Or we can design our languages to have uniform object capabilities, or at the very least first-class global environments so that such tricks are not needed.
From what I understand as someone who has dabbled with lisp, the major appeal of lisp is the ease of extending the language with powerful macros (part of the reason why there were so many lisps,...
From what I understand as someone who has dabbled with lisp, the major appeal of lisp is the ease of extending the language with powerful macros (part of the reason why there were so many lisps, arguably why it fell in popularity). This means that you are encouraged to implement DSLs, which limit possible valid code
Lisp syntax is awesome. It's a mindset shift, and most folks don't want to make that jump. Once you get used to it though, Lisp is just as readable as any other kind of code.
I've worked with and love Python and JavaScript. I always heard Lisp described as some Holy Grail of coding, and I kinda get it now. This article finally helped me understand the appeal of Lisp. Though I don't think I'll be trading Python for Lisp any time soon.
If you're interested in exploring a more functional language without making the whole jump to lisp yet, check into Elixir. I tried it out on the first few days of Advent of Code a couple of years ago and was very surprised to discover that I got all the answers correct on the first try. Something about the way it forces you to decompose problems makes it super easy to build up a program that solves the problem correctly.
I think the idea of code as data is interesting, but the motivation offered seems lacking. In general, we do want to put bounds on what a user can do through a remote interface , so offering an open pipe for arbitrary execution doesn't seem that attractive.
Is there some way that sending arbitrary lisp that is (presumably) executed blindly by the remote any more safe?
I'd be interested if any Lispians can offer other applications that make lisp the "sweet spot".
As someone familiar with Lisp and has read this article multiple times over the years, I'd agree with your take. Using JavaScript to reinvent JSONified lisp-like execution is bizarre and I don't know why anyone would do this in production.
I think it's just a thought experiment.
In unix, code is data. We have a binary executable—that is a file on disc, same as any other—and we can run it, executing its contents 'blindly'. Various structural mechanisms are afforded for access control. But you can do anything you like, given a 'remote connection' over ssh and a root password, can't you? The same thing applies uniformly here; the difference is that we have far more expressive tools.
I do find the statement that '[w]e can't use eval; it's too dangerous' specious. It is an incidental property of js that it does not provide first-class mechanisms for encapsulating untrusted code; and it is uniformly true that within any language we can make an implementation of another language (or the same one) which does not have that problem. Or we can design our languages to have uniform object capabilities, or at the very least first-class global environments so that such tricks are not needed.
Further: I do think lisp syntax is good, but lisp is not about the parentheses and homoiconicity is overrated and somewhat meaningless. It is somewhat orthogonal to the interesting issues at play.
From what I understand as someone who has dabbled with lisp, the major appeal of lisp is the ease of extending the language with powerful macros (part of the reason why there were so many lisps, arguably why it fell in popularity). This means that you are encouraged to implement DSLs, which limit possible valid code