Re: crazy idea...

[Jules]

Lee,

Thanks for the link - I can see that I have a lot of reading ahead of me 
:-) - looks very interesting indeed.

Jules

On Saturday, 28 November 2015 20:26:48 UTC, Lee wrote:
>
>
> Jules, 
>
> There's work using random variation and selection to do some of the more 
> ambitious things you've suggested. 
>
> See, for example, http://geneticimprovement2015.com 
>
> It'd be great to see work in this area being done in Clojure, perhaps in 
> conjunction with some of the more deterministic methods you've suggested 
> here. 
>
>  -Lee 
>
>
>
> > On Nov 28, 2015, at 1:53 PM, Lucas Bradstreet  > wrote: 
> > 
> > Kibit (https://github.com/jonase/kibit) does many of the things that 
> > you describe, though it doesn't go as far you dream. It also uses 
> > core.logic to suggest equivalent substitutions. 
> > 
> > I'd be happy to see more work in this area. 
> > 
> > Lucas 
> > 
> > On 29 November 2015 at 02:01, Jules  
> wrote: 
> >> Guys, 
> >> 
> >> I've had pieces of this idea wandering around my head for years now and 
> have 
> >> finally decided that the time might be right for putting them together 
> in 
> >> the context of Clojure. I'm sure that others have had similar ideas 
> before : 
> >> 
> >> Imagine my Clojure program which reads in your Clojure program and 
> spits out 
> >> a smaller, simpler, faster Clojure program which does exactly what 
> yours 
> >> did... 
> >> 
> >> Of course, you are such a good programmer that your program could not 
> be 
> >> improved ? In which case we need you writing my Clojure program :-) 
> >> 
> >> This is opening the door onto a very large but very interesting problem 
> >> space. 
> >> 
> >> Starting the project off in a language that is homoiconic should 
> deliver 
> >> enormous benefits straight away as the language itself provides a 
> reader, an 
> >> Abstract Syntax Tree (itself) , a macro language (itself) etc... 
> >> 
> >> I have some initial ideas - 
> >> 
> >> - I was thinking of looking at core.logic to see if I might be able to 
> use 
> >> it to match code to which refactorings might be applied. 
> >> 
> >> - I was wondering whether analysing a class/methods transitive bytecode 
> >> might be enough to decide whether a function/method was effectively 
> pure or 
> >> not. 
> >> 
> >> - I was wondering whether a simple initial approach would be to inline 
> all 
> >> but the recursive macros and functions in a program and then work 
> backwards 
> >> from the fully expanded program applying refactorings to extract shared 
> code 
> >> etc. 
> >> 
> >> - I was thinking that some of this machinery would be a nice thing to 
> have 
> >> in a Clojure IDE, advising you about potential refactorings and 
> applying 
> >> them as you type. 
> >> 
> >> - I was imagining that ultimately the inputs might not be have to be 
> >> Clojure, but maybe anything that compiled down to Java bytecode. 
> >> 
> >> - I was wondering whether there was much synergy with core.typed. 
> >> 
> >> - I was wondering whether you could work out how many cpu cycles a 
> function 
> >> might take to run by inspecting its bytecode or optimise for mechanical 
> >> sympathy if your system knew a bit about the right things. 
> >> 
> >> - I was wondering whether my program could benchmark functions then 
> rewrite 
> >> them and benchmark them again to confirm that they were faster. 
> >> 
> >> - i was considering which metrics should be used to decide that a 
> program 
> >> was simpler, 
> >> 
> >> - I was wondering whether a Clojure program could learn much about 
> writing 
> >> Clojure programs from analysing all the Clojure programs stored on e.g. 
> >> GitHub. 
> >> 
> >> - I am dreaming of the day when programs are written by more abstract 
> >> programs which are written by more abstract programs... which are 
> written by 
> >> AIs :-) 
> >> 
> >> 
> >> I guess I am talking about writing an Expert System whose problem 
> domain is 
> >> Clojure [and Java bytecode], which encodes a set of rules for 
> transforming 
> >> one form of its input into another form that in some way satisfies some 
> sort 
> >> of [sub]goal. A system which can plan refactorings from an initial 
> state to 
> >> an 'improved' goal state. 
> >> 
> >> I haven't written any code yet. I realise that this is a huge subject 
> and 
> >> that the best thing to do would be to talk to lots of people much 
> smarter 
> >> than myself about it - so here I am. 
> >> 
> >> What does everyone think ? 
> >> 
> >> Is this worth discussing or just pie in the sky ? 
> >> 
> >> Looking forward to hearing your thoughts, 
> >> 
> >> 
> >> Jules 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "Clojure" group. 
> >> To post to this group, send email to clo...@googlegroups.com 
>  
> >> Note that posts from new members are moderated - please be patient with 
> your 
> >> first post. 
> >> To unsubscribe from this group, send 

