Live data from Hacker News

Why Lisp?

blog.rongarret.info

181–190 of 248 posts

Re: Why Lisp?

#181

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).

There's a class of things that don't require macros in Haskell, but I don't think that means macros are less useful in Haskell. There are plenty of things you might want them for, like generating new definitions.

Re: Why Lisp?

#182

Earlier 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…

Your lame idiom example in java is why I love Lua so much:

    log.debug(debugIsEnabled and "yo expensive" or "yikes!")

Re: Why Lisp?

#183

The 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?

>maintenance

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?

#184

Earlier 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!")

Calling log.debug() with and argument of `false` is a no-op? That sounds like someone bending the language to fit an idiom, because it doesn't sound like a sane API except that it enables this use case.

Re: Why Lisp?

#185
post #111

> 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…

One downside to S-exprs compared to, say, JSON: they do not have direct support for unordered mappings (hash tables, dictionaries, whatever you want to call them). You can represent them as trees, but basically every language these days (including, of course, Lisps) has a mapping type as a core concept; requiring the user to figure out what parts of the input data should be converted to that type is annoying, and makes the format less self-documenting (i.e. it may not be immediately apparent whether there can be duplicate keys or not).

http://eli.thegreenplace.net/2012/03/04/some-thoughts-on-jso...

Re: Why Lisp?

#186
post #57
post #45

Earlier 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…

Part of the visibility issue is that there are very few big-name open source Common Lisp success stories which aren't CL implementations, or CL ecosystem tools. Most of the things in that list are big-ticket enterprisey applications.

Re: Why Lisp?

#187
post #61

The 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…

You can get this in other languages too. For example, Flask (a Python web framework) has a fantastic debug-mode error page that totally changed the way that I think about web development. Any time an exception is thrown in a view function (and this includes the exceptions that you idiomatically throw for HTTP 4xx and 5xx errors) the debug-mode error page would have a stack trace (obviously), but also an interactive REPL that could be opened at any stack frame in that trace. It wasn't necessary all that often, but when it was, boy was it a fantastic way to work.

Re: Why Lisp?

#188
post #163

Earlier 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…

I'm fairly sure that Haskell had do notation before Parsec.

Re: Why Lisp?

#189

The 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.

Could the reason perhaps be that Lisp macro facilities tend to be much more sane than C's pre-processor? Just a wiiild guess.

Re: Why Lisp?

#190
I haven't been here in a while now but when Ron shows up in the mainstream that's reason enough. Why Lisp ? Definitely the reasons he points out.

I 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.

Post reply on HN