> 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.

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.

> 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.

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".

> 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.

> Languages often use '+' for both numeric addition and string concatenation

Perl uses . or ~ depending on which version you are using. It also uses braces for code blocks and postfixed ifs which prevents errors like:

  if (x)
    y
  z

Instead of:

  if (x)
    y
    z

It prides itself to being close to natural language yet still uses braces.

I'm aware, and Perl is specifically what I had in mind when I noted that. It's a little different of a case in Perl than in a language that is more strongly typed, like Python, as Perl uses operators to cast into the appropriate types for the operation and Python makes it an explicit action (which is why Perl has separate operators for most string and numeric operations, such as < and lt, > and gt, == and eq, etc). A Python programmer without much experience in Perl might think this is a case of implicit action, but it's actually rather explicit, as the string and numeric specific operators explicitly define exactly what to do with the two operands.

It's a pet peeve of mine that languages have promoted + for addition and string concatenation when concatenation and addition are distinct concepts that don't really share a lot in common beyond the surface. To me, in new languages, it signals that someone likely hasn't thought through that issue very clearly, or has and just doesn't care about consistency (which I think it important in a language). Python at least has the excuse of age (even if it's not all that old compared to many others).

> It's not just whitespace, it's the specific formatting of whitespace.

Yes. Specific, context sensitive, that requires disambiguation in your head and therefore harder to read.

> We trade an unambiguous set of characters --the parentheses-- by whitespace, and make it context sensitive. Parenthesis are often context sensitive in languages.

Yes, but they're consistent with the mathematical notation everyone has used over their entire life. By the time you pick up a programming language you have most likely used parenthesis for a while.

I am going to create a new language 99% identical to English, where fork means knife, knife means spoon and spoon means fork. Have a happy time translating paragraphs of text involving those 3 objects from English into my language.

> "Readable" is subjective.

Yes. But implicit vs explicit is not subjective. Implicit meaning takes non-zero effort to understand. It works when you the implicit subject is not relevant and you can be abstracted from it, but in this case there is no encapsulation taking place. Therefore, we could objectively say it's less readable. Quod erat demonstrandum.

> Or, it actually is that some people prefer it, even if you and I do not, and that's what it is

Now you have 2 ways of doing the same thing with no added value. Now you have more possible ways of writing down an expression, if you are parsing an expression or refactoring your code with a regex now it's much more complex. If you are writing a coding standard now you will have to make rules for it, and people may not reach agreement on those rules. People may have meeting to discuss which one to use and why, and spend time moving from one style to the other. It's a waste of time.

In 2017 there's still people fighting over tabs vs spaces. Now we add another dimension to it: spaces vs parenthesis. An endless source of bikeshedding.

> In the end, unless you're being forced to use this language

That's not how it works. I have had to use languages that I dislike because that was what was needed in my organization.

> Yes, but they're consistent with the mathematical notation everyone has used over their entire life. By the time you pick up a programming language you have most likely used parenthesis for a while.

As opposed to the natural visual distinctions that we make all the time? Braces are a learned concept. Having something visually offset might be a learned concept, but if it is I bet it's so early it's prior speech developing. People notice visual patterns. An offset bit of text forms a visual pattern. Again, I don't prefer it, but I think you're reaching in your arguments against it.

> I am going to create a new language 99% identical to English, where fork means knife, knife means spoon and spoon means fork. Have a happy time translating paragraphs of text involving those 3 objects from English into my language.

So, exactly the same situation we have with English today, where it changes and slang is used? I'll have to ponder that problem as I kick it in my crib tonight. Or maybe I'll just settle in and watch the boob tube. Surely replacing some words with others isn't and intractable problem?

> Implicit meaning takes non-zero effort to understand.

Whitespace blocks are not always implicit. They may be well defined within the language they are used in (such as in Python). It's no more implicit than < means less than. Both are defined within the language, and < happens to also share meaning with mathematical notation, which makes it easier to grasp initially for those familiar with that, but there's nothing implicit about either as they both use the inclusion of one or more symbols to confer meaning (even if they are space characters), rather than the exclusion of information. You are confusing whitespace for no-space.

> Now you have 2 ways of doing the same thing with no added value.

Of course there is added value. People prefer it. People's preferences have value.

> Now you have more possible ways of writing down an expression, if you are parsing an expression or refactoring your code with a regex now it's much more complex.

That depends on the language and whether there are multiple ways of defining a block. Unless you expect your expression to parse C, Lisp, Python, Smalltalk and Prolog correctly it it's just those pesky Python whitespace blocks that are holding you back. Within Python, space indented blocks are canonical. If you think that is causing too many ways to define how to perform something in different languages, you're probably better off not looking at some of the other languages I listed earlier...

> In 2017 there's still people fighting over tabs vs spaces. Now we add another dimension to it: spaces vs parenthesis. An endless source of bikeshedding.

Not really. Tabs vs spaces is something people that interact in code with each other have to deal with. I doubt Perl and Python developers get upset when they load each other's code, in the other's language, and see the other used spaces instead of parenthesis[1] or vice-versa, because that choice doesn't make sense within those languages. Sure, try to use indentation to define blocks in Perl. It won't do you any good without the parenthesis, because Perl doesn't support that choice.

1: It's obvious at this point we're actually talking about curly-braces, and not parenthesis, right? I'll keep using parenthesis for now for consistency's sake.

Parentheses have been used for evaluating functions and establishing operator precedence for literally hundreds of years. It's taught in every school in every country and most books will contain this notation.

But since everything is relative, it doesn't matter anymore. Let's delimit function evaluations and operator precedence with the words "cat" and "dog" from now on. Since everything is a preference, and is relative, it doesn't matter.

However, what you fail to see is that in reality a choice like this involves effort, it has an economic cost, it's not only preference.

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.

Saying "our goal is to be x" is different than "we are x".

One is an aspiration, the other one is a confident claim.

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/remova...

Paying attention is precisely what we're paid to do.

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

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.

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.

Care to give an example?

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.

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.

There are no potential performance hits. In particular the code generated for list comprehensions would be faster than your example because there is no extra function call per item.

Over here it generated

  local b
  do
    local _accum_0 = { }
    local _len_0 = 1
    for k, v in pairs({
      1,
      2,
      3,
      4
    }) do
      _accum_0[_len_0] = v * 2
      _len_0 = _len_0 + 1
    end
    b = _accum_0
  end

It did a pretty good job. Unlike your code, it doesn't have any function calls, and unlike the code I would probably write, it doesn't use the # operator.

There are a lot of features that make Moonscript much more convenient than plain Lua. Examples (try the first three in Lua):

- default values for function parameters

- list comprehensions

    [x * 2 for x in *{1, 2, 3}]

- easier iteration (e.g. `for key, value in pairs obj`)

- local is default, not global

- a simple class system if you need it

- `export`, `from` and `import` keywords

- `+=`, `/=`, `*=` etc. operators

- indentation based scope (ok, this is debatable)

I can't think of a single place where plain Lua is actually better. OK maybe `:` is better as a method call operator, but that's it.

> default values for function parameters

    function f(a, b, c, d)
        a = a or 1
        b = b or 2
        c = c or 3
        d = d or 4
    end

> list comprehensions

https://news.ycombinator.com/item?id=14444215

> local is default, not global

I think this is a con.

> a simple class system if you need it

I also think this is a con, because it limits flexibility.

Here's my class system:

    Object = {}
    function Object:new()
        local self = setmetatable({}, {__index = self})
        return self
    end

And how to use it:

    local super = Object
    Shape = Object.new(super)
    function Shape:new(color)
        local self = super.new(self)
        self.color = color
        return self
    end

    local super = Shape
    RedShape = Object.new(super)
    function RedShape:new()
        local self = super.new(self, 0xff0000)
        return self
    end

If I want to add multiple inheritance, or interfaces, it is easy. Because it is just metatables. With MoonScript this is not possible.

> `export`, `from` and `import` keywords

Sounds like a con to me. `require` is simple.

> `+=`, `/=`, `*=`

I agree with this one.

>

    function f(a, b, c, d)
        a = a or 1
        b = b or 2
        c = c or 3
        d = d or 4
    end

Compare with:

    f = (a=1, b=2, c=3, d=4) -> ...

Also note the latter is correct when you call it as f(false).

It's a general purpose language, you never know who will use it and how.