devlog wrote:

Code: Select all

Script System_Simple
  Param int asteroids
  Param RNG rng

  Var kSystemScale 1000
  Var system System_Create

  For i 0 (< i asteroids) (++ i)
    Var asteroid (Asteroid_Create (RNG_Int rng))
    Object_SetPos (* kSystemScale (RNG_Direction rng) (RNG_Exponential rng))
    Object_AddInterior system asteroid

system

I could tell exactly what was going on before you even explained it. My hat is off to you making it so easy to read! I'll be honest - I kind of miss a ( ) around the initiating line of the For loop, and the lack of an ending line is a bit off-putting. I do like the necessary indentations, though, I'll admit. I've always been a fan of indenting code.

Code: Select all

MyFunction
  arg1
  arg2
  FunctionComputingArg3
    blah
    blah
    AnotherFunction
      blah

I lol'd.

I personally greatly enjoyed this devlog, though I know not many will. Very awesome! I'm wondering about error handling within the LT engine when it comes to the UDF reader - it'll output the errors to a log file, right? (where and why.) I know a try/catch would get it, but I'm very rusty with C++, so I don't remember precisely how that works there.

Anyway, I approve! Very exciting to see.

Are we going to see a list of functions compiled anytime soon? At that point we could probably start writing our own bits of code to experiment with once the game is released. (Yeah, it'd be a long wait, but it'd be something fun to play with for the time being.)

Also curious: With that code you posted, how would I go about changing the default shape of the asteroids, and what would I need to do to make, say, cubes or spheres? Is there a select case function? Can you call different methods?

Very interesting.

But you can't call it UDF. It's got to start with LT.

I suggest LTSL (LT Scripting Language), LTCCL (LT Content Creation Language), LT#, LT++, LTython, etc.

Kinda reminds me of ACAD's version of LISP.

Last devlog was great , only thing I'd like 'bout it is some pics to show of what the script made/creates ingame .

Helgisa wrote:Last devlog was great , only thing I'd like 'bout it is some pics to show of what the script made/creates ingame .

Yeah, images would have been nice, especially since I'm (and possibly many more? ) are visual learners. I do love an indent-based scripting language, because I use Python primarily, and find it a lot more easier than using tons of brackets, parenthesis, and a lot of other junk when you can just indent. Great job!

I use Java primarily, but have also used C++. I learned in VB. (ew. Bad learning experience.)

[Suggestion to mods: would it be worthwhile to split the UDF comments in this thread off into their own thread, maybe even the first thread in a new sub-forum for LT scripting? I suspect this is just the first of what's going to be a very active collection of related comments and discussions.]

To the proposed language: hrmm.

I can see the elegance of its design. In particular, let me try to summarize its key features:

• All variables must be declared before use and are strongly typed
• Whitespace-separation and indentation are equivalent ways to define scope
• Operators are actually functions

Based on these, some reactions and questions:

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.

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"?

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?

---

I want to be clear here that I'm not just looking for things to complain about. Most of these comments (other than a couple of general language design rules that I think are defensible) are in the form of questions because I know there are things I don't understand. I assume there are design goals that Josh hasn't stated, and that knowing those goals would answer (or make irrelevant) many of these questions.

In particular, while I think implementing UDF with actual operators and scoping characters would make It easier to use by more modders, this would require more of Josh's time and might complicate the UDF parser. Josh may be assessing that level of effort as a cost that exceeds the benefits as he perceives them (my arguments here notwithstanding). Or he may feel that the design elegance of UDF as a functional language justifies some extra effort by would-be modders even if they're likely to be familiar/comfortable with more declarative languages.

If so, then those are design beliefs that are about "what," not "how." We might usefully discuss how something Josh wants could be done, but what he wants isn't debatable. If that's where the functions-as-operators and indentation design decisions live, then I won't say any more about them.

So. How off on my own am I going to be on this one?

Flatfingers wrote:So. How off on my own am I going to be on this one?

I'm there with you. These are really interesting questions, and I'd love to hear Josh's thoughts.

Having worked quite extensively with Python recently,I have to disagree with your second point, Flatfingers. Sorry
I simply don't think that's how our brain works. The { } are not there to convey information but structure in the code - code between those brackets is subordinate to the code outside it. And structure is much easier conveyed visually, by indentation, than with characters.
Point in case: why else would everyone, in every programming language, indent their code?
Example in pseudo-c++:
Now I'll remove indentation: And the brackets: Which structure is clearer, without indent or without brackets? I'd definitely say without bracket and with indents. Because I see immediately how the code is indented but I have to spend some time looking where all the brackets are hiding before I can figure out the structure of the code. Especially in more complex code than my example.
As for the other point, I'd suggest Josh takes the Python route; in Python you can use any kind of whitespace you like, be it any amount of spaces or a tab, as long as you're consequent throughout your file. I always just use tab and I never have to actually think about indentation. I have had way more trouble in C++ forgetting brackets than I've had in Python having wrong indents, in fact.
Hope that makes my point clear

Flatfingers wrote:Suggestion to mods: would it be worthwhile to split the UDF comments in this thread off into their own thread, maybe even the first thread in a new sub-forum for LT scripting? I suspect this is just the first of what's going to be a very active collection of related comments and discussions.

Splitting - sure.
A new forum? Let's see how much content there is to fill it...

Gazz wrote:

Flatfingers wrote:Suggestion to mods: would it be worthwhile to split the UDF comments in this thread off into their own thread, maybe even the first thread in a new sub-forum for LT scripting? I suspect this is just the first of what's going to be a very active collection of related comments and discussions.

Splitting - sure.
A new forum? Let's see how much content there is to fill it...

At least two thread already !

Yeh, yeh. Have it your way then!

Gazz wrote:

Flatfingers wrote:Suggestion to mods: would it be worthwhile to split the UDF comments in this thread off into their own thread, maybe even the first thread in a new sub-forum for LT scripting? I suspect this is just the first of what's going to be a very active collection of related comments and discussions.

Splitting - sure.
A new forum? Let's see how much content there is to fill it...

I almost suggested this very thing - the modding subforum is going to absolutely explode as soon as Mr. Parnell releases more of the functions and everything. Pre-made mods are something you see a lot with games utilizing something like this. I imagine the beta backers will have a lot of mods to choose from, if they ever tire of vanilla, or simply want a different experience.

And I laughed at the subforum description.

This is great: I love both Lisp and Python!

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.

I believe prefix versus infix has more to do with which languages you are familiar with, and that infix is not inherently more readable. I don't mind using prefix, at least, but I study math so might have a bias in the other direction. Could go the Haskell route and make everything prefix, but possible to make infix by adding grave accents (`) to each side.
Is the language going to have macros? If so, then all syntactic matters can be solved to some degree.

Another question (might have been answered in another thread; I haven't read everything yet): can you program the AI?
It would be great if people could program their own AIs which you then could let loose in your own world. Kind of like having another player there, and would create another kind of diversity in the AI population. Perhaps even language-agnostic AIs outside of the game, so the game sends information to some server-like structure running the AI, and every once in a while the server responds with an action.
This could open the realm of competitive Limit Theory: let loose a couple of different AIs in the same system (along with the regular AIs) and let them play by themselves for a while.



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
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.