Just imagine how excited and evangelical this guy will be when he discovers static typing and lazy evaluation, too.
The Nature of Lisp
61–70 of 82 posts
Re: The Nature of Lisp
#62I passionately hate XML so this could not possibly resonate with me. I never had the enlightenment he talks about. Actually I think that learning Lisp/Scheme might have made me a bit of a worse programmer in a way. It made me "dread" repetitive code so much to the point that I almost could not do anything with any language that's not highly dynamic. Anyways. I had 2 epiphanies with lisp. 1. Macros. Very powerful conc…
Interestingly, Oleg Kiselyov recently argued for not including full, undelimited continuations in new languages - http://lambda-the-ultimate.org/node/4586
Re: The Nature of Lisp
#63Reading the related article on writing a Lisp interpreter in Haskell ( http://news.ycombinator.com/item?id=4764088 ) reminded me of my second blinding moment of enlightenment- understanding vau expressions. Things that can't be implemented as functions are typically things that require controlling the evaluation of arguments (conditionals, assignment, short-circuiting boolean operators, etc.), and additional language…
A language that is lazy by default lets you control the evaluation of arguments. Ordinarily, they're not evaluated, and if you force them they are.
However, macros are not just about whether to evaluate -- but about exposing the internal syntactic structure of the arguments.
In Haskell, using laziness you can implement control flow, short-circuiting, etc. If you want functions that work with the syntactic structure of their arguments, you need heavier machinery:
* Thick DSLs: Define explicit AST types and have a DSL that explicitly constructs those AST's.
* Template Haskell (the arguments' syntax has to be in ordinary Haskell)
* Quasiquotes (Need to parse strings)
I think the need for exposed syntax is relatively rare (e.g: a function that evaluates and shows a trace of the evaluation). In those cases, I think explicit AST types work pretty well, as Haskell has extremely light-weight syntax for constructing user-defined data types.
Re: The Nature of Lisp
#64Earlier quoted context omitted.
> why don't languages provide the ability to do this kind of thing automagically, I mean marking some code to be executed at compile time and act as a code generation feature? There's certainly already languages that do this type of thing. Haskell has Template Haskell which lets you execute Haskell code at compile time to generate code. I'm pretty sure multiple ML's also have similar meta-programming features. It wor…
Scala 2.10 will have it too. There is a distinction to be made. In non-homoiconic languages writing macros takes a lot of effort, while in Lisp it's very natural. On the other hand I don't feel that's an advantage for Lisp, because macros are not composable as functions are and you have to really grok Lisp in order to write macros effectively and also recognize instances where they are appropriate.
I don't think writing Template Haskell macros takes a lot of effort. It is probably harder than Lisp macros, but the main effort is studying the TH API once.
Re: The Nature of Lisp
#65Earlier quoted context omitted.
Yes, for me the first time I read about the lisp syntax I was thinking: "oh cool, it makes (+ 2 2) exactly equivalent to the syntaxic tree + / \ 2 2 " But I don't find it particularly enlightening and I still don't see what cool stuff you can do with macros that you can't do elsewhere.
Syntactic abstraction usually requires a language change. For example, Python's "with" statement. In languages with macros, you don't need to wait for anyone to change the language because the entirety of the language is constructed from a few special operators, and you have the ability to continue constructing. Like Python, Clojure has a "with-open" macro. If Rich hadn't already added it, you could build it yourself…
In Haskell, there's the "bracket" function with generalizes the "with" concept.
withFile fileName mode = bracket (openFile fileName mode) hClose
withFile "/usr/share/dict/words" ReadMode $ \h -> do
contents Interestingly, the type of withFile, after its given the filename and filemode args is:
(Handle -> IO a) -> IO a
data Cont r a = Cont ((a -> r) -> r)
Cont (IO a) Handle
Re: The Nature of Lisp
#66Earlier quoted context omitted.
So, homoiconicity is a trifling, meaningless similarity? "Sure, it may be homoiconic, use prefix notation, have first-class functions (in additional to all the other usual functional paradigms that aren't unique to lisps) but it's not a lisp." Big ok to that one. This must be pedantry of the highest caliber, not ignorance.
They are not homoiconic. The underlying datastructure for many schemes, and racket, is not a list. It is a syntax object. Of course you can still do metaprogramming with syntax objects but I wouldn't call it the same thing.
Homoiconicity doesn't refer to lists, but to syntax being represented in the data structures of the language.
Re: The Nature of Lisp
#67Total ignoramus here:Does this "profound enlightenment" actually lead to profound execution?
Re: The Nature of Lisp
#68Also, this is a very interesting article on why lisp is unsuccessful in the "read world": http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
I like the original article a lot, but what it failed to do for me is convince me why someone like me, a typical programmer, would want to choose Lisp over Python/Ruby/etc to solve a real world problem. Both Ruby and Python have powerful meta-programming abilities built into them. Lisp should be compared with these, not with C.
I still think that functional programming is extremely interesting (I'm in the long process of learning Haskell myself) and is useful is certain real world cases, but I was not convinced by this article. All the problems there are easily solved in modern and dynamic languages.
Re: The Nature of Lisp
#69Part of the problem is that lisp evangelism sets itself up to fail. An instantaneous blinding moment of enlightenment, would you like fries with that? Haven't they heard that you shouldn't start a joke with "This is the most hilarious thing ever"? I've been doing lisp for several years now. I've built several interpreters. I've never had the enlightenment he describes. The minor epiphanies have been on par with oo de…
Nice to hear I'm not the only one. I've been using Lisp (mainly Common Lisp) for quite a few years now but never had that flash of enlightenment either. Discovering Lisp always seemed more like coming home: "Ah, this is how I always thought what programming was supposed to be like!"
No fighting with the compiler or being limited by what the PL designer thought you should do, just a pretty direct path from thought to code.
Re: The Nature of Lisp
#70Total ignoramus here:Does this "profound enlightenment" actually lead to profound execution?
As I've written in another comment I have never experienced the profound enlightenment but what do you mean with "profound execution"?
I can tell you that Common Lisp gets me the quickest results going from idea to prototype, it is a very practical language and doesn't get in the way. However a large part of this is experience. It was the most fun language to learn and apply to projects for me though.