Re: Leo and abstraction

[Terry Brown]

On Tue, 21 Mar 2017 10:31:33 -0500
"Edward K. Ream"  wrote:

> I used to think that coffeescript might be a good enough wrapper for
> javascript, but having seen d3 and the agile visualization demos, I
> think the only way to use javascript is via a package.  There just
> isn't time for low-level javascript (or coffeescript) coding.

Although I like coffeescript a lot and continue to use it in ongoing
projects, I think it might be at a bit of a dead end.  I think, and
have seen others blog the same, that coffeescript fixed ECMAScript 5,
and ECMAScript 6 broke coffeescript.  I can't remember the details now
but I think there are some conflicts in how object attributes are
iterated (i in x vs. i of x etc.) and possibly generators and other
nice new features of ECMAScript 6.

Definitely agree that JS dev. needs to be approached through a library
etc.  Just started looking at React.  There are a lot of choices to
make (Angular, Vue?, etc.).  Got to say the "my choice is best" holy
wars seems more intense in the JS realm.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo and abstraction

[Offray Vladimir Luna Cárdenas]

On 21/03/17 10:31, Edward K. Ream wrote:
On Tue, Mar 21, 2017 at 10:05 AM, Offray Vladimir Luna Cárdenas 
mailto:off...@riseup.net>> wrote:


​> ​
Thanks to you for Leo and this live and constructive community. Ideas 
are difficult to express by mail... sometimes is easier to build your 
own software and send the link to the mailing list :-).


​The links to the videos were especially helpful because they show the 
dynamic nature of the software in action.​





Yes. They revealed to me that Live coding and Agile Visualization give a 
particular edge to Pharo over other technologies to prototype ideas. But 
finding the proper"narrative" to share them took a lot of time. This 
narrative is literate computing and now we're talking a lot about blue 
sky Leo futures.



​As I see it now, the question is always, "how easy is it to
emulate feature A in environment B?". It's pretty easy to set up
an @button node in Leo so that it emulates Pharo's instant
execution model. Whether it's possible to get access to agile
visualization in the python world is another question.


Agile visualization and live coding are game changers for me, so
much that Pharo became my platform to express/combine ideas.
Jupyter is exploring that path in some way for the Python word
with interesting ideas and a lot of attention, but also with a
complex multilayered (fractured?) stack behind. Hopefully Leo will
provide clarity there also.


​Yes, I now understand why you like Pharo.

I used to think that coffeescript might be a good enough wrapper for 
javascript, but having seen d3 and the agile visualization demos, I 
think the only way to use javascript is via a package. There just 
isn't time for low-level javascript (or coffeescript) coding.




I agree. In [1] I compare a little bit of D3 with Agile Visualization 
(Roassal). Live coding still gives an edge, because you don't have to 
deal with the fractured file system world: load/edit a file, (re)load 
rendering in the browser, choose/learn your code editor and DCVS, etc. 
There is a lot of friction. In the Grafoscopio User Manual (in English) 
I say where Grafoscopio is similar and different from other tools 
(including Leo, Jupyter and OrgMode). So yes, having coffe script as a 
reference could be good, but I think that vega and vega lite or other 
hight level languages should be part of the default experience of 
literate computing in Leo, and the core search for future releases could 
be in how to bring live coding to python via Leo (and its powerful 
self-referential tree/DOM).


[1] http://mutabit.com/offray/blog/en/entry/sdv-infomed
[2] 
http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/manual.pdf


Cheers,

Offray

--
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo and abstraction

[Edward K. Ream]

On Tue, Mar 21, 2017 at 10:05 AM, Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

​> ​
Thanks to you for Leo and this live and constructive community. Ideas are
difficult to express by mail... sometimes is easier to build your own
software and send the link to the mailing list :-).

​The links to the videos were especially helpful because they show the
dynamic nature of the software in action.​


​As I see it now, the question is always, "how easy is it to emulate
> feature A in environment B?". It's pretty easy to set up an @button node in
> Leo so that it emulates Pharo's instant execution model. Whether it's
> possible to get access to agile visualization in the python world is
> another question.
>
>
> Agile visualization and live coding are game changers for me, so much that
> Pharo became my platform to express/combine ideas. Jupyter is exploring
> that path in some way for the Python word with interesting ideas and a lot
> of attention, but also with a complex multilayered (fractured?) stack
> behind. Hopefully Leo will provide clarity there also.
>

​Yes, I now understand why you like Pharo.

I used to think that coffeescript might be a good enough wrapper for
javascript, but having seen d3 and the agile visualization demos, I think
the only way to use javascript is via a package.  There just isn't time for
low-level javascript (or coffeescript) coding.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo and abstraction

[Offray Vladimir Luna Cárdenas]

Hi,