Re: crazy idea...

[Jules]

Thanks for this pointer, Lucas - it looks as if I could learn a lot from 
Kibit - I'll have a good look at it.

Jules

On Saturday, 28 November 2015 18:54:11 UTC, Lucas Bradstreet wrote:
>
> Kibit (https://github.com/jonase/kibit 
> )
>  
> does many of the things that 
> you describe, though it doesn't go as far you dream. It also uses 
> core.logic to suggest equivalent substitutions. 
>
> I'd be happy to see more work in this area. 
>
> Lucas 
>
> On 29 November 2015 at 02:01, Jules  
> wrote: 
> > Guys, 
> > 
> > I've had pieces of this idea wandering around my head for years now and 
> have 
> > finally decided that the time might be right for putting them together 
> in 
> > the context of Clojure. I'm sure that others have had similar ideas 
> before : 
> > 
> > Imagine my Clojure program which reads in your Clojure program and spits 
> out 
> > a smaller, simpler, faster Clojure program which does exactly what yours 
> > did... 
> > 
> > Of course, you are such a good programmer that your program could not be 
> > improved ? In which case we need you writing my Clojure program :-) 
> > 
> > This is opening the door onto a very large but very interesting problem 
> > space. 
> > 
> > Starting the project off in a language that is homoiconic should deliver 
> > enormous benefits straight away as the language itself provides a 
> reader, an 
> > Abstract Syntax Tree (itself) , a macro language (itself) etc... 
> > 
> > I have some initial ideas - 
> > 
> > - I was thinking of looking at core.logic to see if I might be able to 
> use 
> > it to match code to which refactorings might be applied. 
> > 
> > - I was wondering whether analysing a class/methods transitive bytecode 
> > might be enough to decide whether a function/method was effectively pure 
> or 
> > not. 
> > 
> > - I was wondering whether a simple initial approach would be to inline 
> all 
> > but the recursive macros and functions in a program and then work 
> backwards 
> > from the fully expanded program applying refactorings to extract shared 
> code 
> > etc. 
> > 
> > - I was thinking that some of this machinery would be a nice thing to 
> have 
> > in a Clojure IDE, advising you about potential refactorings and applying 
> > them as you type. 
> > 
> > - I was imagining that ultimately the inputs might not be have to be 
> > Clojure, but maybe anything that compiled down to Java bytecode. 
> > 
> > - I was wondering whether there was much synergy with core.typed. 
> > 
> > - I was wondering whether you could work out how many cpu cycles a 
> function 
> > might take to run by inspecting its bytecode or optimise for mechanical 
> > sympathy if your system knew a bit about the right things. 
> > 
> > - I was wondering whether my program could benchmark functions then 
> rewrite 
> > them and benchmark them again to confirm that they were faster. 
> > 
> > - i was considering which metrics should be used to decide that a 
> program 
> > was simpler, 
> > 
> > - I was wondering whether a Clojure program could learn much about 
> writing 
> > Clojure programs from analysing all the Clojure programs stored on e.g. 
> > GitHub. 
> > 
> > - I am dreaming of the day when programs are written by more abstract 
> > programs which are written by more abstract programs... which are 
> written by 
> > AIs :-) 
> > 
> > 
> > I guess I am talking about writing an Expert System whose problem domain 
> is 
> > Clojure [and Java bytecode], which encodes a set of rules for 
> transforming 
> > one form of its input into another form that in some way satisfies some 
> sort 
> > of [sub]goal. A system which can plan refactorings from an initial state 
> to 
> > an 'improved' goal state. 
> > 
> > I haven't written any code yet. I realise that this is a huge subject 
> and 
> > that the best thing to do would be to talk to lots of people much 
> smarter 
> > than myself about it - so here I am. 
> > 
> > What does everyone think ? 
> > 
> > Is this worth discussing or just pie in the sky ? 
> > 
> > Looking forward to hearing your thoughts, 
> > 
> > 
> > Jules 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

crazy idea...

[Jules]

Guys,

I've had pieces of this idea wandering around my head for years now and 
have finally decided that the time might be right for putting them together 
in the context of Clojure. I'm sure that others have had similar ideas 
before :

Imagine my Clojure program which reads in your Clojure program and spits 
out a smaller, simpler, faster Clojure program which does exactly what 
yours did...

