The magic of Lisps

[Erik Assum]

First of all, this might very well be a ramble without much sense, but please 
bear with me.
Secondly, I’m writing this first and foremost not as an application programmer.

Having programmed in the crud-application business some twenty years 
professionally, the last couple of them in Clojure, there are (at least) two 
things (that might be related) that puzzle me:

1) The power of macros
I see, and acknowledge that eg the go-macro core.async is a wonderful piece of 
work, and that it’s really cool that it could be done in a library. But as an 
application programmer, I really don’t care if it’s a macro or a language 
feature, and I couldn’t really see myself investing that amount of time (nor 
would I have the skills to do so if I had the time) to solve my concurrency 
problems in such a general manner.

2) The creating of a DSL for your problem domain, and then write a custom 
compiler to solve your problem
In my (most optimistic view) every program that I write is somewhat an internal 
DSL, built up of domain-specific functions, glued together with Clojure. But I 
don’t feel that this is very specific to how I program in Clojure vs other 
languages.

So what I’d really like to achieve with this post is two things

1) Arguments ranging from  “Oh, you should look at it from this angle” to 
“That’s how I feel too” to “You’re totally wrong, because…”

2) Pointers to blogs/articles/codebases which shows how applications written 
either with extensive use of macros or by implementing an internal DSL (and 
compiler) are significantly quicker to develop than their brute-force 
alternatives.

You might consider this as a first effort to create a presentation around the 
subject :)

Erik.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The magic of Lisps

[James Reeves]

Macros allow for experimentation in language design, not only by third
parties, but also by the developers of the language themselves. If you have
an idea for some new piece of syntax, it can be tried out in a library
first.

Macros are also useful for precompiling code for performance. If you have a
literal data structure you need to transform, or even one that's partially
literal, you can use macros to transform those parts at compile time.

That's not to say macros are written often; but they have an important
niche.

Regarding DSLs, I don't think applications are often written using an
encompassing internal DSL. I think most of the time when people talk about
a DSL, it's actually just an overly complex API.

In my view, a good DSL is both more consise within a domain, and less
powerful than a general purpose language. A regular expression, for
example, can concisely search through text, but has no side effects and is
guaranteed to halt at some point. Certain regex libraries even go further,
and guarantee they will halt within a time proportional to the input text.

Ideally we should be aiming for the *least* powerful tool for the job,
which often means using data to describe a solution rather than arbitrary
code. Not only is this more reliable, it's also more transparent and allows
for greater introspection.

For example, my own Integrant 
library replaces the dependency management of an application with a data
structure. This is less powerful, because the dependencies need to be
explicitly mapped out beforehand, but it's also more reliable and allows
for introspection.

Going further, Cognitect's Vase 
allows for micro-services to be expressed almost entirely through a data
structure.

Maybe these examples allow people to write applications faster, but I think
it's more important that they allow applications to be written more
reliably. Over time, applications that are reliable and predictable are
going to be easier for people to continue developing.

On Sun, 28 Apr 2019 at 05:46, Erik Assum  wrote:

> First of all, this might very well be a ramble without much sense, but
> please bear with me.
> Secondly, I’m writing this first and foremost not as an application
> programmer.
>
> Having programmed in the crud-application business some twenty years
> professionally, the last couple of them in Clojure, there are (at least)
> two things (that might be related) that puzzle me:
>
> 1) The power of macros
> I see, and acknowledge that eg the go-macro core.async is a wonderful
> piece of work, and that it’s really cool that it could be done in a
> library. But as an application programmer, I really don’t care if it’s a
> macro or a language feature, and I couldn’t really see myself investing
> that amount of time (nor would I have the skills to do so if I had the
> time) to solve my concurrency problems in such a general manner.
>
> 2) The creating of a DSL for your problem domain, and then write a custom
> compiler to solve your problem
> In my (most optimistic view) every program that I write is somewhat an
> internal DSL, built up of domain-specific functions, glued together with
> Clojure. But I don’t feel that this is very specific to how I program in
> Clojure vs other languages.
>
> So what I’d really like to achieve with this post is two things
>
> 1) Arguments ranging from  “Oh, you should look at it from this angle” to
> “That’s how I feel too” to “You’re totally wrong, because…”
>
> 2) Pointers to blogs/articles/codebases which shows how applications
> written either with extensive use of macros or by implementing an internal
> DSL (and compiler) are significantly quicker to develop than their
> brute-force alternatives.
>
> You might consider this as a first effort to create a presentation around
> the subject :)
>
> Erik.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
James Reeves
booleanknot.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit 

