Re: Request for feedback on SRFI-126

[Arne Babenhauserheide <arne_bab@web.de>]

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

Am Mittwoch, 30. September 2015, 08:39:44 schrieb Panicz Maciej Godek:
> > > 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.

Do you see wisp as community pressure on Scheme implementations?

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

I’ll cheat a bit here and pull your later answer:

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

If you do that, you essentially have wisp. Being as close as possible
to Scheme with just leaving out the parens you can infer from
indentation is the core design principle of wisp.

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

That’s completely, totally true.

Guile itself provides almost its full support when you’re using wisp,
but the tool support is much weaker. The Emacs mode for wisp is much,
much weaker than Geiser and there are no syntax highlighters in any
code hosting service, and that doesn’t even start with external code
analysis tools.

But you can already do stuff like this:
http://draketo.de/english/wisp/shakespeare

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

Let’s do that by example:


define : hello world
  format #t "Hello ~A!\n" world

hello "World"


Recognizing the structure isn’t the problem. Tool support is a
problem. And integration. And documentation. And so on. It is unlikely
to be the best system for all kinds of hacking. But it might be a
pretty good system for some tasks. And when you program in wisp, going
to standard Scheme is really easy. You already know all the
functionality, the structures, the libraries and so on.

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

You’re talking about editing right now. I explicitly talked about
reading, not about editing.

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

Replace Java with Python, and that still fits. Python even has flake8
for Emacs which checks for you whether you are following the canonical
path. And people do that intentionally. I know I do.

But there’s a reason why I started into Scheme.

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

Sure, but that’s not what I would compare it to. I’d rather compare it
to the situation with C and Fortran. Porting a big codebase from one
compiler to the other takes some time, but once you did it, the code
works on both compilers. And you can quite easily write code which
works for both compilers. There will be minor glitches, but most
things will just work.

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

I can work with that ☺

Best wishes,
Arne
--
singing a part of the history of free software: 

- http://infinite-hands.draketo.de


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 299 bytes --]