Of course, you are such a good programmer that your program could not be 
improved ? In which case we need you writing my Clojure program :-)

This is opening the door onto a very large but very interesting problem 
space.

Starting the project off in a language that is homoiconic should deliver 
enormous benefits straight away as the language itself provides a reader, 
an Abstract Syntax Tree (itself) , a macro language (itself) etc...

I have some initial ideas -

- I was thinking of looking at core.logic to see if I might be able to use 
it to match code to which refactorings might be applied.

- I was wondering whether analysing a class/methods transitive bytecode 
might be enough to decide whether a function/method was effectively pure or 
not.

- I was wondering whether a simple initial approach would be to inline all 
but the recursive macros and functions in a program and then work backwards 
from the fully expanded program applying refactorings to extract shared 
code etc.

- I was thinking that some of this machinery would be a nice thing to have 
in a Clojure IDE, advising you about potential refactorings and applying 
them as you type.

- I was imagining that ultimately the inputs might not be have to be 
Clojure, but maybe anything that compiled down to Java bytecode.

- I was wondering whether there was much synergy with core.typed.

- I was wondering whether you could work out how many cpu cycles a function 
might take to run by inspecting its bytecode or optimise for mechanical 
sympathy if your system knew a bit about the right things.

- I was wondering whether my program could benchmark functions then rewrite 
them and benchmark them again to confirm that they were faster.

- i was considering which metrics should be used to decide that a program 
was simpler,

- I was wondering whether a Clojure program could learn much about writing 
Clojure programs from analysing all the Clojure programs stored on e.g. 
GitHub.

- I am dreaming of the day when programs are written by more abstract 
programs which are written by more abstract programs... which are written 
by AIs :-)


I guess I am talking about writing an Expert System whose problem domain is 
Clojure [and Java bytecode], which encodes a set of rules for transforming 
one form of its input into another form that in some way satisfies some 
sort of [sub]goal. A system which can plan refactorings from an initial 
state to an 'improved' goal state.

I haven't written any code yet. I realise that this is a huge subject and 
that the best thing to do would be to talk to lots of people much smarter 
than myself about it - so here I am.

What does everyone think ?

Is this worth discussing or just pie in the sky ?

Looking forward to hearing your thoughts,


Jules

-- 
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: crazy idea...

[Lee Spector]

Jules,

There's work using random variation and selection to do some of the more 
ambitious things you've suggested. 

See, for example, http://geneticimprovement2015.com

It'd be great to see work in this area being done in Clojure, perhaps in 
conjunction with some of the more deterministic methods you've suggested here.

 -Lee



> On Nov 28, 2015, at 1:53 PM, Lucas Bradstreet  
> wrote:
> 
> Kibit (https://github.com/jonase/kibit) does many of the things that
> you describe, though it doesn't go as far you dream. It also uses
> core.logic to suggest equivalent substitutions.
> 
> I'd be happy to see more work in this area.
> 
> Lucas
> 
> On 29 November 2015 at 02:01, Jules  wrote:
>> Guys,
>> 
>> I've had pieces of this idea wandering around my head for years now and have
>> finally decided that the time might be right for putting them together in
>> the context of Clojure. I'm sure that others have had similar ideas before :
>> 
>> Imagine my Clojure program which reads in your Clojure program and spits out
>> a smaller, simpler, faster Clojure program which does exactly what yours
>> did...
>> 
>> Of course, you are such a good programmer that your program could not be
>> improved ? In which case we need you writing my Clojure program :-)
>> 
>> This is opening the door onto a very large but very interesting problem
>> space.
>> 
>> Starting the project off in a language that is homoiconic should deliver
>> enormous benefits straight away as the language itself provides a reader, an
>> Abstract Syntax Tree (itself) , a macro language (itself) etc...
>> 
>> I have some initial ideas -
>> 
>> - I was thinking of looking at core.logic to see if I might be able to use
>> it to match code to which refactorings might be applied.
>> 
>> - I was wondering whether analysing a class/methods transitive bytecode
>> might be enough to decide whether a function/method was effectively pure or
>> not.
>> 
>> - I was wondering whether a simple initial approach would be to inline all
>> but the recursive macros and functions in a program and then work backwards
>> from the fully expanded program applying refactorings to extract shared code
>> etc.
>> 
>> - I was thinking that some of this machinery would be a nice thing to have
>> in a Clojure IDE, advising you about potential refactorings and applying
>> them as you type.
>> 
>> - I was imagining that ultimately the inputs might not be have to be
>> Clojure, but maybe anything that compiled down to Java bytecode.
>> 
>> - I was wondering whether there was much synergy with core.typed.
>> 
>> - I was wondering whether you could work out how many cpu cycles a function
>> might take to run by inspecting its bytecode or optimise for mechanical
>> sympathy if your system knew a bit about the right things.
>> 
>> - I was wondering whether my program could benchmark functions then rewrite
>> them and benchmark them again to confirm that they were faster.
>> 
>> - i was considering which metrics should be used to decide that a program
>> was simpler,
>> 
>> - I was wondering whether a Clojure program could learn much about writing
>> Clojure programs from analysing all the Clojure programs stored on e.g.
>> GitHub.
>> 
>> - I am dreaming of the day when programs are written by more abstract
>> programs which are written by more abstract programs... which are written by
>> AIs :-)
>> 
>> 
>> I guess I am talking about writing an Expert System whose problem domain is
>> Clojure [and Java bytecode], which encodes a set of rules for transforming
>> one form of its input into another form that in some way satisfies some sort
>> of [sub]goal. A system which can plan refactorings from an initial state to
>> an 'improved' goal state.
>> 
>> I haven't written any code yet. I realise that this is a huge subject and
>> that the best thing to do would be to talk to lots of people much smarter
>> than myself about it - so here I am.
>> 
>> What does everyone think ?
>> 
>> Is this worth discussing or just pie in the sky ?
>> 
>> Looking forward to hearing your thoughts,
>> 
>> 
>> Jules
>> 
>> --
>> 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.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this 