Re: The magic of Lisps

[rick]

I agree Erik, macros and the dsl idea are edge cases imho. Having written 
clojure for 4 years now (and with 30 as a professional developer) I’ve only 
written a few macros and they were for very specific use cases where I wanted 
to support something specific. 

I think they are over-hyped features which most people will never use. That 
said, it’s nice to have macros when you need them 

> On Apr 28, 2019, at 9:41 AM, James Reeves  wrote:
> 
> Macros allow for experimentation in language design, not only by third 
> parties, but also by the developers of the language themselves. If you have 
> an idea for some new piece of syntax, it can be tried out in a library first.
> 
> Macros are also useful for precompiling code for performance. If you have a 
> literal data structure you need to transform, or even one that's partially 
> literal, you can use macros to transform those parts at compile time.
> 
> That's not to say macros are written often; but they have an important niche.
> 
> Regarding DSLs, I don't think applications are often written using an 
> encompassing internal DSL. I think most of the time when people talk about a 
> DSL, it's actually just an overly complex API.
> 
> In my view, a good DSL is both more consise within a domain, and less 
> powerful than a general purpose language. A regular expression, for example, 
> can concisely search through text, but has no side effects and is guaranteed 
> to halt at some point. Certain regex libraries even go further, and guarantee 
> they will halt within a time proportional to the input text.
> 
> Ideally we should be aiming for the least powerful tool for the job, which 
> often means using data to describe a solution rather than arbitrary code. Not 
> only is this more reliable, it's also more transparent and allows for greater 
> introspection.
> 
> For example, my own Integrant library replaces the dependency management of 
> an application with a data structure. This is less powerful, because the 
> dependencies need to be explicitly mapped out beforehand, but it's also more 
> reliable and allows for introspection.
> 
> Going further, Cognitect's Vase allows for micro-services to be expressed 
> almost entirely through a data structure.
> 
> Maybe these examples allow people to write applications faster, but I think 
> it's more important that they allow applications to be written more reliably. 
> Over time, applications that are reliable and predictable are going to be 
> easier for people to continue developing.
> 
>> On Sun, 28 Apr 2019 at 05:46, Erik Assum  wrote:
>> First of all, this might very well be a ramble without much sense, but 
>> please bear with me.
>> Secondly, I’m writing this first and foremost not as an application 
>> programmer.
>> 
>> Having programmed in the crud-application business some twenty years 
>> professionally, the last couple of them in Clojure, there are (at least) two 
>> things (that might be related) that puzzle me:
>> 
>> 1) The power of macros
>> I see, and acknowledge that eg the go-macro core.async is a wonderful piece 
>> of work, and that it’s really cool that it could be done in a library. But 
>> as an application programmer, I really don’t care if it’s a macro or a 
>> language feature, and I couldn’t really see myself investing that amount of 
>> time (nor would I have the skills to do so if I had the time) to solve my 
>> concurrency problems in such a general manner.
>> 
>> 2) The creating of a DSL for your problem domain, and then write a custom 
>> compiler to solve your problem
>> In my (most optimistic view) every program that I write is somewhat an 
>> internal DSL, built up of domain-specific functions, glued together with 
>> Clojure. But I don’t feel that this is very specific to how I program in 
>> Clojure vs other languages.
>> 
>> So what I’d really like to achieve with this post is two things
>> 
>> 1) Arguments ranging from  “Oh, you should look at it from this angle” to 
>> “That’s how I feel too” to “You’re totally wrong, because…”
>> 
>> 2) Pointers to blogs/articles/codebases which shows how applications written 
>> either with extensive use of macros or by implementing an internal DSL (and 
>> compiler) are significantly quicker to develop than their brute-force 
>> alternatives.
>> 
>> You might consider this as a first effort to create a presentation around 
>> the subject :)
>> 
>> Erik.
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group an

