2015-09-29 22:05 GMT+02:00 Arne Babenhauserheide <arne_bab@web.de>:
Am Montag, 28. September 2015, 22:02:42 schrieb Panicz Maciej Godek:
> Even within the Scheme community there appear voices complaining on the
> Lisp syntax, like SRFI-105, SRFI-110 or SRFI-119.

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 also sacrifices some of the strengths of Scheme, actually, because it makes the code structure obscure.

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.

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.

SRFIs could give Scheme such solutions, and
the flexibility of Scheme would allow making these solutions much more
elegant than what can be created with Python.

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.

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