I haven't followed all the discussion regarding a potential successor to
Racket. AFAIHS, no one actually has suggested a required indentation
scheme ala Python, but since source indentation (and formatting in
general) currently is under discussion, I wanted to make known my
feelings on the matter.
If you don't feel strongly about source indentation, you can skip this.
George
On 5/1/2020 1:19 PM, Christopher Lemmer Webber wrote:
Sorawee Porncharoenwase writes:
>
>> I hate being at the mercy of whatever editor I'm stuck using.
>
>
> I agree with this in principle, but in practice, it's really a matter of
> what mainstream editors support. Editors in the past don't universally
> support automatic indentation, and I could imagine a criticism like
> "Indentation sucks, because I hate being at the mercy of whatever editor
> I'm stuck using." But now, automatic indentation is universal, and the
> criticism goes away.
You don't even need to imagine it... when Python was taking off, one of
the biggest arguments was that it forced people to learn to do
reasonable indentation. Doesn't seem like as much of a good argument
now as I thought it was then, and that's partly because most code is
indented fine these days due to, as you say, good IDE support.
The indentation requirement - aka "significant whitespace" - is one of
the main things I dislike about Python [the other is its comprehension
syntax]. An argument certainly can be made for advocating a readable
coding style ... but on principle I disagree with a language *requiring*
any particular style.
As it happens, I am old enough to remember when Fortran required very
particular formatting: worse even than Python, Fortran was designed
around 80-column punch cards, and for a VERY long time it was necessary
that particular things be placed in particular columns ... else the
statement would not compile.
see https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html
Fortran's adherence to rigid source formatting really did not simplify
the compiler much at all (actually an argument can be made that it
unnecessarily complicated recognizing certain constructs). And if it
ever helped, it wasn't necessary for long - by 1962 [Fortran was
introduced in 1959] compilers were able to deal with free form code.
The first version of Lisp [1961] was on punch cards as well, but from
the beginning Lisp never had column based restrictions on source format.
Fortran ... still recognizes the old style, but ... no longer requires
column based formatting. Free form source has been supported by
compilers since Fortran90.
Historically, there have been a handful of (higher level, non-assembly)
languages that had odd source formatting requirements, but none were as
onerous as Fortran, and none of them survived very long. But just as
Fortran finally was giving up on the idea, Python came along to revive
it. [Python began at about the same time Fortran90 was in committee.]
Forcing programmers to do menial tasks like configuring editors to
certain modes [spaces vs tabs], and to manually count spaces when
corresponding scoped lines are too far apart to eyeball the vertical
alignment is simply counterproductive - there are plenty of more
important things that programmers should be worrying about. Programming
editors having language structural awareness have been around since the
80's ... there is no reason ever to bake such things as indentation
requirements into the language.
Just my 2 cents.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/e180703e-6e2e-ea6b-d918-b46ff4eebb07%40comcast.net.