Re: The magic of Lisps

[John Newman]

I like Eric Normand's take here:
https://lispcast.com/magical-leverage-languages/

On Sun, Apr 28, 2019 at 9:46 AM  wrote:

> I agree Erik, macros and the dsl idea are edge cases imho. Having written
> clojure for 4 years now (and with 30 as a professional developer) I’ve only
> written a few macros and they were for very specific use cases where I
> wanted to support something specific.
>
> I think they are over-hyped features which most people will never use.
> That said, it’s nice to have macros when you need them
>
> On Apr 28, 2019, at 9:41 AM, James Reeves  wrote:
>
> Macros allow for experimentation in language design, not only by third
> parties, but also by the developers of the language themselves. If you have
> an idea for some new piece of syntax, it can be tried out in a library
> first.
>
> Macros are also useful for precompiling code for performance. If you have
> a literal data structure you need to transform, or even one that's
> partially literal, you can use macros to transform those parts at compile
> time.
>
> That's not to say macros are written often; but they have an important
> niche.
>
> Regarding DSLs, I don't think applications are often written using an
> encompassing internal DSL. I think most of the time when people talk about
> a DSL, it's actually just an overly complex API.
>
> In my view, a good DSL is both more consise within a domain, and less
> powerful than a general purpose language. A regular expression, for
> example, can concisely search through text, but has no side effects and is
> guaranteed to halt at some point. Certain regex libraries even go further,
> and guarantee they will halt within a time proportional to the input text.
>
> Ideally we should be aiming for the *least* powerful tool for the job,
> which often means using data to describe a solution rather than arbitrary
> code. Not only is this more reliable, it's also more transparent and allows
> for greater introspection.
>
> For example, my own Integrant 
> library replaces the dependency management of an application with a data
> structure. This is less powerful, because the dependencies need to be
> explicitly mapped out beforehand, but it's also more reliable and allows
> for introspection.
>
> Going further, Cognitect's Vase 
> allows for micro-services to be expressed almost entirely through a data
> structure.
>
> Maybe these examples allow people to write applications faster, but I
> think it's more important that they allow applications to be written more
> reliably. Over time, applications that are reliable and predictable are
> going to be easier for people to continue developing.
>
> On Sun, 28 Apr 2019 at 05:46, Erik Assum  wrote:
>
>> First of all, this might very well be a ramble without much sense, but
>> please bear with me.
>> Secondly, I’m writing this first and foremost not as an application
>> programmer.
>>
>> Having programmed in the crud-application business some twenty years
>> professionally, the last couple of them in Clojure, there are (at least)
>> two things (that might be related) that puzzle me:
>>
>> 1) The power of macros
>> I see, and acknowledge that eg the go-macro core.async is a wonderful
>> piece of work, and that it’s really cool that it could be done in a
>> library. But as an application programmer, I really don’t care if it’s a
>> macro or a language feature, and I couldn’t really see myself investing
>> that amount of time (nor would I have the skills to do so if I had the
>> time) to solve my concurrency problems in such a general manner.
>>
>> 2) The creating of a DSL for your problem domain, and then write a custom
>> compiler to solve your problem
>> In my (most optimistic view) every program that I write is somewhat an
>> internal DSL, built up of domain-specific functions, glued together with
>> Clojure. But I don’t feel that this is very specific to how I program in
>> Clojure vs other languages.
>>
>> So what I’d really like to achieve with this post is two things
>>
>> 1) Arguments ranging from  “Oh, you should look at it from this angle” to
>> “That’s how I feel too” to “You’re totally wrong, because…”
>>
>> 2) Pointers to blogs/articles/codebases which shows how applications
>> written either with extensive use of macros or by implementing an internal
>> DSL (and compiler) are significantly quicker to develop than their
>> brute-force alternatives.
>>
>> You might consider this as a first effort to create a presentation around
>> the subject :)
>>
>> Erik.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.goo