6 ms·
I never understood why people consider lisps superior, mind explaining exactly what changed your mind?
by kgabis 11y ago
I never understood why people consider lisps superior, mind explaining exactly what changed your mind?
- squeaky-clean 11y agoNot a lisp user myself, so I can't speak firsthand, but Paul Graham has several essays about it. http://www.paulgraham.com/lisp.html http://www.paulgraham.com/lisp.html
- k__ 11y agoCan languages with other syntax have the same properties?
- sklogic 11y agoAny language with a compile-time metaprogramming would do.
- TeMPOraL 11y agoTcl I heard has string-based homoiconicity. Otherwise, I'm yet to see a proof you can get an actual, usable and not incredibly annoying macro system working without turning your language into a Lisp. People keep trying, but it's always some inelegant subset bolted onto the core syntax.
- sklogic 11y agoTake a look at Converge, Nemerle, TH and many other similar languages - they're doing just fine without any homoiconicity. All you need is a decent quasiquotation.
- TeMPOraL 11y agoThanks for the pointers, I never heard of those languages before. I am actually looking at the Converge documentation on macros now, and I found the perfect quote to highlight the problem I see with those approaches: Quasi-quotes allow ITree's to be built using Converge's normal concrete syntax. Essentially a quasi-quoted expression evaluates to the ITree which represents the expression inside it. For example, whilst the raw Converge expression 4 + 2 prints 6 when evaluated, [| 4 + 2 |] evaluates to an ITree which prints out as 4 + 2. Thus the quasi-quote mechanism constructs an ITree directly from the users' input - the exact nature of the ITree is of immaterial to the casual ITree user, who need not know that the resulting ITree is structured along the lines of add(int(4), int(2)). That is, quasi-quotes take some code and turn it into a tree object. This tree object can then somehow get compiled into actual code later. Compare that with Lisp approach, in which code is data. You don't think about the code as something separate from the tree that represents it. The code is the tree. There is no ITree object. It may seem like just "semantics", but I find this to be a significant cognitive difference.
- sklogic 11y ago> Compare that with Lisp approach, in which code is data. It's not any different. It does not matter if your `(,a ,b) is compiled into (list a b), or your ` \a\ = \b\` is compiled into make_binary('=',a,b) - both are constructors, essentially. Take a look at what I'm doing with just a quasiquotation here: https://github.com/combinatorylogic/clike https://github.com/combinatorylogic/clike
- pjmlp 11y agoDylan? Then again it is a Lisp with Algol syntax.
- stray 11y agoI believe Dylan used to be a Lisp with Lisp syntax.
- pjmlp 11y agohttp://opendylan.org/documentation/intro-dylan/index.html http://opendylan.org/documentation/intro-dylan/index.html
- stray 11y agoThanks for the link. The page on that site that gives the history including the original lispy syntax is here: http://opendylan.org/history/index.html http://opendylan.org/history/index.html
- BruceM 11y agoWe talk sometimes about having an additional reader to support another syntax ... but so far, it isn't something where someone's actually volunteered to step up and help. It'd be interesting to play with some ideas from David Moon's PLOT as well ...
- leephillips 11y agoJulia is homoiconic and, of course, has lisp-style macros. It has a syntax similar to something like array fortran. http://julialang.org/ http://julialang.org/
- kkylin 11y agoI love using Julia, but for me writing Julia macros came with a steeper learning curve than in Lisp / Scheme, due in part to the syntax. I kept wishing Julia was a layer on top of a Lisp, and that I can just write Lisp macros. (I know the parser is currently in Scheme, but you can't exploit that easily.)
- grayclhn 11y agoThe obvious solution is to write a julia macro that implements lisp macros as a DSL ;)
- KenoFischer 11y agoNo need, Julia comes with a builtin lisp.
- ihnorton 11y agoI tend to end up writing `Expr` objects directly when I'm building larger macros as I find them much easier to reason about. It's clearly not as convenient/clean as Lisp though. (David Moon actually sent a PR last year to make hygiene much easier.. unfortunately it got stuck for a while, but the PR was recently rebased and hopefully will be merged eventually). Regarding the learning curve: we rewrote the first half of the Metaprogramming section of the manual a few months ago to try to provide a more gradual introduction, especially for people without a Lisp background. Objectively I don't know if the change has helped, but I tell myself that the number of macro-related questions has gone down :) We would really like to make these tools accessible to people both with and without a formal CS background (probably the majority of Julia users will fall in the latter category). So, if you have any suggestions for doc/pedagogy improvements in this area, I would be very happy to hear them!
- PuercoPop 11y agoYes, take a look at Dylan. But they almost never do.
- maaku 11y agoDylan's approach works because it has lisp at its core.
- chadzawistowski 11y agoOther languages can technically have homoiconicity, but there's something to be said for the simplicity of Lisp forms.
- cwp 11y agoYes. See Smalltalk for a language with object-oriented homoiconicity.
- stray 11y agoThat's not really homoiconicity though, is it? Smalltalk source code does not appear to be expressed in terms of a Smalltalk data structure. Whereas Lisp source code is expressed as lists of lists.
- cwp 11y agoSure it is. All parts of a Smalltalk program are present as objects that can be manipulated by sending them messages. Classes, methods, variable bindings, closures, stack frames, even individual messages are objects. As a practical matter, methods also have a textual representation, but that's not strictly necessary. Ten or fifteen years ago, the Squeak method browser had a mode where you could write Smalltalk code using tiles, kind of like in Etoys, no parsing necessary. That was a hassle to use, though, so people stuck with writing methods using text. By the way, Lisp has the same sort of "impurity". S-expressions are very simple, but they are syntax. It's surely possible to create a tool that would let one construct cons cells in memory directly, but that would be a hassle. Instead we use parentheses.
- stray 11y agoThe 'iconicity' part of homoiconicity refers to the textual representation.
- deleted 11y ago[deleted]
- rakoo 11y agoMaybe not the same, but I feel like nim (http://nim-lang.org/docs/manual.html#templates http://nim-lang.org/docs/manual.html#templates) can have a comparable power ot redefining itself. But I'm absolutely not an expert neither in any lisp nor in nim so I can't really tell.
- ArtB 11y agoThe property of homoiconicity is shared by all Lisps, Forths, and Prolog amongst others: https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Homoiconicity
- moron4hire 11y agoIt's not that there is anything particularly special about what you can do in Lisp than what you can do in, say, C#. It's that Lisp provides facilities for metaprogramming that most other languages lack. Most other languages make metaprogramming hard enough, or require it all be done at runtime, that it is very discouraging against the concept in general. Lisp creates a culture around metaprogramming that fundamentally changes how you approach programming forever after. You stop writing programs. You start writing programs that write programs. It's a lever that multiplies the power of the programmer. That can be both good and bad. For a hacker coding in earnest on her own, it can be extremely good. Yes, if you are the type of beginner or intermediate programmer that still struggles to just write programs, advanced metaprogramming in any language is not for you. If you're an intermediate programmer looking to become an expert programmer, learn Lisp, where metaprogramming is easy, and take the lessons on to whatever other languages you eventually end up using. That's what people mean.
- stray 11y agoI've never had to change my mind about Lisp -- but to me, Common Lisp's condition system kicks the crap out of every other language because it allows you to handle conditions without unwinding the stack. And whenever you get dropped into the debugger, you can edit and reevaluate the broken code or values or whatever -- and then continue on with the task. In other words, you can begin a task with imperfect code -- and refine it as you go along -- figuring out how to handle corner cases as you go. All without starting the task over from the beginning. I know of only one other language that allows you to explore a problem space like that. Besides, the parentheses make the code less jagged looking and jagged looking code imo, is more tiring to look at. Lisp is simply prettier.
- muraiki 11y agoSmalltalk also drops you into a debugger on an error, letting you inspect the state of the system, correct your code, and resume. Check out Pharo Smalltalk.
- stray 11y agoTIL. I have edited my comment to account for smalltalk.
- TeMPOraL 11y agoSmalltalk probably supports this as well, but what's cool about Common Lisp's condition system is that it doesn't depend on user interaction or debugger to work. Conditions let you separate the code making the decision about how to handle an error from actual error handling. The decision doesn't have to involve interactive debugger, you can have your code making the choice about which restart (unit of error handling code) to invoke. The common use case is that you install various restarts as you go down the call stack; then, when an exception happens, control goes up the stack until appropriate decision code, which selects restart, and control goes back down the call stack to the selected restart block. It's an incredibly flexible system that makes exception handling much more useful.