Nah, Lisp is nowhere near the most minimal way to serialize code. It's plaintext, so it's denormalized. Something akin to bincode is the most minimal. But that requires a non-plaintext editor...
Why Lisp?
151–160 of 248 posts
Re: Why Lisp?
#152The 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…
Note that this is a double edged sword. Everyone is having is own little DSL world. A thing that Lispers often enjoy, but it's an art, a beautiful one, and a beautiful freedom too, and most people want a python with easy to access libraries more than that.
Lisp aims itself into niche problems where there's nothing good enough done yet. For the rest people won't care about the ability to fit the language to their need, they want 'productivity' and if a pattern become useful, backpressure will force language designer / BDFL to change it.
Re: Why Lisp?
#153Earlier quoted context omitted.
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…
Do you know if the attaching to a remote instance is available in Racket? I spent some time learning racket a year or two ago, but was under the impression they took out some of the really cool features (or I never discovered them)
Does it have to be remote?
If you can login on the same machine you can start the application with "racket whatever.rkt -i" to get a repl.
Re: Why Lisp?
#154Earlier quoted context omitted.
> 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…
Is there any loss less binding of XML to s expressions? I've never seen one. Usually example where I see people rewrite XML to s expressions (like in this thread) are very lossy -- its easy to be pretty by throwing away most of the information!
> Is there any loss less binding of XML to s expressions? I've never seen one.
You haven't looked hard enough. Mappging XML to sexprs is trivial:
content
-->
((tag value attr ...) content)
Re: Why Lisp?
#155I actually created a hybrid of JSON and Lisp called Geneva [1]. It was a fun weekend experiment. I totally relate to how the author feels
Re: Why Lisp?
#156Earlier quoted context omitted.
A higher order function doesn't serve the same purpose as a macro. A higher order function is meant to be applied, called, composed etc. A lisp macro is a different type of abstraction. For example, many people think that macros are just hiding lambda's of higher order functions. This is wrong. A macro abstracts over implementation details of a construct to make it read naturally. For example, you can write a functio…
Your point seems to be that macros allow for a slightly more natural syntax for certain things, but I can do pretty much the same thing in a language with a natural HOF syntax (Ruby): with_open_file filename do |f| do stuff with file end And for your second example: # our 'macro' function def defclass(name, parent, &blk) k = Class.new(parent) k.instance_eval(&blk) Kernel.const_set(name, k) end defclass :Tiger, Animal…
Sure, ruby has nice syntax for lambda, but the entire point is not even having to worry about what goes into blocks and what not. Syntax is a bad excuse for abstraction. Lisp has higher order functions too, but a deceptively short (or "natural") syntax can easily sweep ugly semantics under the rug. I know no one would ever write your defclass hof anyways because of the extreme runtime overhead that causes. If you wanted to reimplement your defclass macro more efficiently, I don't see how you would be able to do so while not breaking all of a users code relying on that function. The point of a macro is so the implementation detail is hidden, and the interface doesn't have to change when you change the implementation. Lisp has higher order functions too. Hell, that's where ruby got it from. Higher functions have their uses, but they are not for abstracting patterns in code like macros are. They are for abstracting procedures in code on arguments received at runtime. The difference is macro expansion happens lexically, at compile time, while functions are part of the program at runtime.
If you haven't seen a practical example of what it's useful for, that's akin to the attitude of a C programmer not understanding the usefulness of higher order functions. They say, I get 95 percent of the way their with good old functions and function pointers. We would find that absurd, just as how I find the claim that a 'simple practical example of where added power of a macro is useful does not exist' is absurd
For example, see 'A unit testing framework' in 'practical common lisp' available online by Peter seibel. I can't possibly imagine how you'd be able to create a unit testing framework abstraction in Ruby as nice or efficient as the one presented with higher order functions in 26 lines of code. But it'd be cool if anyone could prove otherwise.
Re: Why Lisp?
#157Earlier quoted context omitted.
A higher order function doesn't serve the same purpose as a macro. A higher order function is meant to be applied, called, composed etc. A lisp macro is a different type of abstraction. For example, many people think that macros are just hiding lambda's of higher order functions. This is wrong. A macro abstracts over implementation details of a construct to make it read naturally. For example, you can write a functio…
In what language are you writing?
Semantically, I'm writing in common lisp. If you mean the syntax, that's an ad hoc thing that comes up when writing in an HTML text box and emacs isnt here. But the syntax is shallow and unimportant compared to the abstraction presented. (it's just normal lisp syntax with implied parentheses anyways, so it's a bit ambiguous)
Re: Why Lisp?
#158Earlier 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…
#define DEBUG(fmt, ...) if (DEBUG) { printf(fmt, ...);} ? (change syntax to actually work)
That does something similar, sure, but what it in fact is is a macro. As snikeris was saying, you couldn't write anything quite like that #define in a macroless language like Java.
Re: Why Lisp?
#159I actually created a hybrid of JSON and Lisp called Geneva [1]. It was a fun weekend experiment. I totally relate to how the author feels [1] https://github.com/smizell/geneva
Early versions of wat-js used ["the", "same", "syntax"]. You might find it interesting. https://github.com/manuel/wat-js
Re: Why Lisp?
#160Earlier quoted context omitted.
Because macros let you control code in a way libraries don't^1. Java now has this way to iterate over a collection of things: for(String exclamation: exclamations) { System.out.println("I yell " + exclamation + " at you"); } But this was only added in 2004!^2 So for almost 10 years, you had to manually iterate over stuff. How would you implement this as a library? Well, you could write a function that lets you write:…
Agreed about your Java example. However, for the purpose of this discussion, let's assume we're talking about modern, well-designed languages without ugly kludges and with access to nice features such as lazy evaluation and real closures. > Macros can be viewed as libraries that act on the language itself. There isn't a difference between language-level features and "library functions" in a language with macros. I si…
Many have said that the real benefit is that you wind up turning Lisp into the language that is perfect for your domain.
When you start your project, you don't know enough to design the perfect language for your domain. You start coding in Lisp, and you begin to uncover patterns that express your domain. Eventually, you find your way towards building a small set of macros that beautifully, expressively capture your domain.
Look for where Paul Graham talks about "bottom-up" programming versus "top-down" programming, and you'll find what he has to say about this. He says you do both in Lisp. Bottom-up is "changing the language to suit your problem."