4 ms·

Adding superlatives to your stuff is, to me, just noise. e.g: "fast", "simple", "friendly", "lightweight". I would rather provide conclusive proof, like some s

Adding superlatives to your stuff is, to me, just noise. e.g: "fast", "simple", "friendly", "lightweight". I would rather provide conclusive proof, like some side to side comparison of features to illustrate how idiomatic MoonScript is supposedly friendlier than Lua. Personally I think the changes are not necessarily in the right direction: 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. 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.

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 ago
  The 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 ago
      Except 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.
deleted 9y ago
[deleted]
sattoshi 9y ago
How are they just noise? If somebody says that something is "fast", it's because it's purpose is to be fast and nothing else. If something says it's lightweight it means it's aim is a minimal size. They are not noise, they are mission statements.
- partycoder 9y ago
  Saying "our goal is to be x" is different than "we are x". One is an aspiration, the other one is a confident claim.
rweichler 9y ago
I see it as a toy language. The only person I think would find it useful is leafo himself since he can edit it however he wants. But everyone else should stay away from it. Plain Lua is so much better.
- partycoder 9y ago
  It's a general purpose language, you never know who will use it and how.
- honewatson 9y ago
  Can't agree with that. Having used both Lua and Moonscript quite a bit I think Moonscript is what most dynamic scripting languages should be. Simple, succinct and does what you need for a scripting language. I really enjoy using it.
  - rweichler 9y ago
    Care to give an example?
    - anonymoushn 9y ago
      The list comprehensions are really great. Most of the time when I'm writing Lua I can't be bothered to write exactly what Moonscript outputs for a list comprehension because it's noisy, but it's what I really would write if I cared about tiny amounts of performance.
      - rweichler 9y ago
        Idk. Still not sold. You can do list comprehensions in regular Lua with something like this: function listcomp(t, f) local r = {} for k,v in pairs(t) do r[k] = v end return r end And then, your Lua code would be like: listcomp({1, 2, 3, 4}, function(k, v) return v*2 end) Which would be the equivalent to this in MoonScript: [v*2 for k,v in pairs({1, 2, 3 ,4})] I dunno. Just seems like a wash to me. And then you think about the extra compile step to run MoonScript, and the potential performance hits, and I'm just turned off completely from it.
b0rsuk 9y ago
Side by side: the examples on the landing page have a "Show LUA" button, so you can easily compare.
eutropia 9y ago
Many languages allow for assignment and instantiation on the same statement... I deal with this all the time in ruby and my editor simply highlights vars which aren't used later (quickly leading me to figure out if I had a typo) As for your traffic example: in many circumstances removing lines and signs makes the roads safer (as reported by the guardian). People pay more attention because of increased uncertainty, and aren't driving (or coding) on autopilot. https://www.theguardian.com/commentisfree/2016/feb/04/removal-road-markings-safer-fewer-accidents-drivers https://www.theguardian.com/commentisfree/2016/feb/04/remova... Paying attention is precisely what we're paid to do.

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 ago
The 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 ago
    Except 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.

deleted 9y ago

[deleted]

sattoshi 9y ago

How are they just noise? If somebody says that something is "fast", it's because it's purpose is to be fast and nothing else. If something says it's lightweight it means it's aim is a minimal size. They are not noise, they are mission statements.

partycoder 9y ago
Saying "our goal is to be x" is different than "we are x". One is an aspiration, the other one is a confident claim.

rweichler 9y ago

I see it as a toy language. The only person I think would find it useful is leafo himself since he can edit it however he wants. But everyone else should stay away from it. Plain Lua is so much better.

partycoder 9y ago
It's a general purpose language, you never know who will use it and how.
honewatson 9y ago
Can't agree with that. Having used both Lua and Moonscript quite a bit I think Moonscript is what most dynamic scripting languages should be. Simple, succinct and does what you need for a scripting language. I really enjoy using it.
- rweichler 9y ago
  Care to give an example?
  - anonymoushn 9y ago
    The list comprehensions are really great. Most of the time when I'm writing Lua I can't be bothered to write exactly what Moonscript outputs for a list comprehension because it's noisy, but it's what I really would write if I cared about tiny amounts of performance.
    - rweichler 9y ago
      Idk. Still not sold. You can do list comprehensions in regular Lua with something like this: function listcomp(t, f) local r = {} for k,v in pairs(t) do r[k] = v end return r end And then, your Lua code would be like: listcomp({1, 2, 3, 4}, function(k, v) return v*2 end) Which would be the equivalent to this in MoonScript: [v*2 for k,v in pairs({1, 2, 3 ,4})] I dunno. Just seems like a wash to me. And then you think about the extra compile step to run MoonScript, and the potential performance hits, and I'm just turned off completely from it.

b0rsuk 9y ago

Side by side: the examples on the landing page have a "Show LUA" button, so you can easily compare.

eutropia 9y ago

Many languages allow for assignment and instantiation on the same statement... I deal with this all the time in ruby and my editor simply highlights vars which aren't used later (quickly leading me to figure out if I had a typo) As for your traffic example: in many circumstances removing lines and signs makes the roads safer (as reported by the guardian). People pay more attention because of increased uncertainty, and aren't driving (or coding) on autopilot. https://www.theguardian.com/commentisfree/2016/feb/04/removal-road-markings-safer-fewer-accidents-drivers https://www.theguardian.com/commentisfree/2016/feb/04/remova... Paying attention is precisely what we're paid to do.