Return to “Scripting & Modding”

Post

Re: UDF - The LT script language

#16
fvirexi wrote: On a side note: what does UDF stand for? I agree it could benefit from a new name. Mcsven's LTSL sounds like GLSL, appropriate because Josh seems to be really into shaders, and uses OpenGL :D
Personally, I like names less acronymic. What about "Limitless, the language" (.lim as the extension)? Opening up the game for modding makes it easier to expand beyond its original limits, and the language is probably Turing-complete, so there's another kind of limitless. Even with other names, I vote for .lim as the extension, the mathematical shorthand for limit. :geek:
UDF stands for Universal Data Format. For that reason, I think I prefer LTDL over LTSL, because Limit Theory Data Language makes a lot more sense than Limit Theory Scripting Language, especially considering what we're dealing with. I agree that UDF doesn't really help tell you what it is.

.lim sounds good to me, honestly. I'll be honest, though - I don't really care for "Limitless, the language". :P

Welcome to the forums, by the way! :wave:
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: UDF - The LT script language

#17
Talvieno wrote: UDF stands for Universal Data Format. For that reason, I think I prefer LTDL over LTSL, because Limit Theory Data Language makes a lot more sense than Limit Theory Scripting Language, especially considering what we're dealing with. I agree that UDF doesn't really help tell you what it is.

.lim sounds good to me, honestly. I'll be honest, though - I don't really care for "Limitless, the language". :P
No worries. I realized after I posted, "limitless" might sound a) bit too pretentious and ambitious about the scope of the language (and the language itself is not the focus), and b) not really fitting a language anyway. Still going to hope somebody comes up with a great idea for a non-acronymic name, but as its not a general purpose language, LTDL does make much more sense, I must admit.
Post

Re: LTSL - The LT script language

#20
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. :lol: 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. ;)
Post

Re: LTSL - The LT script language

#22
mcsven wrote:Flat, I don't really get where you're coming from on this. Hasn't this all been thrashed through massively as a result of Python's growing popularity... and the result is unanimously in Python's favour when it comes to readability?
No.

:)

Obviously there's not unanimity on this question. Nor (not that I should have to say this) is popularity any guarantor of quality or correctness.

If namechecking ESR feels like a sufficient response to the questions and reasons I've taken the time to provide, OK. I think his experience as a programmer (as he described in Why Python) is substantially broader than that of a lot of people who will want to mod LT using LTSL. So I would hesitate to substitute his personal reaction to whitespace-for-scoping as a measure of how well that will work for normal human beings who are trying to "think in code," any more than I'd say something must be right for everybody just because I like it.

Reason is more persuasive than arguments from authority.
Post

Re: LTSL - The LT script language

#23
Well, I still disagree. In your example I have to spend time matching brackets to know what else belongs with what if, whereas with indentation I can see it in an instance. The {} don't serve any informational purpose for me personally, there just something I have to use to make the computer understand the algorithm I have in mind. The program I have in mind is based on logic, not on individual characters.
Furthermore, Python is widely regarded as a very easy language to learn for people learning to program.
Maybe I haven't programmed enough yet to be a real programmer though. :) But on the other hand, wouldn't that make me part of the target audience, in fact?
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
Post

Re: LTSL - The LT script language

#24
I was joking about Raymond, and it was the article you linked that I was thinking about. I should've gone with a smiley. :)

That said, is there anything other than arguments from authority on this issue? The reasoning you have presented so far has been mostly assertions about legibility and ease of debugging, yet these are surely countered simply by saying that I think the opposite. We're not much further forward.

On the other hand, my invocation of Python was because it stands as the most obvious proxy for mandatory indentation and is widely held to be one of the most readable (and writable) languages. It's relatively easy to find things like this, for example. Whilst there are obviously many factors at play here, the control syntax is clearly a substantial component of what gives the language these properties.

Ultimately I just didn't think using indentation for a scripting language would be controversial because Python has demonstrated it to potentially be a good thing and it's not hard to find corroborating opinions for that view.
Post

Re: LTSL - The LT script language

#27
Flatfingers wrote:
1. This at first looked to me like operator-precedence based on prefix notation. I have never thought prefix notation was the best choice in any programming language. Programming languages ought to be designed to be easy for humans to read and write, not to be easy for computers to parse. That means infix notation, even if it requires some syntactic sugar.

I am considering whether implementing operators as functions satisfies that goal. Right now I'm thinking "not so much." It's certainly LISP-like, but is LISP really all that readable even if you invent special new rules to avoid parentheses? I also question the real-world utility of imposing the lambda formalism in what I assume is meant to be a comprehensible scripting language, given that more-or-less normal human beings -- i.e., not recent Computer Science graduates -- will want to use the LT scripting language to tweak the game. Simpler for users is better, regardless of perceived theoretical elegance behind the scenes.
Absolutely agree. :thumbup:
Flatfingers wrote:
2. The use of visual formatting to express functional and parametric scoping... I just don't know about this. It has the feel of straining to dream up an alternative to parenthesization. Why? What is so bad about parentheses that justifies trying to find a way to avoid them?

