Re: Request for feedback on SRFI-126

[Panicz Maciej Godek]

2015-09-30 1:44 GMT+02:00 Arne Babenhauserheide <address@hidden>:

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.

No. Guile and Racket are both experiments. I think it was a good move on Racket's side that they proclaimed that they are a separate programming language, because that way they manage to avoid bad community pressures like this.

 

And different from that choice, it’s trivial to change:

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

Converting strange syntax to Lisp is essentially what parsing does.

Yet you loose a lot of support from your tools if you miss the assumptions that they were made upon.

 

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

It is easy for you, because you're inveted it. For everyone else it's just another thing they'd need to learn in order to read the code. They'd need to remember all the assumptions you've made.

 

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

Raise your hands all those who don't use emacs to write their Lisp code.

Raise your hands all those who don't use geiser to interact with Guile.

I honestly think that, however clever Lisp is, it would be rather painful to edit it without proper tools. Even the aforementioned 'wisp.scm' is a tool.

Regarding Java, I think its tools have the same problem the language has, i.e. everything is fine as long as you stick to the path that their developers chose for you.

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

This is the reason why emacs indents lisp code. This is the part of Norvig's comparison that I particularly like:

"One of Python's controversial features, using indentation level rather than begin/end or braces, was driven by this philosophy: since there are no braces, there are no style wars over where to put the braces. Interestingly, Lisp has exactly the same philosphy on this point: everyone uses emacs to indent their code, so they don't argue over the indentation. Take a Lisp program, indent it properly, and delete the opening parens at the start of lines and their matching close parens, and you end up with something that looks rather like a Python program."

 

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

The same is true if you try to port e.g. PHP code to Guile, but then it only gets more difficult

 

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

Well, that would be a little vague, but my first shot would be that it runs an app that makes money to anyone.

 

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

Cool :)