This appears to be a pile of syntactic sugar on top of Lua, which is an idea which would have appealed to me a lot as a younger developer. But the older I get the more I realize that its almost never actually syntax or brevity that gets in the way in a software project and that this sort of thing often introduces a lot of cognitive overhead. It isn't that these extra doodads are hard to wrap your head around, but the fact that we have two very similar languages (Pluto, Lua) that we are interactive with on a regular basis (because Pluto works within the Lua ecosystem) and now we have to think about that a lot.
I think a lot of programmers when they first learn Lisp go crazy with macros, adding all sorts of flimflam to their programs because they can, but then eventually you realize that just makes life harder, or at least marginally more complicated, and you gradually give it up. Feels like a similar calculation could apply here.
WillAdams 11 minutes ago [-]
Would general-purpose programming include making a Graphical User Interface?
A simple and small language with GUI bindings and a graphical tool for laying out a design in a flexible manner with a responsive result is something a lot of folks would find useful.
matusnovak 1 hours ago [-]
Is it possible to use Pluto alongside with a binding library such as Sol2[0]? I don't mind not being able to set type hints in the bindings to use in some IDE, I can create stubs for it manually.
Well written and well documented. I will be trying it out. One drawback that I see is the use of packages from LuaRocks might be an issue and one does not really want to cope with compilation issues. But Lua is a beautiful language in any form.
Interesting, apparently the source also includes a (modified) version of the PUC Lua VM. Why don't they just generate bytecode for the existing VM and leave it as is (unless the modified version somehow would significantly increase performance)? What changes were necessary to the original VM to implement the language?
90s_dev 4 hours ago [-]
Some features like break N and default function args seem to be incompatible with the vanilla lua vm.
Rochus 1 hours ago [-]
I think that would be achievable with plain PUC Lua bytecode; it's actually just a jump. The same for default function arguments; the VM doesn't actually care how many arguments the caller pushes on stack, and providing default values is easy to implement for the caller.
90s_dev 11 hours ago [-]
Basically a more convenient/intuitive Lua for JS/C/Java/C++ users, plus optional static typing. May in fact use this instead of Lua.
JdeBP 1 hours ago [-]
There's almost nothing in there that's like C or C++. But there's a definite influence of .NET and C♯ with things like null-coalescing, null-conditionals, and interpolated strings.
Imustaskforhelp 7 hours ago [-]
Yea. I am definitely trying this out too. It really has some new features changes that I wished lua had.
tzury 6 hours ago [-]
Well, this is a very poor design, one which makes me think what is the purpose of this project in the first place?
for i = 1, 10 do -- Loop 1.
for ii = 1, 5 do -- Loop 2.
break 1 -- This will break from Loop 2.
break 2 -- This will break from Loop 1.
end
end
Seems logical to me. 1 = break the current level, 2 = break 1 level up, 3 = break 2 levels up, etc.
If you would do it the other way around, and then if you would add another for loop around the others, the breaks will break. You wouldn't expect that if you're modifying this code without looking at the current breaks or knowing about the break behavior.
If you however move the break statements inside a new for loop, at the most inner level, it would seem obvious that you have to update the break numbers.
nextaccountic 3 hours ago [-]
Adding a label to each loop and breaking by label (like in Rust) feels better and more resistant to code changes
lifthrasiir 3 hours ago [-]
I don't particularly dislike that design, but Lua already supports a goto target label `::label::` so I think the following syntax would work better:
::outer:: for i = 1, 10 do
::inner:: for ii = 1, 5 do
break inner
break outer
end
end
philsnow 4 hours ago [-]
What's poor about it, the numbers in the example? Think of them as inner/outer instead of "1" and "2". Without this kind of break statement, what do you do when you want to exit the outer loop, something like this probably:
local stop = false
for i = 1, 10 do -- outer loop
if stop then break end
for j = 1, 5 do -- inner loop
break -- to break from inner loop
stop = true; break -- to break from outer loop
end
end
So this new feature fits with the general theme of pluto being a very-sugared lua.
aa-jv 4 hours ago [-]
This is just poor language design.
The reason one might find this cumbersome or problematic, is in the case of very large numbers of lines of code - sure, your example is visible and somewhat readable (arguable) in its current form - but tell me you won't have issues when the loop is 80 or 100 lines of code, and you need to add another inner loop as part of the development process.
Are you now going to go through and be sure all your breaks are numbered properly? Are you really, though?
Better, imho, would have been to introduce labels and "break <label>", but even that is going to cause more headaches than its worth.
Ultimately, one shouldn't write such horrid code anyway.
raincole 2 hours ago [-]
That's a Lua dialect so I don't know what you expect ;)
"Pluto aspires to be a version of Lua with a larger feature-set, that is all. Pluto is not a Lua-killer, an attempted successor, or any of that. Many people (rightly so) love Lua precisely because of the design philosophy. And fundamentally, Pluto is a major deviation from Lua's design philosophy. Some may prefer this, some may not."
I think a lot of programmers when they first learn Lisp go crazy with macros, adding all sorts of flimflam to their programs because they can, but then eventually you realize that just makes life harder, or at least marginally more complicated, and you gradually give it up. Feels like a similar calculation could apply here.
A simple and small language with GUI bindings and a graphical tool for laying out a design in a flexible manner with a responsive result is something a lot of folks would find useful.
[0]: https://github.com/ThePhD/sol2
If you would do it the other way around, and then if you would add another for loop around the others, the breaks will break. You wouldn't expect that if you're modifying this code without looking at the current breaks or knowing about the break behavior.
If you however move the break statements inside a new for loop, at the most inner level, it would seem obvious that you have to update the break numbers.
The reason one might find this cumbersome or problematic, is in the case of very large numbers of lines of code - sure, your example is visible and somewhat readable (arguable) in its current form - but tell me you won't have issues when the loop is 80 or 100 lines of code, and you need to add another inner loop as part of the development process.
Are you now going to go through and be sure all your breaks are numbered properly? Are you really, though?
Better, imho, would have been to introduce labels and "break <label>", but even that is going to cause more headaches than its worth.
Ultimately, one shouldn't write such horrid code anyway.
[^1]: https://en.wikipedia.org/wiki/De_Bruijn_index
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...