On 21/03/17 09:06, Edward K. Ream wrote:
On Mon, Mar 20, 2017 at 7:33 PM, Offray Vladimir Luna Cárdenas 
mailto:off...@riseup.net>> wrote:


I'm trying to bring some Leo ideas to the Pharo live coding
environment by prototyping them and some other back here by
discussing on the list.

​Excellent. One less thing that I have to do. Hehe.​




He! There is a lot of learning on the "do your idea by yourself" 
pedagogy ;-).



The idea of outlining as emergent order is a powerful way of
dealing with our own cognitive limits, not only for the
programmer, but for anyone that wants to make literate computing
on complex matters (scientists, activists, journalists, students,
teachers, etc.). The idea of having a development environment
behind the notebook experience is being explored by Org Mode with
emacs and now by Jupyter with Jupyter Lab and Grafoscopio with
Pharo. I wonder how we can deal with complexity when we combine
this emergent order of outlining with live coding and broader dev
frameworks. Precisely today I was making some mind maps about this:
​...​
​​[These] are interesting times for ideas cross-pollination and
exploration.


​Yes indeed.  Many thanks for these links and your persistence. At 
last I understand your general idea.​




Thanks to you for Leo and this live and constructive community. Ideas 
are difficult to express by mail... sometimes is easier to build your 
own software and send the link to the mailing list :-).




​As I see it now, the question is always, "how easy is it to emulate 
feature A in environment B?". It's pretty easy to set up an @button 
node in Leo so that it emulates Pharo's instant execution model. 
Whether it's possible to get access to agile visualization in the 
python world is another question.




Agile visualization and live coding are game changers for me, so much 
that Pharo became my platform to express/combine ideas. Jupyter is 
exploring that path in some way for the Python word with interesting 
ideas and a lot of attention, but also with a complex multilayered 
(fractured?) stack behind. Hopefully Leo will provide clarity there also.


Cheers,

Offray


--
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo and abstraction

[Edward K. Ream]

On Mon, Mar 20, 2017 at 7:33 PM, Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

> I'm trying to bring some Leo ideas to the Pharo live coding environment by
> prototyping them and some other back here by discussing on the list.
>
​Excellent. One less thing that I have to do. Hehe.​


The idea of outlining as emergent order is a powerful way of dealing with
> our own cognitive limits, not only for the programmer, but for anyone that
> wants to make literate computing on complex matters (scientists, activists,
> journalists, students, teachers, etc.). The idea of having a development
> environment behind the notebook experience is being explored by Org Mode
> with emacs and now by Jupyter with Jupyter Lab and Grafoscopio with Pharo.
> I wonder how we can deal with complexity when we combine this emergent
> order of outlining with live coding and broader dev frameworks. Precisely
> today I was making some mind maps about this:
> ​...​
> ​​[These] are interesting times for ideas cross-pollination and
> exploration.
>

​Yes indeed.  Many thanks for these links and your persistence. At last I
understand your general idea.​


​As I see it now, the question is always, "how easy is it to emulate
feature A in environment B?". It's pretty easy to set up an @button node in
Leo so that it emulates Pharo's instant execution model. Whether it's
possible to get access to agile visualization in the python world is
another question.

Edward​

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo and abstraction

[Offray Vladimir Luna Cárdenas]

Thanks for your testimony John. I have given some similar testimony [1]. 
I'm trying to bring some Leo ideas to the Pharo live coding environment 
by prototyping them and some other back here by discussing on the list.


[1] http://leoeditor.com/testimonials.html#offray-luna-cardenas

The idea of outlining as emergent order is a powerful way of dealing 
with our own cognitive limits, not only for the programmer, but for 
anyone that wants to make literate computing on complex matters 
(scientists, activists, journalists, students, teachers, etc.). The idea 
of having a development environment behind the notebook experience is 
being explored by Org Mode with emacs and now by Jupyter with Jupyter 
Lab and Grafoscopio with Pharo. I wonder how we can deal with complexity 
when we combine this emergent order of outlining with live coding and 
broader dev frameworks. Precisely today I was making some mind maps 
about this:


This are interesting times for ideas crosspollination and exploration.

Cheers,

Offray



On 03/03/17 10:11, john lunzer wrote:

Warning: This is a testimonial, sorry.

Lately I've been thinking about programming in general. My thoughts 
have centered on the limits of the human brain to understand computer 
programs. This was triggered by watching Inventing on Principle 
. It's a daunting 
multifaceted concept which I'm sure people spend their entire lives 
pondering.


Most recently I've been focusing on one facet, abstraction and program 
"units". I define a "unit" as a part of the program that is considered 
a piece onto itself which can be labeled and referred to as a whole. 
Perhaps, as a daily Leo user, this is easy to think about because Leo 
does its best to coerce programmers and programs into looking at 
programming through this lens.


