For the sake of discussion, here’s a long rant: I might have a very uninformed opinion here, but wouldn’t having significant white space and no scope-defining character amount to multiple spaces and line feeds being part of the syntax? The next best thing being, allowing semicolons in place of line feeds. I’m no language designer, so let me try to give you my perspective as an average programmer:
I find editing Python and Haskell a pain, because of white spaces. I can’t count the times I got that dreaded ‘invalid indentation’ error, because I’m editing code with a different editor on a different system. I also had to reformat entire programs after somebody saved using the incorrect tab setting, and I avoid Python because of this. Yet I haven’t heard this complaint from Python programmers, so I always believed I was just too dumb. I haven’t seen a better solution than s-expr to make expressions and scope ultra-visible and easy to manipulate. Yet s-expressions still bring their own requirements for comfortable editing: most people still require a specialized editor or a plugin for lisps. I fact, is there any language that doesn’t require some sort of plugin or specialized editor to be attractive to new programmers? Thinking of it, isn’t the IDE almost as important as the syntax or the language these days? Some JavaScript programmers can’t work without VSCode, scope-sensitive autocomplete, a linter and god knows how many other plugins. PHP programmers also feel naked without a fancy IDE and a host of plugins. I keep hearing people complain about x or y language because it doesn’t have a good editor, IDE or plugin for VSCode. Globally, people use more and more tools to program in the same languages. That’s what turned me into a sort of ‘digital minimalist’. I take comfort in not being dependant on anything other than a compiler/interpreter and a simple editor I can whip out of any system in seconds. I think there’s value in reducing our dependencies, including on tools, editors, IDEs and plugins. That being said, I love DrRacket and its facilities, also because it’s self-contained and bundled with Racket. One less thing to install. These are the considerations I’d take in account when thinking of a new syntax. Still, like I said before, I’m excited by the fact that the Racket team is looking for a solution to this problem, and I’ll be the first to applaud a way to keep the next Racket expressive and powerful, while making it more attractive to people used to more familiar syntax. Parentheses are, and always will be a barrier to entry for potential Racket adopters, and this is no small matter. I think Julia is a good example of the right balance between simple, attractive syntax and power. Are there downsides to their approach? Cheers, Dex > On May 2, 2020, at 2:12 AM, George Neuner <gneun...@comcast.net> wrote: > > > On 5/1/2020 4:35 PM, Dexter Lagan wrote: >> 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'm not really sure what Pike is getting at there: I haven't used SWIG > myself, but if I understand it correctly, Python code would have to be in a > module to be called from "other" language code. If so, I don't see how the > indentation of the "other" code could affect the Python. > > That aside: > > Even working only in Python, programmers routinely get tripped up by > copy/paste errors - so it is evident that indentation sensitivity is not any > real solution to scope related logic problems. It might [for some > definition] help newbies identify stupid errors, but I believe that even > moderately experienced programmers are more hindered than helped by it. > > >> 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? > > Well, few people use Haskell, so I would discount it as a data point. Even > so, one of the tutorials includes this interesting tidbit: > > With good text editor, programming is fun. Of course, you can get along with > simplistic > editor capable of just cut-n-paste, but good editor is capable of doing most > of the chores > for you, letting you concentrate on what you are writing. With respect to > programming > in Haskell, good text editor should have as much as possible of the following > features: > > • Syntax highlighting for source files > • Indentation of source files > • Interaction with Haskell interpreter (be it Hugs or GHCi) > • Computer-aided code navigation > • Code completion > > The implication is that Haskell is difficult to write without proper editor > support. So too is Python. Decent syntax and structure aware editors are > not really a problem any more, but they can go only so far: they can fail > spectacularly when code gets complicated and the language syntax provides no > clues to figure out the scoping. > > S-exprs do not suffer from this affliction. > > > Also mentioned previously is my concern that indentation sensitivity may make > implementing macros as we enjoy them in Racket difficult. Or maybe > impossible. Although certainly there are indentation languages which have > macro facilities, I am not aware of any in which the macros can be written in > the same language. All the ones I know of implement a separate DSL macro > language. > > I have designed and implemented a few languages: including a Scheme-ish > mostly functional language [but lacking macros]. I have not thought through > all the nuances of implementing a language that can reflectively manipulate > the structure of a program in the midst of compiling it [or in the case of > Lisp - running it]. However, I have to think there are reasons for existing > indentation languages not having done so. > > YMMV, > George -- 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/121F40A4-DCF2-47C7-9053-B38D9724C7B2%40gmail.com.
