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.
Kotlin has some great ideas, but it's kind of frustrating to have half my code yellow-highlighted because the IDE has detected that there's a short-hand version of everything.
for example in JavaScript
let fish = 5
let cheese = 27
let nop = 0x4e71
result = {fish,cheese,nop}
result = {fish:fish,cheese:cheese,nope:nop}
result = {fish,cheese,nope:nop}
Philosophically, I feel a little ambivalent about the briefer syntax because it mixes two sorts of denotations. Variables refer to scoped objects for which, from the point of view of what the program means, vanish (in compiled languages they literally can totally vanish - variable references are just resolved into the appropriate reference to memory). The keys of a hash table are totally different sorts of things and persist at runtime. I'd prefer that these two very distinct conceptual spaces remain separate, even if in a certain sense they overlap in a specific case.
Doesn't really matter, though.
That's storage, not load. You need you know more, but you don't have to think about as much at any one time.
BrainFuck has extremely simple operations. You don't have to think about very many different things at all, but you need to think about them a lot.
>and all you get from the shorter one is typing a few fewer keystrokes.
I'm not particularly concerned about keystrokes (unless I'm golfing). I'm happy to increase the size of the content to reduce how much I think about it. Reducing the number of elements I have to look at to grasp the same concept is distinct from keystrokes.
Sometimes
ArbitraryLongVariableName = 43
a = 43
ArbitraryLongVariableName += 1
ArbitraryLongVariableName = ArbitrarilyLongVariableName + 1The concise syntax was tossed out, but I have a soft spot for it.
For example coalescing operator. You can do the same in standard Lua with or. Pipe operator might seem like cool idea, but the language needs to be designed around it (Elixir) or you need multiple variants (threading macros in Lisps).
I don't mean to discount the work that has gone into it, and there are a lot of really neat features here. But honestly I think it would be stronger as a standalone thing, without all the lua baggage, given how far idiomatic pluto diverges from idiomatic lua.
[0]https://pluto-lang.org/docs/New%20Features/Ternary%20Express...
local function report(result) print(result ?? "The value was nil.") end
report(filesize("/path/to/file/of/length/zero"))
If filesize returns nil for file-not-found and the length otherwise. Wouldn't coalescing work and or would not be able to identify existing but empty files.
It's particularly exciting that they constantly rebase upstream Lua, and plan to update it to be compatible with Lua 5.5. Especially because Lua 5.5 finally has the ability to turn off globals!
1. classes
2. named parameters with default values
3. string interpolation
I love Lua, but it's a bit sad that everyone ends up hacking together their own OOP system (including myself). I would really prefer a standardized solution.
Named parameters are such an underrated feature IMO. It makes function calls so much easier to read, in particular if the arguments all have the same type. I know, we can "fake" named arguments by passing a single table argument, but this has some overhead and default values are still rather awkward to implement. The one big downside of named parameters is that the parameter names are now part of the public API.
I don't know why, but 100 times a day I have to go back and replace a dot with a colon and it drives me nuts.
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.
the thing i like lua for is easily getting into that "flow state" of just writing code without having to think about "how should i approach this" but sometimes the lack of things which pluto addresses forces a level of verbosity that snaps me out of it. i often find myself hitting a mental roadblock where i think "like fuck am i gonna write that much code to do X, i'll just go work on a more fun part of the program and come back later".
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
::outer:: for i = 1, 10 do
::inner:: for ii = 1, 5 do
break inner
break outer
end
endIf 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.
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
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.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
"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."