Re: [ANN] An impudent introduction to Guile

Re: [ANN] An impudent introduction to Guile

[Cao Jin]

It's interesting. I have used Matlab for many years, but never tried R. As for as I know, there are tons of state-of-the-art library in R and Matlab.

After skimming your paper, I wander that
1) Are these library used in your code example implemented by yourself? Or other libraries are called, such as LAPACK for linear algebra?
2) Is it easy to use scheme and your library, or maybe some others, to do computational job? In practice, those who use R or Matlab want their idea to be proved quickly, not to spend time on coding style, right?

If scheme can do most computational job as python numpy does, I will switch to it.


On Feb 5, 2016 7:09 AM, Panicz Maciej Godek <godek.maciek@gmail.com> wrote:
>
> Hi,
> I am pleased to announce that I just finished my booklet titled
>
> A Pamphlet against R
> Computational Intelligence with Guile Scheme
>
> The pamphlet introduces (in a truly impertinent manner) a set of libraries that I have been developing over the last few months, including topics like:
>
> - genetic algorithms
> - fuzzy logic
> - decision trees
> - clusterization
>
> and more!
>
> The book (in both pdf and LaTeX) is available with the required libraries under the Creative Commons license at
> http://panicz.github.io/pamphlet/
>
> Yeey!
>

Re: [ANN] An impudent introduction to Guile

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]

Hi

2016-02-06 1:47 GMT+01:00 Cao Jin <lop@null.net>:

> It's interesting. I have used Matlab for many years, but never tried R. As
> for as I know, there are tons of state-of-the-art library in R and Matlab.
>
> After skimming your paper, I wander that
> 1) Are these library used in your code example implemented by yourself? Or
> other libraries are called, such as LAPACK for linear algebra?
>

Everything is either written from scratch, or uses one of the helper
libraries (two such libraries are included in the repo; the other is
SRFI-1).
The point of the book is that it is not a tutorial on using libraries, but
it explains some methods and translates these explanations to Scheme, so
that they can be modified and extended easily.

If you are looking  for some serious numerical libraries for Scheme,
there's a very powerful scmutils package available

http://www.cs.rochester.edu/~gildea/guile-scmutils/

I've actually used its code for Singular Value Decomposition to perform
Principal Component Analysis.

2) Is it easy to use scheme and your library, or maybe some others, to do
> computational job? In practice, those who use R or Matlab want their idea
> to be proved quickly, not to spend time on coding style, right?
>
> I think it depends on a point of view. I initially tried using R, but it
was causing many unexpected problems, but I already knew Scheme quite well,
and for me even implementing the libraries from scratch wasn't that much
of  a job.
But the book is mostly about fun, and about understanding.
Also, interfacing Guile with Emacs through Geiser is an incredible
productivity boost.

Interestingly, when I benchmarked the genetic algorithm that I wrote with
genalg package from R, the Scheme version run in Guile actually
outperformed the R version, although it was written in completely
performance-naive style.

On the other hand, if you wanted to use the decision trees classifier,
you'd probably want to apply memoization.

If scheme can do most computational job as python numpy does, I will switch
> to it.
>

I think that in practice Scheme can be even more convinient, as it provides
native support for complex numbers

I also think it would be helpful to interface Guile with plot generation. I
see that Nala has a guile-plot package, but I haven't tried it. I
personally wrote some code for generating LaTeX pgfplots for the project,
and can add it to the repo if you llike.

[-- Attachment #2: Type: text/html, Size: 3380 bytes --]

Re: [ANN] An impudent introduction to Guile

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]


Panicz Maciej Godek writes:

> I also think it would be helpful to interface Guile with plot generation. I
> see that Nala has a guile-plot package, but I haven't tried it. I
> personally wrote some code for generating LaTeX pgfplots for the project,
> and can add it to the repo if you llike.

A good plotting tool would be great!

I actually opened a socket to Python and used pylab from Scheme when I
wanted to plot beautifully…

Liebe Grüße,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 298 bytes --]

Re: [ANN] An impudent introduction to Guile

[Cao Jin]