Most tools do not ignore this concept all together. Most programming 
environments have some sort of "outline" window which allows you to 
view the structure of a program at a higher level. As I have 
experienced it this "outline" view is always dictated by the features 
of a language (ex. outline divided up at module, class, function 
levels). In addition most tools incorporate "code folding" to help a 
programmer focus on language specific programming units (again, ex. 
folding at class and function definitions).


Leo takes this concept to its limit. Leo offers language agnostic 
abstraction at arbitrary levels. It allows a programmer to structure 
their program outside of the confines of the programming paradigms of 
the language they're programming in. Of course it still helps to use 
the language specific "units" as a guide, in fact this is what Leo 
does upon import to create an initial outline structure from programs 
originating outside of Leo.


I can't ignore the freedom of arbitrary abstraction, and I've come to 
rely upon it so much that I struggle to use non-Leo environments. It 
is well known that the human brain has a limited working memory. The 
act of programming stretches working memory to it's limit. Leo 
provides an environment in which a program can seamlessly be 
restructured to fit within the bounds of a programmers individual 
working memory.


I realize this is a "why" and not a "how" and that this doesn't help 
anyone get better acquainted with Leo. But, as a programmer if you've 
ever felt frustrated with the organizational constructs of the 
language you're working in you might be surprised to realize that 
after using Leo it wasn't the language that was the problem, but a 
lack of tools to organize your programs in a way that makes sense to 
/you/.

--
You received this message because you are subscribed to the Google 
Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to leo-editor+unsubscr...@googlegroups.com 
.
To post to this group, send email to leo-editor@googlegroups.com 
.

Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo and abstraction

[Edward K. Ream]

On Fri, Mar 3, 2017 at 9:11 AM, john lunzer  wrote:

> Warning: This is a testimonial, sorry.
>

​No need to apologize.  I'll add it to the testimonials page.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo and abstraction

[john lunzer]

Good point Terry. Chapters too, I've been using them a lot again lately and 
I find they help quite a bit with context switching when editing multiple 
large related programs/projects simultaneously. I see chapters as 
essentially the same thing as bookmarks but with Hoist built in.

On Friday, March 3, 2017 at 12:29:45 PM UTC-5, Terry Brown wrote:
>
> Well said.  When you think about it there are a number of features in Leo 
> that allow personalized abstraction.  Organizer nodes are the simplest, but 
> all the various methods for linking between distant parts of the tree are 
> also helpful (backlinks, unls, bookmarks, tags, even clones ;-)
>
> Cheers -Terry
>
> --
> *From:* john lunzer >
> *To:* leo-editor > 
> *Sent:* Friday, March 3, 2017 9:11 AM
> *Subject:* Leo and abstraction
>
> Warning: This is a testimonial, sorry.
>
> Lately I've been thinking about programming in general. My thoughts have 
> centered on the limits of the human brain to understand computer programs. 
> This was triggered by watching Inventing on Principle 
> <https://www.youtube.com/watch?v=PUv66718DII>. It's a daunting 
> multifaceted concept which I'm sure people spend their entire lives 
> pondering.
>
> Most recently I've been focusing on one facet, abstraction and program 
> "units". I define a "unit" as a part of the program that is considered a 
> piece onto itself which can be labeled and referred to as a whole. Perhaps, 
> as a daily Leo user, this is easy to think about because Leo does its best 
> to coerce programmers and programs into looking at programming through this 
> lens.
>
> Most tools do not ignore this concept all together. Most programming 
> environments have some sort of "outline" window which allows you to view 
> the structure of a program at a higher level. As I have experienced it this 
> "outline" view is always dictated by the features of a language (ex. 
> outline divided up at module, class, function levels). In addition most 
> tools incorporate "code folding" to help a programmer focus on language 
> specific programming units (again, ex. folding at class and function 
> definitions). 
>
> Leo takes this concept to its limit. Leo offers language agnostic 
> abstraction at arbitrary levels. It allows a programmer to structure their 
> program outside of the confines of the programming paradigms of the 
> language they're programming in. Of course it still helps to use the 
> language specific "units" as a guide, in fact this is what Leo does upon 
> import to create an initial outline structure from programs originating 
> outside of Leo. 
>
> I can't ignore the freedom of arbitrary abstraction, and I've come to rely 
> upon it so much that I struggle to use non-Leo environments. It is well 
> known that the human brain has a limited working memory. The act of 
> programming stretches working memory to it's limit. Leo provides an 
> environment in which a program can seamlessly be restructured to fit within 
> the bounds of a programmers individual working memory. 
>
> I realize this is a "why" and not a "how" and that this doesn't help 
> anyone get better acquainted with Leo. But, as a programmer if you've ever 
> felt frustrated with the organizational constructs of the language you're 
> working in you might be surprised to realize that after using Leo it wasn't 
> the language that was the problem, but a lack of tools to organize your 
> programs in a way that makes sense to *you*.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to leo-editor+...@googlegroups.com .
> To post to this group, send email to leo-e...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo and abstraction

