Is there value in Rob Pike’s comment on avoiding significant white space in 
the Go language?

“We have had extensive experience tracking down build and test failures caused 
by cross-language builds where a Python snippet embedded in another language, 
for instance through a SWIG invocation, is subtly and invisibly broken by a 
change in the indentation of the surrounding code.” — Rob Pike, 2012

  I personally dislike white space and prefer either mustaches or parenthesis, 
just so I know my code will still work if line feeds are stripped somehow, or 
that some piece of code is embedded or quoted in another language, which is 
what I gather Rob was talking about. However, Haskell and Python people don’t 
seem to mind, and if it saves us more keystrokes while keeping expressiveness, 
why not?

Dex

> On May 1, 2020, at 10:20 PM, George Neuner <gneun...@comcast.net> wrote:
> 
> 
> 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.

-- 
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/CF6238ED-5C9D-49DE-B400-872E9DB69271%40gmail.com.

Reply via email to