[-- Attachment #1: Type: text/plain, Size: 2988 bytes --]

Hi Panicz,

Thank you for these information.

On 2/6/2016 14:08, Panicz Maciej Godek wrote:
> Hi
>
> 2016-02-06 1:47 GMT+01:00 Cao Jin <lop@null.net <mailto:lop@null.net>>:
>
>     It's interesting. I have used Matlab for many years, but never
>     tried R. As for as I know, there are tons of state-of-the-art
>     library in R and Matlab.
>
>     After skimming your paper, I wander that
>     1) Are these library used in your code example implemented by
>     yourself? Or other libraries are called, such as LAPACK for linear
>     algebra?
>
>
> Everything is either written from scratch, or uses one of the helper
> libraries (two such libraries are included in the repo; the other is
> SRFI-1).
> The point of the book is that it is not a tutorial on using libraries,
> but it explains some methods and translates these explanations to
> Scheme, so that they can be modified and extended easily.
>  
> If you are looking  for some serious numerical libraries for Scheme,
> there's a very powerful scmutils package available
>
> http://www.cs.rochester.edu/~gildea/guile-scmutils/
> <http://www.cs.rochester.edu/%7Egildea/guile-scmutils/>
>
> I've actually used its code for Singular Value Decomposition to
> perform Principal Component Analysis.
OK, I will try it later.
>
>     2) Is it easy to use scheme and your library, or maybe some
>     others, to do computational job? In practice, those who use R or
>     Matlab want their idea to be proved quickly, not to spend time on
>     coding style, right?
>
> I think it depends on a point of view. I initially tried using R, but
> it was causing many unexpected problems, but I already knew Scheme
> quite well, and for me even implementing the libraries from scratch
> wasn't that much of  a job.
> But the book is mostly about fun, and about understanding.
> Also, interfacing Guile with Emacs through Geiser is an incredible
> productivity boost.
>
> Interestingly, when I benchmarked the genetic algorithm that I wrote
> with genalg package from R, the Scheme version run in Guile actually
> outperformed the R version, although it was written in completely
> performance-naive style.
>
It's great to see this result.

> On the other hand, if you wanted to use the decision trees classifier,
> you'd probably want to apply memoization.
>
>     If scheme can do most computational job as python numpy does, I
>     will switch to it.
>
>
> I think that in practice Scheme can be even more convinient, as it
> provides native support for complex numbers
>
> I also think it would be helpful to interface Guile with plot
> generation. I see that Nala has a guile-plot package, but I haven't
> tried it. I personally wrote some code for generating LaTeX pgfplots
> for the project, and can add it to the repo if you llike.
>

As described above, I think it is worth trying Scheme for numerical
computing. Your work is appreciated!

Regards,
Lop


[-- Attachment #2: Type: text/html, Size: 6286 bytes --]

Re: [ANN] An impudent introduction to Guile

[Jan Wedekind]

On 6. Februar 2016 06:08:42 GMT+00:00, Panicz Maciej Godek <godek.maciek@gmail.com> wrote:
>Hi
>
>2016-02-06 1:47 GMT+01:00 Cao Jin <lop@null.net>:
>
>> It's interesting. I have used Matlab for many years, but never tried
>R. As
>> for as I know, there are tons of state-of-the-art library in R and
>Matlab.
>>
>> After skimming your paper, I wander that
>> 1) Are these library used in your code example implemented by
>yourself? Or
>> other libraries are called, such as LAPACK for linear algebra?
>>
>
>Everything is either written from scratch, or uses one of the helper
>libraries (two such libraries are included in the repo; the other is
>SRFI-1).
>The point of the book is that it is not a tutorial on using libraries,
>but
>it explains some methods and translates these explanations to Scheme,
>so
>that they can be modified and extended easily.
>
>If you are looking  for some serious numerical libraries for Scheme,
>there's a very powerful scmutils package available
>
>http://www.cs.rochester.edu/~gildea/guile-scmutils/
>
>I've actually used its code for Singular Value Decomposition to perform
>Principal Component Analysis.
>
>2) Is it easy to use scheme and your library, or maybe some others, to
>do
>> computational job? In practice, those who use R or Matlab want their
>idea
>> to be proved quickly, not to spend time on coding style, right?
>>
>> I think it depends on a point of view. I initially tried using R, but
>it
>was causing many unexpected problems, but I already knew Scheme quite
>well,
>and for me even implementing the libraries from scratch wasn't that
>much
>of  a job.
>But the book is mostly about fun, and about understanding.
>Also, interfacing Guile with Emacs through Geiser is an incredible
>productivity boost.
>
>Interestingly, when I benchmarked the genetic algorithm that I wrote
>with
>genalg package from R, the Scheme version run in Guile actually
>outperformed the R version, although it was written in completely
>performance-naive style.
>
>On the other hand, if you wanted to use the decision trees classifier,
>you'd probably want to apply memoization.
>
>If scheme can do most computational job as python numpy does, I will
>switch
>> to it.
>>
>
>I think that in practice Scheme can be even more convinient, as it
>provides
>native support for complex numbers
>
>I also think it would be helpful to interface Guile with plot
>generation. I
>see that Nala has a guile-plot package, but I haven't tried it. I
>personally wrote some code for generating LaTeX pgfplots for the
>project,
>and can add it to the repo if you llike.

