Thanks for the opinions, Dinosawer and fvirexi. This stuff deserves a good, in-depth discussion with everybody's views reflected now, because we're going to be living with it for a long time.
(Also, thanks for not ninja-ing me, Josh.
This is about the limit of the guesswork and opinionizing I can do on this subject, anyway, so I'll try to hold off on further extended comments until you've had a chance to mull things over.)
INDENTATION-AS-CONTROL
When I mentioned scoping characters (such as { and }), I specifically called them "syntactic information" and "control information." That is, they're not just there for readability; they are supplying specific functional structure that determines the processing logic (as well as parameter control in that context). The question is what is the better way of supplying that information to the interpreter.
My view remains that an explicitly typed and visible character will be superior in the long run for a working programmer.
It's not that you
can't do that with indents. Obviously you can. The question is whether one
should do it.
Let's take your code example again. I've been a working programmer for many years. But even in the days of 80-column displays I never used either K&R or 1TBS; I've always used the Allman style because it provides maximum clarity for scoping:
Code: Select all
if(thirsty)
{
if(largebottles)
{
buy(largebottle);
}
else
{
for(int i=0;i<10;i++)
{
buy(smallbottle);
}
}
else
{
eat(chocolate);
}
Even without indentation, that style makes it pretty clear -- more so than the examples you gave -- how the flow of control moves through this code.
Indentation certainly improves readability. That why I indent, in addition to specifying the required braces. But formalizing indentation so that it provides actual syntactic utility... I'm not convinced that this feature will be desirable in practice.
Basically it comes down to the practical requirement of being able to read, understand, and debug code that someone else wrote, or that you wrote long ago. Once you get past algorithm design, "programming" is about poring over a complex chain of instructions, trying to understand why it's not doing what you thought you told it to do. I believe programmers get clearer information about the scope-of-control part of this process from an explicitly visible character (such as a brace) than from any
absence of characters (such as indentation from spaces or tabs).
So here's the bottom line:
I think programmers can see more quickly whether a syntactic or semantic error is due to the existence or placement of scope-control characters -- a literal visible character -- than they can see whether a line is too far left or right. A programming language ought IMO to be designed to make this understanding easier to obtain for the working programmer, regardless of any theory about simplifying lexical steps or not looking like some other language. (I'm not implying either of these motivated Josh; this is a general statement about language design.)
I'll also note that brace-counting for syntactic correctness is a lot easier for an editor to help with than trying to guess what indentation level you really wanted for a line of code. Seeing something that is visibly there -- as opposed to what's not there -- is always going to be easier for the vast majority of human beings. We're just wired that way. (See
Bastiat.)
Some of this may come down to what one was taught or has used. I don't discount that. But I can't speak to it because I assume we're all subject to it. So I'm focusing instead on what I perceive to be the actual functional effects on working programmers of these two approaches.
On that basis, I think specifying scope control information through explicit characters, rather than through implicit spacing, makes programming a little easier for people just trying to convert a neat idea into code.
PREFIX VERSUS INFIX NOTATION (OPERATORS-AS-FUNCTIONS)
I'm not going to argue this one as strenuously. I don't care for prefix notation, and I maintain that infix is easier for most people to understand (even if that means a compiler/interpreter has to do some extra lexical work).
But I think I can see how this choice -- that operators are actually functions -- is more integral to Josh's concept of UDF (or LTSL, as it seems we can now call it!). So while I persist in thinking that LTSL will be easier for modders to use if operators are implemented as operators, allowing the use of infix notation, I'm not going to spend a lot of time arguing it because I have a feeling this one is set in stone.
I would still enjoy a better understanding of "why try to dispense with scope/parameter characters?" though. Getting rid of those seems to be the driver behind both the operators-as-functions and indentation-as-control design choices for LTSL. Why is that a desirable/necessary goal?
Finally:
fvirexi wrote:Is the language going to have macros? If so, then all syntactic matters can be solved to some degree.
I thought of that, too.
It would appear to be a way to let everybody have what they want.
The problem with it (beyond meaning that Josh would need to implement that functionality) is that the non-macro versions would still be there. People would use them, so the folks who prefer the macro versions would still have to understand this code in order to modify it. That's extra work, not less work.
Conversely, those who do use macros to put the syntax in a more comfortable form would be writing code that would force others to have to obtain and apply those macros. And again, that's an extra step, when modding can already be hard enough. It would probably put some people off from improving otherwise valuable mods.
So I think, on balance, it's better to think about making vanilla LTSL maximally usable by as many potential modders as possible. That's just my opinion, though; if anybody wants to talk about a macro facility for LTSL, there's plenty of room here in this new sub-forum for that thread.