On 5/2/2020 4:58 AM, Dexter Lagan wrote:
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.
Python is as much a cult as a programming language.
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?
For most languages, IDEs are mainly needed for debugging. For just
editing, the majority of languages really don't need syntax or structure
awareness. Syntax coloring is nice, but programmers got along fine
without it for ~50 years.
Most languages in use now have syntax based (however loosely) on C and
mostly are not WS sensitive. The compiler doesn't care about how the
code is formatted: there is a statement terminator (or separator [there
is a difference]) character that serves to keep the compiler
synchronized with the source.
In Pascal, you can write an entire program on a single edit line. In C
and C++, the preprocessor is line sensitive, so it isn't possible to
write a whole program in one line - but the mainline code is WS
indifferent, and you can write entire functions, or even multiple
functions, in one line.
But no one does that except in those competitions trying to pack a whole
program into 255 characters or less.
For most languages it is visual debugging: tracing and breaking
execution, probing runtime values, while seeing the source ... *that* is
where an IDE comes into its own.
S-expr languages are different in this respect because they are
expression based rather than statement based. Expressions can be nested
arbitrarily, and it is more difficult to visually identify things
without some editor assistance like coloration, parenthesis matching,
and syntax directed indentation.
S-expr languages have long used - though not required - indentation as a
guide to visualize program structure. When you program with Racket (or
Scheme or Lisp) for a while, you cease to see the parentheses and really
mostly see only the indentation structure.
For debugging: tracing and breaking S-expr code is more complicated to
*display* and interact with reasonably - the UI matters greatly to
programmer efficiency. But the actual debugger internally is not really
much different from a debugger for a statement language - it's mostly
how the programmer interacts with it that needs to change.
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.
Programmers today are spoiled. My first program was written on a
teletype connected by modem to a PDP-10 at some nearby college. It took
half an hour to get a 10 line program working.
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?
Julia is interesting, but I confess, I don't know it as well as I
probably should. It claims to have reflective macros, so that would
make it a data point in favor of a non-S-expr syntax.
But one thing I'm not a fan of is cluttering source with compiler
directives. Julia uses directives rather liberally to control threading,
and I find that distracting. 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/cdfca9c9-b6d5-7cc5-2aa6-f9ef4d3ee928%40comcast.net.