Interesting. Will have a look at how they expose operators.

Myself I have implemented http://github.com/wedesoft/aism for array operations.
-- 
Jan Wedekind
http://www.wedesoft.de/

Re: [ANN] An impudent introduction to Guile

[A0]

On 06/02/16 00:47, Cao Jin wrote:
> It's interesting. I have used Matlab for many years, but never
> tried R. As for as I know, there are tons of state-of-the-art
> library in R and Matlab.
> 
> After skimming your paper, I wander that 1) Are these library used
> in your code example implemented by yourself? Or other libraries
> are called, such as LAPACK for linear algebra? 2) Is it easy to use
> scheme and your library, or maybe some others, to do computational
> job? In practice, those who use R or Matlab want their idea to be
> proved quickly, not to spend time on coding style, right?
> 
> If scheme can do most computational job as python numpy does, I
> will switch to it.
> 
> 
> On Feb 5, 2016 7:09 AM, Panicz Maciej Godek
> <godek.maciek@gmail.com> wrote:
>> 
>> Hi, I am pleased to announce that I just finished my booklet
>> titled
>> 
>> A Pamphlet against R Computational Intelligence with Guile
>> Scheme
>> 
>> The pamphlet introduces (in a truly impertinent manner) a set of
>> libraries that I have been developing over the last few months,
>> including topics like:
>> 
>> - genetic algorithms - fuzzy logic - decision trees -
>> clusterization
>> 
>> and more!
>> 
>> The book (in both pdf and LaTeX) is available with the required
>> libraries under the Creative Commons license at 
>> http://panicz.github.io/pamphlet/
>> 
>> Yeey!
>> 

Hi,

Guile has an excellent Foreign Function Interface that one can use to
call any existing C or
Fortran (if bind(c) interfaces provided) optimised numerical routines,
usually directly
(most of the time, you don't need to write wrappers). I have already
used it in some projects.
On the Guile side, there are data structures like bytevectors that can
represent C-pointers,
as well as the array data type which has a set of useful routines to
manipulate array data collectively.

Of course, there aren't loads of numerical packages (so nothing like
CRAN)
written for Guile specifically.

The job where Guile excels from my perspective (someone who produces
optimised numerical codes
that solve equations) is to bind things together, to provide top-level
loops, interrupts, easy access
to the operating system. To impose structure.

Re: [ANN] An impudent introduction to Guile

[Lawrence Bottorff]

[-- Attachment #1: Type: text/plain, Size: 3270 bytes --]

I've got this <https://github.com/borgauf/pamphlet> fork going where I've
done some editing (grammar, style, spelling, etc.) on the book (up to
"Reporting bugs." Let me know what you think.

In general, I think Scheme desperately needs an "O'Reilly"-style book.

Question: What should we say when someone asks, "Why should I fool with a
new programming language when there's Matlab/Mathematica/etc.?"

I think this is a great project. I myself have recently started something
similar which shamelessly puts coding (in Scheme) together with high school
math. Two things I want to avoid is 1) having other "blub" languages fill
this yawning gap (read Python), and 2) helping cushion the computer science
wall where hot-shot high-school coders go to college, major in comp-sci . .
. and then hit the comp-sci wall, i.e., discrete math, theory, no more cool
coding tricks, etc.

LB

On Sun, Feb 7, 2016 at 4:54 AM, A0 <cape.wrath@openmailbox.org> wrote:

>
>
> On 06/02/16 00:47, Cao Jin wrote:
> > It's interesting. I have used Matlab for many years, but never
> > tried R. As for as I know, there are tons of state-of-the-art
> > library in R and Matlab.
> >
> > After skimming your paper, I wander that 1) Are these library used
> > in your code example implemented by yourself? Or other libraries
> > are called, such as LAPACK for linear algebra? 2) Is it easy to use
> > scheme and your library, or maybe some others, to do computational
> > job? In practice, those who use R or Matlab want their idea to be
> > proved quickly, not to spend time on coding style, right?
> >
> > If scheme can do most computational job as python numpy does, I
> > will switch to it.
> >
> >
> > On Feb 5, 2016 7:09 AM, Panicz Maciej Godek
> > <godek.maciek@gmail.com> wrote:
> >>
> >> Hi, I am pleased to announce that I just finished my booklet
> >> titled
> >>
> >> A Pamphlet against R Computational Intelligence with Guile
> >> Scheme
> >>
> >> The pamphlet introduces (in a truly impertinent manner) a set of
> >> libraries that I have been developing over the last few months,
> >> including topics like:
> >>
> >> - genetic algorithms - fuzzy logic - decision trees -
> >> clusterization
> >>
> >> and more!
> >>
> >> The book (in both pdf and LaTeX) is available with the required
> >> libraries under the Creative Commons license at
> >> http://panicz.github.io/pamphlet/
> >>
> >> Yeey!
> >>
>
> Hi,
>
> Guile has an excellent Foreign Function Interface that one can use to
> call any existing C or
> Fortran (if bind(c) interfaces provided) optimised numerical routines,
> usually directly
> (most of the time, you don't need to write wrappers). I have already
> used it in some projects.
> On the Guile side, there are data structures like bytevectors that can
> represent C-pointers,
> as well as the array data type which has a set of useful routines to
> manipulate array data collectively.
>
> Of course, there aren't loads of numerical packages (so nothing like
> CRAN)
> written for Guile specifically.
>
> The job where Guile excels from my perspective (someone who produces
> optimised numerical codes
> that solve equations) is to bind things together, to provide top-level
> loops, interrupts, easy access
> to the operating system. To impose structure.
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 4326 bytes --]

Re: [ANN] An impudent introduction to Guile

[Panicz Maciej Godek]

2016-02-07 22:51 GMT+01:00, Lawrence Bottorff <borgauf@gmail.com>:
> I've got this <https://github.com/borgauf/pamphlet> fork going where I've
> done some editing (grammar, style, spelling, etc.) on the book (up to
> "Reporting bugs." Let me know what you think.

I'm really impressed! Thanks! :)
However, I do have some remarks:

1. if possible, it would be nice if you could keep the lines up to 80
columns each (60 columns is preferable). I do editing in Emacs in
terminal on a very tiny display and I often split the screen in two
halves for comparatory editing.
The only exception are links that are more than 80 columns long.

2. in the line 161, you expanded the sentence "The first chapter
introduces all the elementary notions needed for programming" with the
adverbial "in Scheme". My original intent was that -- although the
syntactic guise of the programs expressed is obviously Scheme -- the
presented notions (of definition, reduction and substitution) are
required to do programming in general.

3. I'm not quite convinced whether \texttt{equivalence-classes} should
be replaced with \textit{equivalence-classes}. If we actually decide
to do so, I think it would be better to replace it as
\textit{equivalence classes}. However, although the italics are
actually used to refer to new notions, and typewriter font to refer to
notions/functions defined in Scheme, that use case is closer to
mentioning, than defining -- and I thought it would fall into memory
easier if the reader could see that "this is actually a Scheme
function indeed". (This won't be obvious during the first reading, so
I think it would be best to put the decision off for now)

4. I don't think that we need to add (line 192) that we mean "the
phenomena in the +real+ world". We could also mean the phenomena in
the world of ideas, or  some fictional world. Either way, this is
unobvious from the philosophical point of view ;]

5. I think you got the "reading programs isn't like reading novels"
(196) opposite to my intention, which was that the programs have a
higher level of generality (which is rather unfamiliar) -- novels are
more concrete and less general.