I also note that using written parentheses as syntactic elements is consistent with how other syntactic information is encoded in most programming languages, including the rest of UDF. All other control statements are expressed as written characters. Using indentation to impose scoping effects breaks that consistency; it requires programmers to encode control information in two different ways. That's not impossible; my question is whether it's desirable since less consistency = more complexity... and correctly specifying code to do a particular thing is already complicated enough.

Finally, there are numerous practical questions for getting indentation right. How much is sufficient? One space? Two? Four? Can they vary between scripts, or within one script? Will a tab character work? I'm not about to change my preferred text editor to vim or anything else just because it can be told to help with indentation, so how hard am I personally going to have to work to make absolutely sure that every line in a long script lines up perfectly to achieve correct scoping? When my time is better spent thinking at a semantic level, how is fussing over indentation better (or faster) than typing a single visible character that 1:1 encodes for "start new scoping"?
I'm kinda torn on this one. While I love Python's common sense approach with data types and parentheses, my old-school Java love has inculcated an appreciation for parentheses and an ease of understanding that is not present with indentation. Though I believe that is a preference issue, as people comfortable with Python would've no problem with the visuals of the code as it stands.
Flatfingers wrote:
3. Regarding the use of what looks like strong typing: what are the core pre-defined types? How are new complex types defined? How are type conversions handled?
More info on this would be great. One of the reasons I love Java is the ability to create new data types as classes.(Though I see that won't be possible with LTSL.)
Post

Re: LTSL - The LT script language

#28
Dinosawer wrote:Python is widely regarded as a very easy language to learn for people learning to program.
Maybe I haven't programmed enough yet to be a real programmer though. :) But on the other hand, wouldn't that make me part of the target audience, in fact?
Regarded as such by the people who've learned it as their first/primary language, I assume? ;)

That's not me taking a shot; I don't say it in an entirely negative way. It's a completely natural human thing, once we've been taught some particular skill and have invested time and effort into becoming good at it, to defend it. I don't fault people for that. I do, however, think (hence the qualifier "entirely" above) that people ought to be aware of this tendency and be open to both the possibility that there's something better and that some existing thing is pretty good and a replacement is not actually better just because it's newer. Neither of those is a good way to assess the value of anything -- for that, you need to consider actual functional qualities.

That's what I've been trying to do.

That said, I've obviously made "easy for lots of people to use" my touchstone for thinking about LTSL's design. If most people who'll want to mod LT only know Python, then by my own requirements I'd have to ease up some on my disagreement over using indentation to provide control formatting. That won't persuade me at a functional level that it's better for the larger set of working programmers (for the reasons I've given) than explicit scoping characters. But I'm trying to be consistent.
mcsven wrote:I was joking about Raymond, and it was the article you linked that I was thinking about. I should've gone with a smiley. :)
I actually suspected that might be the case. Subtlety can be hard to pick up on sometimes, especially as conversations veer into religious war territory. Mea culpa.
mcsven wrote:That said, is there anything other than arguments from authority on this issue? The reasoning you have presented so far has been mostly assertions about legibility and ease of debugging, yet these are surely countered simply by saying that I think the opposite. We're not much further forward.
That's a fair point. Citing my own experience doesn't feel like an "ESR says ...", and I think I've bent over backwards to invite alternative perspectives about this. Still, I'm asking for my experience to be considered, which means yours and everyone else's deserves the same consideration.

I guess since everyone's opinion is equal, there's not much more reason for me to spend more time trying to articulate my particular viewpoint. If what I've said at extensive length so far isn't sufficient, more won't help, and I don't care to just argue.
Post

Re: LTSL - The LT script language

#30
Flatfingers wrote:
Dinosawer wrote:Python is widely regarded as a very easy language to learn for people learning to program.
Maybe I haven't programmed enough yet to be a real programmer though. :) But on the other hand, wouldn't that make me part of the target audience, in fact?
Regarded as such by the people who've learned it as their first/primary language, I assume? ;)

...
:lol: Fair question. Don't know about other people (Don't they start with Java or C++ in schools usually?), but not in my case. For me it was Java->tiny bit of Python->C->C++->more Python when it came to learning, so it's not a "first learned" bias for me. :)
This xkcd is relevant: http://xkcd.com/353/

Anyway, I agree that we're probably not going to agree on this one. So be it :ghost:
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image

Online Now

Users browsing this forum: No registered users and 8 guests

cron