2015-09-30 1:44 GMT+02:00 Arne Babenhauserheide : > Am Mittwoch, 30. September 2015, 01:02:50 schrieb Panicz Maciej Godek: > > 2015-09-29 22:05 GMT+02:00 Arne Babenhauserheide : > > > 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 :)