(I wonder whether we should switch to private correspondence, or
doesn't anyone mind having such updates here?)

> In general, I think Scheme desperately needs an "O'Reilly"-style book.

Sometimes I wonder. On one hand, our community could benefit if Guile
was more fashionable. I think that in practice, our situation is
similar to that of Erlang. Garret Smith (the author of "Erlang The
Movie II: the sequel", the best movie on the whole Internet) said that
"github is the Erlang's package manager" -- which is much more tedious
than, say, pip or ruby gems. And while some implementations of Scheme
provide nice solutions with this regard (most notably Chicken's eggs),
I think that -- similarly to Erlangers -- we mostly need to rely on
the fact that  even if they are complex, well written functional
programs are easy to understand and compose. (This is also why I
thought writing a booklet is better than just publishing those
libraries, because creating them was really effortless. Also, I think
that the kind of software literacy that Scheme promotes is much more
important and far-reaching than even the most complete set of
libraries imaginable)

I think that the problem of Scheme is that it is best characterized
not by what it allows to do, but what it doesn't forbid to do, and
comprehending this "negative" characteristic requires much more
imagination.

> Question: What should we say when someone asks, "Why should I fool with a
> new programming language when there's Matlab/Mathematica/etc.?"

The way I see it, this is a field where there's constant change --
there was Octave, but then R emerged, and now Julia is gaining
popularity.

Certailny, the language itself (Scheme, that is) has been good enough
for at least two decades. What I think is needed is a set of
accessible tools that would provide immediate benefits from the Lisp's
syntax. For instance, Emacs is a really great environment for lispers,
but it is accessible only to those that already know Emacs. The dr
Racket envrionment is way more accessible, but while it's good for
education, I don't think I would want to use it for editing.

I think that LightTable is a very nice tool, but is focused on
Clojure, which is targetted to the JVM platform.

> I think this is a great project. I myself have recently started something
> similar which shamelessly puts coding (in Scheme) together with high school
> math. Two things I want to avoid is 1) having other "blub" languages fill
> this yawning gap (read Python), and 2) helping cushion the computer science
> wall where hot-shot high-school coders go to college, major in comp-sci . .
> . and then hit the comp-sci wall, i.e., discrete math, theory, no more cool
> coding tricks, etc.

Honestly, I think that Python is a very good tool for many practical
applications. I often use it at work, where I wouldn't be able to
convince anyone to use a language with "all those weird parentheses".
On the other hand, I don't think that I would want to build anything
complex or serious in Python, because of its inherent limitations.

I believe is that we could make this cognitive revolution only through
the minds of children, that weren't spoiled by the idea that the infix
notation is natural. Actually I do have an idea for a game that could
teach children programming (and that uses Guile), but it's been almost
a year since I made any greater contributions. The idea is that the
players can control their humanoid avatars in 3d environment, and they
can progress from fully manual control, through automating some tasks
using scripts, to completely autonomous bots.

If you're interested, you can have a look at the presentation that I
made a year ago:

http://link.as/the-pose-editor-videotutorial

Sorry for so many words ;]
and thanks again!

Panicz

An impudent introduction to impudence

