Re: Request for feedback on SRFI-126

[Arne Babenhauserheide]

Am Mittwoch, 30. September 2015, 01:02:50 schrieb Panicz Maciej Godek:
> 2015-09-29 22:05 GMT+02:00 Arne Babenhauserheide <address@hidden>:
> > I wrote SRFI-119, not because I want Scheme to become more like
> > Python, but because I want it to *look* more like Python while
> > retaining its strengths.

> If you asked me, I'd say that if people started using that SRFI (or the two
> others), then it would be most harmful to the Scheme community, because
> that would increase code enthropy and force programmer to make an
> irrelevant choice.

It’s no more irrelevant than the choice between Guile and Racket. And
different from that choice, it’s trivial to change:

    for i in *.w; do guile wisp.scm $i > $(basename $i .w).scm; done

> It also sacrifices some of the strengths of Scheme, actually, because it
> makes the code structure obscure.

I disagree on that. The structure is still just as easy to recognize
as with parens: Even with parens the strongest indicator of the
structure is the indentation. It keeps the effects of inline-colons
limited to one line to avoid the need to do any complex mental
parsing: If there’s a colon in a line, the paren it opens gets closed
at the end of the line.

> The same goal could better be achieved (non-intrusively) by making an easy
> to use editor that would allow to display your Scheme code in the way you
> prefer, be it Python-style indentation or some fancy LaTeX formatting.

I consider it as problematic when programming languages need strong
tool support to be easy to read. With the right tools, even Java is
nice to use.

Changing indentation sensitive code needs some tool support to be
elegant, but that is available in most editors, but reading does
not. And I’ve been stuck in too many github diffs to consider that as
a solved problem :)

> > It isn’t necessary to sacrifice the strengths of Scheme to become as
> > easy for new programmers as Python. However it does require accepting
> > that a large part of the utility of any language lies in its
> > libraries: The best language for any job is the one which provides the
> > solution off-the-shelf.
> 
> Fine. But I don't find it disturbing that this "useful language with tons
> of great libraries" is called Racket or Guile, rather than Scheme.

This week a Freenet user wrote a client to Freenet in Racket. I wanted
to use it for Guile, but since I didn’t really know the capacities of
Racket, I didn’t know how to replicate them in Guile. I asked the user
whether he/she could port to Guile and after a few days he/she
published a Guile version but stated that it did not work yet. One
hour of fixing later I had it running.

Why I write that: For large projects it might be relatively easy to do
the conversion, because the compatibility layers are only a small part
of the total code base. The saved time by reusing existing code is
much larger than the time spent doing the compatibility stuff. For
small projects, it can be a blocker. You can’t spend a few days
waiting and 1 hour porting for programs which just take 4 hours to
write. Or rather: You can’t do that if you need to combine many small
projects into a bigger whole.

> I will agree with you if you show me one example of successful deployment
> of Guile or Racket. Like, Python has some impressive tools like Django or
> Enaml.

Can you give me clear criteria for when you would consider a
deployment as successful?

> > But someone has to actually do that: Creating libraries with
> > consistent style which provide to the application developer what
> > Scheme already provides to the language developer.
> >
> 
> I agree. But from my experience, in order to make a useful library, it is
> best to work on some real applications.

I agree.

> I think it is actually reasonable to think that the power of a programming
> language manifests itself in the applications that are written in that
> language.

I agree, too.

So our viewpoints don’t seem to be that far away from each other :)

Best wishes,
Arne

signature.asc
Description: This is a digitally signed message part.