Home

15 comments

cousin_itover 10 years ago
I admit that I don't completely understand Lisp's claim to fame. Yes, programs in the language are represented by a built-in data type, and you can write a self-interpreter quite easily. But the same is true for a simple assembly language, if you know the instruction encoding! You can represent a program as a code pointer, and it's easy to write an analog of "eval" by hand, using just a handful of arithmetic instructions and conditional jumps. What's more, such an "eval" won't even depend on a garbage collector or other niceties that Lisp self-interpreters take for granted.
评论 #9038849 未加载
评论 #9038831 未加载
评论 #9040213 未加载
评论 #9039018 未加载
评论 #9039527 未加载
评论 #9039406 未加载
评论 #9039153 未加载
评论 #9042532 未加载
评论 #9040451 未加载
评论 #9038844 未加载
jgrodziskiover 10 years ago
Hi, Submitter here,<p>I stumble upon that article from my bookmarks while pouring my latest side project (<a href="http://www.learn-computing-directory.org/languages-and-programming/compilers-fundamentals.html" rel="nofollow">http:&#x2F;&#x2F;www.learn-computing-directory.org&#x2F;languages-and-progr...</a>) and thought about submitting it to HN. By the way, feel free to give me feedbacks about the directory! (in still in very alpha state but already online). I only fill for the moment the &quot;Algorithms and Data Structures&quot;, &quot;Compilers&quot; and &quot;Theory of computation&quot; topics.<p>Two great articles that complements perfectly the one submitted are LISP interpreters in Python from Norvig: <a href="http://norvig.com/lispy.html" rel="nofollow">http:&#x2F;&#x2F;norvig.com&#x2F;lispy.html</a> and <a href="http://norvig.com/lispy2.html" rel="nofollow">http:&#x2F;&#x2F;norvig.com&#x2F;lispy2.html</a> Also, the book &quot;Understanding Computation&quot; (<a href="http://computationbook.com/" rel="nofollow">http:&#x2F;&#x2F;computationbook.com&#x2F;</a>) can be a great companion as there is a section about Lambda Calculus.<p>Jérémie.
nabla9over 10 years ago
While this is nice academic view. As a Lisp programmer, the Power of Lisp comes from being big ball of mud, see: <a href="https://en.wikipedia.org/wiki/Big_ball_of_mud#In_programming_languages" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Big_ball_of_mud#In_programming...</a>.<p>Usable and efficient Common Lisp implementation can be build from just ~25 primitives (more than core LISP but still very elegant). Elegant derivation of Lisp world does not matter when the atoms and the molecules can&#x27;t be distinguished. Is the object system and meta-object protocol implemented as primitives by people who designed the Lisp implementation, or is it external library? Who cares. Only performance and correct function matter.
samatmanover 10 years ago
I understand why Alan Kay said what he did, but a closer analogy would be to Euclid&#x27;s Elements. If one follow&#x27;s Lisps axioms, one ends up with Lispian Computation, elegant, clean, tail-call optimized.<p>Other axioms of computing lead the user in different directions, notably Hindley-Milner. Lisp carves territory in mathematical state space, not physical reality.
评论 #9039438 未加载
adamgravitisover 10 years ago
I just noticed this was authored by Michael Nielsen... co-author of <i>the</i> text on quantum computation, and now a huge open-academia advocate. And he&#x27;s open-sourced the micro-lisp he wrote in this article: <a href="https://github.com/mnielsen" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mnielsen</a>
mvcover 10 years ago
If you&#x27;re near Boston&#x2F;Cambridge, the Clojure Meetup Group is showing a live video of William Byrd talking about this tonight.<p><a href="http://www.meetup.com/Boston-Clojure-Group/events/218650142/" rel="nofollow">http:&#x2F;&#x2F;www.meetup.com&#x2F;Boston-Clojure-Group&#x2F;events&#x2F;218650142&#x2F;</a>
quarterwaveover 10 years ago
Any chance of a resurgence in Lisp machines? Especially in view of the changes in CPU architecture due to semiconductor scaling challenges.
评论 #9043493 未加载
评论 #9039399 未加载
评论 #9039016 未加载
评论 #9043096 未加载
评论 #9039073 未加载
unotiover 10 years ago
There&#x27;s nothing inherently unnatural about taking a bottom up approach to solving problems. Sometimes, knowing you&#x27;re going to need a particular tool and doing that first makes sense. I think of it like the cooking technique Mise en place [1], where you lay out all the ingredients before you start cooking. Neither bottom up, nor top down, is always the most natural way to attack a problem. Sometimes you can attack a problem from both sides at once.<p><a href="http://en.m.wikipedia.org/wiki/Mise_en_place" rel="nofollow">http:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Mise_en_place</a>
gobengoover 10 years ago
What does Lisp provide on top of e.g. the lambda calculus? I&#x27;d expect the latter to be even more fundamental. But I suppose one could reasonably argue that that wasn&#x27;t &#x27;Software&#x27;, just Math.
评论 #9039704 未加载
jherikoover 10 years ago
surely this is actually that a short lisp compiler or interpreter is the maxwell&#x27;s equations. the analogy is way off the mark for software as a discipline in total. you can know nothing about lisp and understand pretty much everything... thats not true of classical electromagnetism and maxwell&#x27;s equations
评论 #9040504 未加载
keithgabryelskiover 10 years ago
for what it is worth, here is a version of a lisp interpreter I wrote in python: <a href="https://github.com/keithgabryelski/plisp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;keithgabryelski&#x2F;plisp</a> I used _Interpreting_LISP_ by Gary D. Knott as a guide.
评论 #9041337 未加载
kazinatorover 10 years ago
That half a page of code isn&#x27;t &quot;Lisp in itself&quot;.<p>I do not see any low-level I&#x2F;O routines, or a reader to scan expressions and convert them into objects.<p>I don&#x27;t see the actual function call mechanism: where the subroutine linkage is set up and torn down, and what goes into what register.<p>I don&#x27;t see a garbage collector.<p>A whole bunch of hand-written assembly language made the code on that page work.
charlieflowersover 10 years ago
Shouldn&#x27;t [2012] be appended to the title? I&#x27;ve seen the article discussed on HN before. [1]<p>[1] <a href="https://news.ycombinator.com/item?id=3830867" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=3830867</a>
评论 #9038683 未加载
评论 #9038720 未加载
GFK_of_xmaspastover 10 years ago
Disagree with premise, Maxwell&#x27;s equations are useful in practice.
phkahlerover 10 years ago
I hate that. The half page of code is not Lisp. Not even close, and I&#x27;m not talking about a standard library. There is no parser in there. Eval is operating on Lisp data, not lisp source code. There is no support for efficient math, or strings, or anything really.<p>If that is lisp, then a byte code interpreter loop is every interpreted language: read_opcode, inc_pc, call a function indexed from a list indexed by opcode. It can be written in one line of C. This BTW translates to hardware a lot easier than the half page of Lisp. That one line of code by itself is also just as useless as the half page of Lisp.<p>It&#x27;s still interesting, but people need to stop claiming it&#x27;s Lisp defined in this tiny little block of code.
评论 #9039260 未加载