[Keith Wright]

Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> (I wonder whether we should switch to private correspondence, or
> doesn't anyone mind having such updates here?)

I would think so.  Thanks for telling us about
this project, it's interesting to read somebody
who cares about writing on a programming list.

For example:

Here are a couple of program/diatribes I have
been working on:

How can literate programming be done in Scheme?
http://www.free-comp-shop.com/pprint.html

Why does a dodecahedron have twice as many faces as a cube? 
http://www.free-comp-shop.com/poly.html

Please email me off list if you want to discuss
spelling, semantics, metaphysics, or geometry.

  -- Programmer in Chief

Re: An impudent introduction to impudence

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

2016-02-08 21:31 GMT+01:00 Keith Wright <kwright@keithdiane.us>:

> Panicz Maciej Godek <godek.maciek@gmail.com> writes:
>
> > (I wonder whether we should switch to private correspondence, or
> > doesn't anyone mind having such updates here?)
>
> I would think so.  Thanks for telling us about
> this project, it's interesting to read somebody
> who cares about writing on a programming list.
>
> For example:
>
> Here are a couple of program/diatribes I have
> been working on:
>
> How can literate programming be done in Scheme?
> http://www.free-comp-shop.com/pprint.html
>
> Why does a dodecahedron have twice as many faces as a cube?
> http://www.free-comp-shop.com/poly.html
>
>
This is exquisite!
I habe been thinking about something similar -- namely an editor that would
allow to typeset the Scheme code according to one's preferences (for
example, arithmetic expressions could be infixed, division could be written
as fractions, (list-ref l i) as $l_{i}$, and so on. I don't think it would
actually be useful, but it could shut the mouth of parentheses-haters
(which isn't particularly motivating though)

Please email me off list if you want to discuss
> spelling, semantics, metaphysics, or geometry.
>
> Oh, I certainly will (in a few days), but I rather hope to discuss
typography, epistemology and dynamic systems :)
Thank you!

[-- Attachment #2: Type: text/html, Size: 2178 bytes --]

Re: [ANN] An impudent introduction to Guile

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Feb 08, 2016 at 08:58:41PM +0100, Panicz Maciej Godek wrote:

[...]

> (I wonder whether we should switch to private correspondence, or
> doesn't anyone mind having such updates here?)

Just lurker here, so weigh my vote accordingly. But I'm desperately
setting aside some quality time to read the introduction (and very
much looking forward to it).

I'm following this back-and-forth with much interest, so as far as
I'm concerned, please stay here :-)

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAla5oscACgkQBcgs9XrR2kauKACfZwZy1ysbHCAMfdpYkIkCeudg
gEMAnRAk6eFrzXZUqYuLOfYIC0g4VaLS
=BV88
-----END PGP SIGNATURE-----

Re: [ANN] An impudent introduction to Guile

[Lawrence Bottorff]

[-- Attachment #1: Type: text/plain, Size: 6739 bytes --]

Good, good.

On Mon, Feb 8, 2016 at 7:58 PM, Panicz Maciej Godek <godek.maciek@gmail.com>
wrote:

> 2016-02-07 22:51 GMT+01:00, Lawrence Bottorff <borgauf@gmail.com>:
> > I've got this <https://github.com/borgauf/pamphlet> fork going where
> I've
> > done some editing (grammar, style, spelling, etc.) on the book (up to
> > "Reporting bugs." Let me know what you think.
>
> I'm really impressed! Thanks! :)
> However, I do have some remarks:
>
> 1. if possible, it would be nice if you could keep the lines up to 80
> columns each (60 columns is preferable). I do editing in Emacs in
> terminal on a very tiny display and I often split the screen in two
> halves for comparatory editing.
> The only exception are links that are more than 80 columns long.
>
> 2. in the line 161, you expanded the sentence "The first chapter
> introduces all the elementary notions needed for programming" with the
> adverbial "in Scheme". My original intent was that -- although the
> syntactic guise of the programs expressed is obviously Scheme -- the
> presented notions (of definition, reduction and substitution) are
> required to do programming in general.
>

corrected


>
> 3. I'm not quite convinced whether \texttt{equivalence-classes} should
> be replaced with \textit{equivalence-classes}. If we actually decide
> to do so, I think it would be better to replace it as
> \textit{equivalence classes}. However, although the italics are
> actually used to refer to new notions, and typewriter font to refer to
> notions/functions defined in Scheme, that use case is closer to
> mentioning, than defining -- and I thought it would fall into memory
> easier if the reader could see that "this is actually a Scheme
> function indeed". (This won't be obvious during the first reading, so
> I think it would be best to put the decision off for now)
>

good . . . it's just that it bleeds into the margin (on your original pdf)
. . . any way to correct that?


>
> 4. I don't think that we need to add (line 192) that we mean "the
> phenomena in the +real+ world". We could also mean the phenomena in
> the world of ideas, or  some fictional world. Either way, this is
> unobvious from the philosophical point of view ;]
>

I didn't change this? But looking at it I'd say ". . . Internalizing a
definition is not always a
pleasant task, because it requires the intellectual effort of focusing and
remembering." (*the *instead of *an*)


>
> 5. I think you got the "reading programs isn't like reading novels"
> (196) opposite to my intention, which was that the programs have a
> higher level of generality (which is rather unfamiliar) -- novels are
> more concrete and less general.
>

Changed it to  ". . . Because of their familiar narrative specificity, we
typically absorb stories almost effortlessly."


>
> (I wonder whether we should switch to private correspondence, or
> doesn't anyone mind having such updates here?)
>
> > In general, I think Scheme desperately needs an "O'Reilly"-style book.
>
> Sometimes I wonder. On one hand, our community could benefit if Guile
> was more fashionable. I think that in practice, our situation is
> similar to that of Erlang. Garret Smith (the author of "Erlang The
> Movie II: the sequel", the best movie on the whole Internet) said that
> "github is the Erlang's package manager" -- which is much more tedious
> than, say, pip or ruby gems. And while some implementations of Scheme
> provide nice solutions with this regard (most notably Chicken's eggs),
> I think that -- similarly to Erlangers -- we mostly need to rely on
> the fact that  even if they are complex, well written functional
> programs are easy to understand and compose. (This is also why I
> thought writing a booklet is better than just publishing those
> libraries, because creating them was really effortless. Also, I think
> that the kind of software literacy that Scheme promotes is much more
> important and far-reaching than even the most complete set of
> libraries imaginable)
>
> I think that the problem of Scheme is that it is best characterized
> not by what it allows to do, but what it doesn't forbid to do, and
> comprehending this "negative" characteristic requires much more
> imagination.
>
> > Question: What should we say when someone asks, "Why should I fool with a
> > new programming language when there's Matlab/Mathematica/etc.?"
>
> The way I see it, this is a field where there's constant change --
> there was Octave, but then R emerged, and now Julia is gaining
> popularity.
>
> Certailny, the language itself (Scheme, that is) has been good enough
> for at least two decades. What I think is needed is a set of
> accessible tools that would provide immediate benefits from the Lisp's
> syntax. For instance, Emacs is a really great environment for lispers,
> but it is accessible only to those that already know Emacs. The dr
> Racket envrionment is way more accessible, but while it's good for
> education, I don't think I would want to use it for editing.
>
> I think that LightTable is a very nice tool, but is focused on
> Clojure, which is targetted to the JVM platform.
>
> > I think this is a great project. I myself have recently started something
> > similar which shamelessly puts coding (in Scheme) together with high
> school
> > math. Two things I want to avoid is 1) having other "blub" languages fill
> > this yawning gap (read Python), and 2) helping cushion the computer
> science
> > wall where hot-shot high-school coders go to college, major in comp-sci
> . .
> > . and then hit the comp-sci wall, i.e., discrete math, theory, no more
> cool
> > coding tricks, etc.
>
> Honestly, I think that Python is a very good tool for many practical
> applications. I often use it at work, where I wouldn't be able to
> convince anyone to use a language with "all those weird parentheses".
> On the other hand, I don't think that I would want to build anything
> complex or serious in Python, because of its inherent limitations.
>
> I believe is that we could make this cognitive revolution only through
> the minds of children, that weren't spoiled by the idea that the infix
> notation is natural. Actually I do have an idea for a game that could
> teach children programming (and that uses Guile), but it's been almost
> a year since I made any greater contributions. The idea is that the
> players can control their humanoid avatars in 3d environment, and they
> can progress from fully manual control, through automating some tasks
> using scripts, to completely autonomous bots.
>
> If you're interested, you can have a look at the presentation that I
> made a year ago:
>
> http://link.as/the-pose-editor-videotutorial
>
> Sorry for so many words ;]
> and thanks again!
>
> Panicz
>

[-- Attachment #2: Type: text/html, Size: 8981 bytes --]

Re: [ANN] An impudent introduction to Guile

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

:)

2016-02-09 19:41 GMT+01:00 Lawrence Bottorff <borgauf@gmail.com>:

> Good, good.
>
>
>> 3. I'm not quite convinced whether \texttt{equivalence-classes} should
>> be replaced with \textit{equivalence-classes}. If we actually decide
>> to do so, I think it would be better to replace it as
>> \textit{equivalence classes}. However, although the italics are
>> actually used to refer to new notions, and typewriter font to refer to
>> notions/functions defined in Scheme, that use case is closer to
>> mentioning, than defining -- and I thought it would fall into memory
>> easier if the reader could see that "this is actually a Scheme
>> function indeed". (This won't be obvious during the first reading, so
>> I think it would be best to put the decision off for now)
>>
>
> good . . . it's just that it bleeds into the margin (on your original pdf)
> . . . any way to correct that?
>

Now I see. I think we would need some TeXpErT to have a look. Or perhaps it
would look nicer if a space was inserted before the dash, i.e.
\texttt{equivalence -classes}. Or maybe it's not worth the trouble and your
soltion with \textit is satisfactory.


5. I think you got the "reading programs isn't like reading novels"
>> (196) opposite to my intention, which was that the programs have a
>> higher level of generality (which is rather unfamiliar) -- novels are
>> more concrete and less general.
>>
>
> Changed it to  ". . . Because of their familiar narrative specificity, we
> typically absorb stories almost effortlessly."
>

This seems fine :)

Thank you

[-- Attachment #2: Type: text/html, Size: 2792 bytes --]