Yes, then to which you respond “You don’t need to use comments or use code that has comments”. I then reply why that mentality is not a good one by making a comparison. My statement was correct.
Are we not going to implement something that saves a hell lot of time in coding just because “Don’t use it, it makes it hard to read.”? I’d rather take my productivity as a basis rather than readability in Roblox, as the code I write isn’t read by tens of people. It’s not like as if a scripter couldn’t just put a comment or directly explain to the person who didn’t understand it in a development team. Even besides, it’s the coders’ responsibility to make the code readable, not other people.
3 Likes
You severely undermine the argument of people who do not support by creating this over summarization. There is more to code structure and code flow than simply “reading”. Anyone can “read” code, but it’s harder to understand and interpret code that, for example, jumps around a lot.
There is no need for goto statements in current lua implementations regardless, what use case is there that you couldn’t do right now? I don’t think making your code shorter is worth sacrificing potential readability and creating poor habits among people. There are people, of course, that will transcend goto’s nasty reputation and use it properly – those people are far and few between considering how bad I’ve seen Roblox scripts get in the general populace.
1 Like
You know exactly what I meant when I said “to read” and your argument is still the same.
It’s the coders’ responsibility to make the code readable, not other people.
There is a need: I don’t want to waste 10 minutes on something that can be done in 5 seconds efficiently.
2 Likes
Yes, but to a bystander that would have just joined the discussion there is grave potential for misunderstanding. Over-generalization tends not to target the two arguing, but rather the people that are watching.
Such as when? Example?
Just because you personally can’t read code that uses goto doesn’t mean everyone can’t. I don’t understand why your dislike for this means no one should have it?
Not what was said and this statement is logically fallacious.
Again, as I’ve been asking, what examples can you provide of the use case for this?
The examples given are quite trivial because you can just invert the guard in the if statement and have it span over the entire loop instead. It doesn’t really support your feature request too well. Is there a more complex / particular situation where ‘continue’ is more appropriate according to you? (I personally wouldn’t argue for ‘goto’ except for very, very specific cases, otherwise it leads easily to spaghetti code)
1 Like
They were just examples of how they are used. Not examples of good uses. I can get examples of good uses when I finish work.
What’s so inherently bad about having this in? More options are always good, and it doesn’t really affect you if you don’t use it.
3 Likes
Here’s one where I currently use an alternative to continue. I want to run everything before it but not the few things after it. Continue would improve the readability and mean I have to write less.
for a = 1, #Value.ArgTypes do
local Prefix, Suffix = " [/", "]"
repeat
if Value.ArgTypes[ a ][ 2 ] then
if Value.ArgTypes[ a ][ 2 ].Required then
Prefix, Suffix = " /<", ">"
end
local Opts = ""
for a, b in pairs ( Value.ArgTypes[ a ][ 2 ] ) do
if a ~= "Name" and a ~= "Required" and a ~= "Default" and b then
Opts = Opts .. a .. "=" .. tostring( b ) .. ", "
end
end
if Opts ~= "" then
Suffix = "(" .. Opts:sub( 1, Opts:len( ) - 2 ) .. ")" .. Suffix
end
if Value.ArgTypes[ a ][ 2 ].Name then
Str = Str .. Prefix .. Value.ArgTypes[ a ][ 2 ].Name .. Suffix
do break end
end
end
local Type = Main.TargetLib.GetArgType( Value.ArgTypes[ a ][ 1 ] )
Type = ( Main.TargetLib.ArgTypeNames[ Type ] or Type or "string" ):lower( )
Str = Str .. Prefix .. Type .. Suffix
until true
end
Ignore my new lines, a lot of people tell me it hurts their souls.
Just an example why I like continue:
for k,v in pairs(Players:GetPlayers()) do
local data = PlayerData[v]
if not data or not data.Loaded then continue end
if not v.Character then continue end
local head = v.Character:FindFirstChild("Head")
if head then replaceFace(head,data.Face) end
end
-- The equivalent without continue would need to be like:
for k,v in pairs(Players:GetPlayers()) do
local data = PlayerData[v]
if data and data.Loaded and v.Character then
local head = v.Character:FindFirstChild("Head")
if head then replaceFace(head,data.Face) end
end
end
Not a good example (but already wrote it, could delete but eh, shrug) , as this example can be pretty much compacted in one if-statement, as those 3 things aren’t really based on each other. If I used Character.RightArm.SpecialEffects.Something and needed to check if each existed, I would either need to use a lot of a or b statements or have several nested if-statements.
4 Likes
That’s a pretty good example of why I like it too. Makes the code neater, instead of long if statements you have multiple smaller if statements that are easier to read.
“Nobody should be able to use goto because goto is considered harmful” isn’t an argument; it’s dogma.
Lua is a simple language, and the lack of complex control flow structures can be limiting. Granted, there are workarounds–goto only makes many of those workarounds less messy and time-consuming than they would otherwise be.
http://sbel.wisc.edu/Courses/ME964/Literature/knuthProgramming1974.pdf
2 Likes
Regardless of what your opinion on goto is, this probably isn’t happening because this would be a core modification to the lua language (of which we’ve already got some, but aren’t looking to add many more).
What you can do: Write (or modify) a compile-to-lua language and use that in your workflow. Doesn’t someone use https://moonscript.org/ ?
4 Likes
######AAAAAAAAAAAAAAAAAAAAAAAAAA
That reminds me of my VB course I took last year,
GoTo LineNumber
Ex:
local a = 10
LineOne: a = a + 1
if a < 20 then GoTo LineOne
I don’t like it though 
I’m pretty neutral on this issue. On one hand I really think we should adapt to the most modern version of Lua, but in the other hand I really think that the usability of goto will dramatically impair the scripting practices of beginners on this game.
Considering there’s also the concern of free models and how they’d end up getting worse, I’m gonna have to edge towards no.
“continue” at least has clear semantics. “goto” needs more definition to see if it would prevent optimization or lead to velociraptor attacks.
–edit: “goto” needs to be defined /wrt scoping.
5 Likes
I’d be fine with just continue, it’s the main one I use.
3 Likes
My thought overall is if you’re currently having serious workflow issues without goto and continue, you can work around them by breaking your code into functions and using return as an escape clause. I think a lot of the arguments for goto and continue lies in tight knit performance.
Some discussion in general:
You jest (maybe?), but Visual Studio actually allows you to do this (to varying degrees of success).
I think that still allocates another memory frame, so it’s not quite the same.
Although somewhat neutral on this subject, I strongly disagree with this argument. In general more options are good. However, more options are not always good, especially in programming languages. For example, PHP has both and and && as as semantic, with the only difference being operation order. This increases the amount of things a programmer needs to think about. Furthermore, if Roblox adds goto and continue to its engine, it will never be able to remove it. For that reason, Roblox should be conservative in adding these changes.
The addition of features you don’t use doesn’t seem to affect you. However, it affects you directly when you start reading other people’s code. Furthermore, you don’t develop in a vacuum. I will read other developer’s code. Finally, this change will take significant engineering resources in Roblox, resources that can arguably reallocated to other things.
Right now this workflow is expensive in that you can’t copy and paste resources over. I hope the new plugin API is going to change this.
My two cents.
3 Likes