['Terry Brown' via leo-editor]

Well said.  When you think about it there are a number of features in Leo that 
allow personalized abstraction.  Organizer nodes are the simplest, but all the 
various methods for linking between distant parts of the tree are also helpful 
(backlinks, unls, bookmarks, tags, even clones ;-)
Cheers -Terry
  From: john lunzer 
 To: leo-editor  
 Sent: Friday, March 3, 2017 9:11 AM
 Subject: Leo and abstraction
   
Warning: This is a testimonial, sorry.
Lately I've been thinking about programming in general. My thoughts have 
centered on the limits of the human brain to understand computer programs. This 
was triggered by watching Inventing on Principle. It's a daunting multifaceted 
concept which I'm sure people spend their entire lives pondering.
Most recently I've been focusing on one facet, abstraction and program "units". 
I define a "unit" as a part of the program that is considered a piece onto 
itself which can be labeled and referred to as a whole. Perhaps, as a daily Leo 
user, this is easy to think about because Leo does its best to coerce 
programmers and programs into looking at programming through this lens.
Most tools do not ignore this concept all together. Most programming 
environments have some sort of "outline" window which allows you to view the 
structure of a program at a higher level. As I have experienced it this 
"outline" view is always dictated by the features of a language (ex. outline 
divided up at module, class, function levels). In addition most tools 
incorporate "code folding" to help a programmer focus on language specific 
programming units (again, ex. folding at class and function definitions). 
Leo takes this concept to its limit. Leo offers language agnostic abstraction 
at arbitrary levels. It allows a programmer to structure their program outside 
of the confines of the programming paradigms of the language they're 
programming in. Of course it still helps to use the language specific "units" 
as a guide, in fact this is what Leo does upon import to create an initial 
outline structure from programs originating outside of Leo. 
I can't ignore the freedom of arbitrary abstraction, and I've come to rely upon 
it so much that I struggle to use non-Leo environments. It is well known that 
the human brain has a limited working memory. The act of programming stretches 
working memory to it's limit. Leo provides an environment in which a program 
can seamlessly be restructured to fit within the bounds of a programmers 
individual working memory. 
I realize this is a "why" and not a "how" and that this doesn't help anyone get 
better acquainted with Leo. But, as a programmer if you've ever felt frustrated 
with the organizational constructs of the language you're working in you might 
be surprised to realize that after using Leo it wasn't the language that was 
the problem, but a lack of tools to organize your programs in a way that makes 
sense to you.-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


   

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Leo and abstraction

[john lunzer]

Warning: This is a testimonial, sorry.

Lately I've been thinking about programming in general. My thoughts have 
centered on the limits of the human brain to understand computer programs. 
This was triggered by watching Inventing on Principle 
. It's a daunting multifaceted 
concept which I'm sure people spend their entire lives pondering.

Most recently I've been focusing on one facet, abstraction and program 
"units". I define a "unit" as a part of the program that is considered a 
piece onto itself which can be labeled and referred to as a whole. Perhaps, 
as a daily Leo user, this is easy to think about because Leo does its best 
to coerce programmers and programs into looking at programming through this 
lens.

Most tools do not ignore this concept all together. Most programming 
environments have some sort of "outline" window which allows you to view 
the structure of a program at a higher level. As I have experienced it this 
"outline" view is always dictated by the features of a language (ex. 
outline divided up at module, class, function levels). In addition most 
tools incorporate "code folding" to help a programmer focus on language 
specific programming units (again, ex. folding at class and function 
definitions). 

Leo takes this concept to its limit. Leo offers language agnostic 
abstraction at arbitrary levels. It allows a programmer to structure their 
program outside of the confines of the programming paradigms of the 
language they're programming in. Of course it still helps to use the 
language specific "units" as a guide, in fact this is what Leo does upon 
import to create an initial outline structure from programs originating 
outside of Leo. 

I can't ignore the freedom of arbitrary abstraction, and I've come to rely 
upon it so much that I struggle to use non-Leo environments. It is well 
known that the human brain has a limited working memory. The act of 
programming stretches working memory to it's limit. Leo provides an 
environment in which a program can seamlessly be restructured to fit within 
the bounds of a programmers individual working memory. 

I realize this is a "why" and not a "how" and that this doesn't help anyone 
get better acquainted with Leo. But, as a programmer if you've ever felt 
frustrated with the organizational constructs of the language you're 
working in you might be surprised to realize that after using Leo it wasn't 
the language that was the problem, but a lack of tools to organize your 
programs in a way that makes sense to *you*.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.