4 ms·
> I would rather provide conclusive proof, like some side to side comparison of features to illustrate how idiomatic MoonScript is supposedly friendlier than Lu
by RyanSquared 9y ago
> I would rather provide conclusive proof, like some side to side comparison of features to illustrate how idiomatic MoonScript is supposedly friendlier than Lua.
In the reference manual, it is quite literally a side by side comparison. MoonScript code is shown to the left, with Lua to the right. MoonScript provides shortened code with minimal overhead compared to how it would be implemented in Lua, and you can see how by viewing the reference manual.
> For example, what if you have a typo in a variable identifier when assigning a value to a variable? Now you have a new variable. Where to look for the definition of a variable? It depends on what runs first now. That's not friendlier. CoffeeScript made the same mistake in the name of simplicity and it quite frankly doesn't add any value. The time you saved typing "local" will be now consumed several times debugging and code reviewing... and you will have to pay more attention during your code reviews.
This is the same problem with Lua. The best solution that I've found is to have an editor that highlights variables in different colors; once the color has changed (and it should based on if it's similarly named to another variable, so that `asdf` should be a very different color to `asdg`) you know it's a different variable.
> Then, removing braces and other delimiters. That's not necessarily better either. Let's remove lane delimiters from streets, traffic signals, stop and yield signs, and let's make it all implicit based on rules you can follow in your head. See? doesn't work.
Except you can still know when a block ends. Your comparison isn't really fair because it's just a cosmetic change. It's as though stop signs were a square instead of an octogon, not if they were just completely removed.
- partycoder 9y agoThe unique color solution doesn't scale: Imagine that across multiple files. Imagine that in a large project. Imagine that with color blind people. Then, when you remove parenthesis, it's the same as removing a lane delimiter. Matching parenthesis can already be confusing, now try matching invisible parenthesis. That creates more problems than it solves. If this author wants to borrow aspects of Python, I suggest reading PEP 20: The Zen of Python. "Explicit is better than implicit". Implicit parenthesis, implicit braces, implicit returns... the more implicit stuff the more work you need to do in your head, and the more you rely on humans. I thought programming was about giving more work to machines, not to humans.
- kbenson 9y ago> Then, when you remove parenthesis, it's the same as removing a lane delimiter. As someone that vastly prefers parenthesis, no, it's not. The block is just bounded by syntactic structure, not by delimiter. It's like replacing lane delimiters with rippled road texture. The delimiter is different and in my opinion inferior, but it's not gone, it's just replaced by some other indicator.
- partycoder 9y agoExcept that that whitespace is not used only for that purpose, it could mean also something else, right? We trade an unambiguous set of characters --the parentheses-- by whitespace, and make it context sensitive. How is that now more readable? As someone who has had to match these whitespace based parenthesis I can tell you it's not more readable. It's more like someone determined that parenthesis were not visually palatable and decided to remove them. Like "hey, that fire extinguisher doesn't look very elegant, let's remove it, or wrap it in wallpaper so nobody can see it".
- kbenson 9y ago> Except that that whitespace is not used only for that purpose, it could mean also something else, right It's not just whitespace, it's the specific formatting of whitespace. It's just a character, like any other, only defined by it's lack of distinguishing characters. Instead of whitespace, block continuations could be defined by pipes, or angle brackets, or any number of things. They chose wihtespace. > We trade an unambiguous set of characters --the parentheses-- by whitespace, and make it context sensitive. Parenthesis are often context sensitive in languages. It's very common for them to handle both code block and object/dict/hash definition. Languages often use '+' for both numeric addition and string concatenation (which in my eyes is often more problematic and less justified than whitespace as a block defining element). > How is that now more readable? As someone who has had to match these whitespace based parenthesis I can tell you it's not more readable. "Readable" is subjective. Unless you have experience with it, you would probably find APL more than unreadable, likely impenetrable. Experience can vastly change what one find easy to understand, and easier to learn doesn't necessarily mean better in all respects. > It's more like someone determined that parenthesis were not visually palatable and decided to remove them. Or, it actually is that some people prefer it, even if you and I do not, and that's what it is, a preference implemented in the languages they decided to make. It is, to me, subjectively worse, but the key word there is subjectively. There are trade-offs between the benefits and detriments of that style, but we shouldn't fall into the trap of assuming we can make objective claims as to the quality of the choices of languages that prefer structured whitespace as a syntactic element when it's obvious a large percentage of people find it beneficial. In the end, unless you're being forced to use this language, I'm not sure why it matters what choice they made with regard to this. If you don't like the choices made by this language, don't use it, and your actions will speak for themselves. If enough people feel that way, the language will die out or change. If enough people do like it how it is, it will continue, as it should, because there's no reason we should restrict other people's choices when it comes down to what is by large an aesthetic choice.