Re: crazy idea...

[Lucas Bradstreet]

Kibit (https://github.com/jonase/kibit) does many of the things that
you describe, though it doesn't go as far you dream. It also uses
core.logic to suggest equivalent substitutions.

I'd be happy to see more work in this area.

Lucas

On 29 November 2015 at 02:01, Jules  wrote:
> Guys,
>
> I've had pieces of this idea wandering around my head for years now and have
> finally decided that the time might be right for putting them together in
> the context of Clojure. I'm sure that others have had similar ideas before :
>
> Imagine my Clojure program which reads in your Clojure program and spits out
> a smaller, simpler, faster Clojure program which does exactly what yours
> did...
>
> Of course, you are such a good programmer that your program could not be
> improved ? In which case we need you writing my Clojure program :-)
>
> This is opening the door onto a very large but very interesting problem
> space.
>
> Starting the project off in a language that is homoiconic should deliver
> enormous benefits straight away as the language itself provides a reader, an
> Abstract Syntax Tree (itself) , a macro language (itself) etc...
>
> I have some initial ideas -
>
> - I was thinking of looking at core.logic to see if I might be able to use
> it to match code to which refactorings might be applied.
>
> - I was wondering whether analysing a class/methods transitive bytecode
> might be enough to decide whether a function/method was effectively pure or
> not.
>
> - I was wondering whether a simple initial approach would be to inline all
> but the recursive macros and functions in a program and then work backwards
> from the fully expanded program applying refactorings to extract shared code
> etc.
>
> - I was thinking that some of this machinery would be a nice thing to have
> in a Clojure IDE, advising you about potential refactorings and applying
> them as you type.
>
> - I was imagining that ultimately the inputs might not be have to be
> Clojure, but maybe anything that compiled down to Java bytecode.
>
> - I was wondering whether there was much synergy with core.typed.
>
> - I was wondering whether you could work out how many cpu cycles a function
> might take to run by inspecting its bytecode or optimise for mechanical
> sympathy if your system knew a bit about the right things.
>
> - I was wondering whether my program could benchmark functions then rewrite
> them and benchmark them again to confirm that they were faster.
>
> - i was considering which metrics should be used to decide that a program
> was simpler,
>
> - I was wondering whether a Clojure program could learn much about writing
> Clojure programs from analysing all the Clojure programs stored on e.g.
> GitHub.
>
> - I am dreaming of the day when programs are written by more abstract
> programs which are written by more abstract programs... which are written by
> AIs :-)
>
>
> I guess I am talking about writing an Expert System whose problem domain is
> Clojure [and Java bytecode], which encodes a set of rules for transforming
> one form of its input into another form that in some way satisfies some sort
> of [sub]goal. A system which can plan refactorings from an initial state to
> an 'improved' goal state.
>
> I haven't written any code yet. I realise that this is a huge subject and
> that the best thing to do would be to talk to lots of people much smarter
> than myself about it - so here I am.
>
> What does everyone think ?
>
> Is this worth discussing or just pie in the sky ?
>
> Looking forward to hearing your thoughts,
>
>
> Jules
>
> --
> 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.

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