Earlier quoted context omitted.
The majority of macros I write could be represented with HOF and lexically-closed lambdas. That adds significant extra syntax when you use them though. Consider a classic pattern of a with macro: (with-mutex-held-macro (some-mutex) (do-stuff)) (call-with-mutex-held-hof some-mutex (lambda () (do-stuff)) A minor advantage is that a macro will be expanded in-line; a Sufficiently Smart Compiler could transform the HOF ve…
One thing to note is that you're using the macro or lambda to delay evaluation. In a lazy-by-default language, that's unnecessary (which is a part of why macros are less useful in Haskell).
Why Lisp?
181–190 of 248 posts
Re: Why Lisp?
#182Earlier quoted context omitted.
Could someone please explain the difference between Lisp macros and, say, languages that have first-class functions? I get that a Lisp macro will be expanded into the respective code, while a function's execution is different. However, at the practical (i.e., developer's) level, are there any additional benefits? Can, say, a Lisp macro be 'partially formed', in the sense that it can expand into some boilerplate that…
My favorite example for this is the lame idiom you see in Java code: if (log.isDebugEnabled()) { log.debug("expensive" + debug + message); } This is "better" than just log.debug(...) because with the latter, your expensive log message argument needs to be evaluated even if debug is disabled. However, in a language w/ macros, you just say: (debug (str "expensive" debug message)) and these considerations are already ta…
log.debug(debugIsEnabled and "yo expensive" or "yikes!")Re: Why Lisp?
#183The article doesn't discuss macros, which is one of the answers to "Why Lisp?" I didn't "get" macros until I read a footnote in the (freely available) book Practical Common Lisp . In chapter 7, it introduces the `dolist` macro. DOLIST loops across the items of a list, executing the loop body with a variable holding the successive items of the list. This is the basic skeleton (leaving out some of the more esoteric opt…
Aren't macros breaking the homocionicity of the lisps? And making maintenance more difficult (aren't you re-inventing a new language with macros?)? Where does the "First rule of the macro club" coming from? When should you break it?
If used right, macros make things much more maintainable. If you have a hundred nearly-identical codeblocks, where only (say) a string constant is varying, and suddenly you need to change what those blocks do, bam, you've got a hundred blocks to change. If those blocks had been refactored with a macro, all you have to do is change the macro once. It also prevents the new guy from coming and doing a bandaid fix to line #72 making it slightly different from the 99 lines around it and making your life a living hell.
Re: Why Lisp?
#184Earlier quoted context omitted.
My favorite example for this is the lame idiom you see in Java code: if (log.isDebugEnabled()) { log.debug("expensive" + debug + message); } This is "better" than just log.debug(...) because with the latter, your expensive log message argument needs to be evaluated even if debug is disabled. However, in a language w/ macros, you just say: (debug (str "expensive" debug message)) and these considerations are already ta…
Your lame idiom example in java is why I love Lua so much: log.debug(debugIsEnabled and "yo expensive" or "yikes!")
Re: Why Lisp?
#185> The reason that code represented as XML or JSON looks horrible is not because representing code as data is a bad idea, but because XML and JSON are badly designed serialization formats. By that same token, a Volkswagen Beetle is a badly-designed boat. XML was never designed as a data serialization format. It's a markup language . It was designed to sprinkle structure and metadata into large human-readable plaintext…
> XML was never designed as a data serialization format. It's a markup language. Those two things are not mutually exclusive. > Likewise, JSON is a subset of a general-purpose programming language's literal notation that happened to be very fast to parse in a browser by virtue of the browser implementing that language. That's true. That is not in conflict with anything I said. > The problem is that there's no one-siz…
http://eli.thegreenplace.net/2012/03/04/some-thoughts-on-jso...
Re: Why Lisp?
#186Earlier quoted context omitted.
The best you'll get are examples of something solvable in Python being "beautiful" in Lisp. Then some real world Lisp examples will be references to a 20 year old storefront generator and the initial release of reddit. Lisp(s) are certainly better than Python in every way, except when it comes to successful projects completed.
I think you need a bigger reference frame of Lisp's usage over its 50 year history that extends even to 2015. But even then, quoting Kent Pitman: "Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Lang…
Re: Why Lisp?
#187The interactive model is insanely cool. When building a toy game engine a while back ( https://github.com/orthecreedence/ghostie ) I saved probably half the development time by being able to redefine functions/values while the game was running . The old way of lisping is to prototype in lisp, then build in a "real" language (c/java). However nowadays the lisp implementations (CCL/SBCL specifically) are fast/advanced…
Even better you can attach the repl to a remote instance. I had a problem a little while ago that could only be reproduced on the server. I could connect to the repl over ssh and evaluate and modify code directly. Compare that to a similar problem I had with a C# app we had. For that I had to stick in a load of logging code, check it in then wait half an hour for the CI server to deploy before running and checking th…
Re: Why Lisp?
#188Earlier quoted context omitted.
Could someone please explain the difference between Lisp macros and, say, languages that have first-class functions? I get that a Lisp macro will be expanded into the respective code, while a function's execution is different. However, at the practical (i.e., developer's) level, are there any additional benefits? Can, say, a Lisp macro be 'partially formed', in the sense that it can expand into some boilerplate that…
Macros can provide a lot of syntactic convenience over those first-class functions, especially with heavily nested structures. For example, I can replace this monadic parser definition... function SpecDeclP()Parser{ return Bind(SeqRight(MyKeywordP, IdentifierP), function(nm interface{})Parser{ return Bind(BetweenParensP(IdentifierP), function(parm interface{})Parser{ return Bind(SetSwitchUserStateP, function(_ interf…
Re: Why Lisp?
#189The article doesn't discuss macros, which is one of the answers to "Why Lisp?" I didn't "get" macros until I read a footnote in the (freely available) book Practical Common Lisp . In chapter 7, it introduces the `dolist` macro. DOLIST loops across the items of a list, executing the loop body with a variable holding the successive items of the list. This is the basic skeleton (leaving out some of the more esoteric opt…
It's kind of cool how in lisp you're supposed to do macros to change major aspects of how the language behaves, but in C if you try having a little bit of fun with #define and the pre-processor everybody starts getting just extremely rude at you.
Re: Why Lisp?
#190I worked at a large e-commerce retailer for a few years, one that you might have heard of or even purchased something from. I had the experience of building a few systems in Lisp and also in a few mainstream imperative languages. It was tough and really lonely even though I had real success.
With Lisp I could do things that whole teams could only dream of in Blub and in much shorter periods of time.
The problems weren't really technical but more psychological and social when it came to Lisp. Big problems. I wasn't very successful in resolving many of them.
I still use Lisp here and there but have been drawn to the ML family in the past few years. Strong static type systems got a hold of me for better or worse.
All languages suck, it's just the degree that differs.