Neovim: lua or moonscript

[aktau]

As @tarruda has commented twice now (once here), there's apparently been a choice towards using moonscript over vanilla lua. I don't know where else to put this but it seemed like @tarruda was referring to some decision about this being made. If so, where was it? Did I miss it? And secondly (and perhaps more importantly), what's the policy on allowing plain .lua files in the source tree? I'm asking because I'm way more familiar with vanilla lua and would probably prefer/be better at contributing vanilla, finding moonscript to be a bit non-obvious.

[justinmk]

I think (hope) moonscript is only for writing tests.

[tarruda]

@aktau I used moonscript because I find it much cleaner to read and write, much less boilerplate than lua:

• local scope by default (like python)
• No need for parens on function calls(can look a lot like haskell) and also looks more like a DSL
• No boilerplate for object-oriented programming

However, I agree that I should not make this decision by myself. How about we conduct a poll with the community to decide what's best? I think we can do the same thing as #104 and use @ZyX-I script to collect the results.

[aktau]

@tarruda good to know that even as BDFL you are interested in talking about it ;)

I do kinda agree with the local scope by default and boilerplate for OOP yet I'm a bit torn, I've been looking at moonscript and finding it hard to love (while I immediately fell in love with lua the first time I saw it).

Some kind of discussion and/or vote about it would be nice, I'd like to know what the other members of the community think. (options: moon, lua or mixed)

About the parens... I'm actually in favor of having parens instead of not having them, but that's entirely a taste matter, I believe. And I say that as someone who's written a fair amount of Scala and has (ab)used it's paren-less features.

[justinmk]

My concern with moonscript is that it adds another dependency and abstraction layer for dubious gain.

• it's a project that may or may not continue to be active, but will be critical to the health of neovim
• the benefits are largely superficial AFAICT
• like coffeescript, it may possibly introduce _new_ quirks on top of lua, which is already a strong language
• it adds additional cognitive load to developers who need to understand the full stack of neovim development (C, lua, moonscript)
• it adds another dependency and build step
  
  
  
  • edit: actually it doesn't require an additional compile step: http://moonscript.org/reference/#moonscript_module
  
  

It seems that busted works without plain lua, too.

[aktau]

There could perhaps also be another way to make lua less boilerplate-y, and instead of going OOP adding a bit of functional programming to the mix with luafun.

[sethwoodworth]

Vim is 22 years old. Lua is 20 years old. Moonscript is 3 years old and not yet at 1.0.

If NeoVim is going to supplant vim, then it should be planning for the next 20 years. I think that moonscript is a risky choice and may set back a lot of progress.

[Soares]

Note that if the neovim community reaches critical mass, any lua 'dialect' that we pick will see its chance of sticking around drastically increase -- we aren't operating in a vacuum here, and if a giant neovim community starts using moonscript then moonscript is much less likely to disappear.

[philix]

Moonscript is for Lua what CoffeeScript is for JavaScript. Just as browsers
embed JavaScript, I think neovim should embed Lua. This allows people to
choose whichever higher level language that compiles to Lua that they want.
Requiring contributors to learn C, Lua, Moonscript... is another point in
favor of Lua.
On Feb 27, 2014 8:24 PM, "Seth Woodworth" [email protected] wrote:

Vim is 22 years old. Lua is 20 years old. Moonscript is 3 years old and
not yet at 1.0.

If NeoVim is going to supplant vim, then it should be planning for the
next 20 years. I think that moonscript is a risky choice and may set back a
lot of progress.

Reply to this email directly or view it on GitHubhttps://github.com/neovim/neovim/issues/207#issuecomment-36304777
.

[altunyurt]

There are bunch of other tools that compiles to lua. Using lua as the scripting language will give the flexibility to use any other language that compiles to lua, besides lua itself.

On the other hand, using an abstraction layer on top of an existing already proven component that is both powerful and simple, will just limit it's capabilities at the cost of bringing more bugs and problems into code base where no contributor of this project is either responsible or should be dealing with.

[simendsjo]

I would be _very_ careful to start using a language in early development. Things _will_ break. I did this for a medium sized project back in 2007-2008, and I consider it my biggest mistake ever. Moonscript looks nice enough apart from a couple of dangerous whitespace rules (didn't look at OOP), but is it worth the risk?

[lslah]

I'd love to see the first commited unit test by @tarruda written in Lua in order to compare both. I've never used both languages before but I really like the way the current unit test is written. It took me just some minutes to create another unit test using the first one as template - I really enjoyed it. Just curious if it'd be the same fun using pure Lua.

[Gaelan]

Ruby anybody? :smiley:

[Gaelan]

If we are sure about going with Lua, then my vote is Moonscript.

[tarruda]

@aktau I had a similar reaction the first time I had contact with coffeescript, but with time I learned to enjoy how nice functional-style programs look in it. I also like the 'DSL look' programs have when you dont have to put parenthesis around callbacks passed to functions.

What is hateful about coffeescript are its scoping rules(pure madness). Moonscript does not share this problem since it provides an 'export' keyword similar to python 'nonlocal'

I strongly believe in the zen of python, especially that programming languages there should provide one way of doing things, so I don't like the fact that moonscript lets you do same thing in more than one way(such as calling functions with or without parenthesis), but this problem could be solved by a linting program that forces a subset of the language(Which I dont think moonscript has yet)

@justinmk / @simendsjo I do not share these concerns about moonscript being abandoned, especially because it's very easy to write a 'transpiler'(I think vimscript wont be so easy since it seems to have an 'obscure ' grammar). Take coffeescript for example, it' s official implementation is about 2k lines of code(Dont know about moonscript since I never looked at its source). Perhaps the author, @leafo , would like to join the discussion to give some insight?

@philix There's no doubt that neovim will eventually embed the luajit engine, allowing the community to choose which language they prefer for writing their own code. We are discussing what language to use for writing official code, but even if moonscript is choosen, third party code will still be able to use lua or any other dialect they prefer.

@Gaelan , moonscript is inspired by coffeescript, which was written by a programmer that wanted to make javascript look more like ruby , so I think you can enjoy it.

I think moonscript has the same motivation of projects such as sass or less. They 'adapt' the underlying language to the tastes of the author and a community.

From my point of view, Moonscript does nice things for lua, but in the end this is a matter of personal choice, that's why I think this is something that should be decided by the majority of the community.

Here's a side-by-side comparison between moonscript and lua, which is also a good reference for quickly learning the language. Notice how it saves the programmer from writing a lot of boilerplate, keeping the source cleaner.

No matter the choice I think consistency is essential, when a language choosen we'll stick with it, so dont be too quick to judge :)

[Gaelan]

@tarruda Yeah, looking at the moonscript made me thing "Hey, are those tests written in coffeescript"?

[Gaelan]

@tarruda Just out of curiosity, do you have any reason for Lua over Ruby, Python, JS, or something else?

[cweagans]

+1 for Python, but if it's either Lua or a dialect of Lua, I guess I'd have to prefer vanilla over anything. Lots more documentation on that front.

[leafo]

+1 for MoonScript

[mutantturkey]

Lua is easily embeddable
On Feb 27, 2014 8:10 PM, "Cameron Eagans" [email protected] wrote:

+1 for Python, but if it's either Lua or a dialect of Lua, I guess I'd
have to prefer vanilla over anything. Lots more documentation on that front.

Reply to this email directly or view it on GitHubhttps://github.com/neovim/neovim/issues/207#issuecomment-36312044
.

[tarruda]

@Gaelan yes. Lua is a very lightweight library compared to ruby or python.

That is perfect for our main use case which is remove the very complex C code implementing vimscript. Ruby or Python standard libraries wont make much difference here since most of what we need is provided by lua: a scripting language VM with a garbage collector. It's C api is also much cleaner than alternatives.

Remember that even though we'll be embedding lua, the main way to extend the editor is using your favorite language with the new plugin architecture.

[Gaelan]

@tarruda OK.

[leafo]

If MoonScript is chosen as the language I will work closely with those using it. I'll fix any bugs you might find and I'll even add new syntax should you come up with any good ideas.

As for the stability of MoonScript, I can only speak for myself, but I've been using significantly since I first released it about 3 years ago. I've written well over 100 thousand lines of code in it and refined the language every step of the way. I've got broad test coverage in the repo and a handful of projects that depend on its stability.

I have no intention of abandoning the project. I've written web frameworks, large websites, small websites, command line tools, other languages, various libraries, many games, and a bunch of other stuff in MoonScript. So hopefully that will give you an idea of my devotion to the project. :smiley:

I would be honored to have MoonScript be part of neovim.

[cweagans]

I strongly feel that language ubiquity should be a large factor here. Lua is in a lot of places, but Javascript is literally _everywhere_ these days. If I was making the decision, Moonscript would not be an option under any circumstances, and not because it's not a good language (I've never even heard of it before today), but because I know know anybody that's using it. If I'm going to have to learn an entire new language to build things for my neovim install, why not just dig in and learn vimscript?

I know that I would be extremely unlikely to use Lua anywhere else other than vim. Javascript or Python, OTOH...well, that's a different story.

[tarruda]

@cweagans As I have said, moonscript would be used only for testing and writing official code. You would be free to write and publish extensions or user interfaces in any other language.

Even if you decide to submit a patch, all you need is a very basic knowledge of the language for writing a test case. I mean, how different this is from writing tests in ruby, python or javascript? Except for the ffi boilerplate(which will be removed soon as we'll take information directly from the C headers) it's the same idiom we see in all the bdd testing frameworks out there.

Besides the fact that lua is lightweight and perfect for embedding, luajit has a great foreign function interface, which makes it perfect for unit testing C code.

We should choose between moonscript or lua soon, and keep the poll open until sunday. @ZyX-I could you explain how your voting script would work for this?

[ShaneDelmore]

My vote is for moonscript. The whole reason this isn't in C is that we want a more appropriate testing language where the language gets out of the way and lets us see what are spec is really trying to say.

[houqp]

After seeing @leafo 's commitment to to help with neovim, I will vote for moonscript as well :)

I am actually very happy to see neovim adopt Lua, because I am a big fan of LuaJIT's FFI interface!

[cespare]

+1 for Lua/Moonscript over other options. I don't even use Lua (whereas I have used Ruby/Python/JS extensively) but from what I know, the speed and footprint of embedded Lua is a huge advantage over alternatives.

Looking into Moonscript for the first time today, I mostly like what I see -- it looks like a reasonable clean-up of vanilla Lua and it's very obvious how it compiles to Lua. If you know Lua, it's not really like learning a new language -- it's just a different way of writing it. Most of the complaints I see here about Moonscript are the same ones I hear about Coffeescript, and don't seem very compelling to me.

The main problem I have with Moonscript is that I personally find significant whitespace distasteful (my editor can't always help fix my indentation, indentation bugs can be pernicious and difficult to track down, and copy-pasting code is more difficult, among other issues).

On balance, I don't think I have a preference between Moonscript and Lua.

[ghost]

Moonscript looks really clean and doesn't appear to be a risky option (in terms of longevity). If Moonscript were to die we could simply replace the Moonscript with its generated Lua.

Moonscript with parentheses for function application would be amazing, IMO.

[scott-linder]

:+1: moonscript, the example unit test @tarruda has written appears to be very declarative and easy enough to follow, although if whitespace is significant I think it would be a good idea to add vim modelines to each test, or at least post some global formatting standard for the unit tests so I can add a rule somewhere (its irrelevant what the standard is, only that there is one).

[tbelaire]

I'm quite happy that we're going with Lua, since it's a really nice language. Very nice to embed, and C code is pretty clean when embedding.

After reading more of the moonscript docs, I find that the level of magic is just too much for me.
This example in particular was just too much:

y = { my_func 1,2,3,
   4,5,
  5,6,7
}

Lua
local y = {
  my_func(1, 2, 3, 4, 5),
  5,
  6,
  7
}

I think that the Lua code is actually much nicer to read at this point.
The other examples about this point are the same kind of thing. There's just a few too many special rules, and although I like parts of it, I feel like the potential for confusion is too high. I would be in favour of a restricted subset of Moonscript, but for now, I must cast my vote to Lua

+Lua.

PS. List comprehensions are nice though. I would miss those.

[ghost]

@tbelaire While I agree that magic makes debugging harder and can cause confusion, with Moonscript you can easily do moonc my_script.moon to see the Lua code. This will surely go a long way to eliminating confusion.

[leafo]

@tbelaire I'm not suggesting people write code like that, I'm just providing a language specification so it's perfectly clear why what happens when it does.

[tbelaire]

@leafo I would be much happier if we had a linter or something that made that a syntax error, and required a set of ()s. Same with the if.

if (func 1,2,3,
  "hello",
  "world")
    print "hello"
    print "I am inside if"

is much clearer as to the intent than without the (), and there is very little downside.
In Python it's easy, since you always have a : sentinel before an indent block, which makes it really easy to parse. Here, it's messy, and a little stricter syntax would go a long way to avoiding confusion.

[scott-linder]

@tbelaire you can write some pretty wicked stuff in C as well, but we are still going forward with development of neovim in C, because if you restrict yourself to good, clear style you can go far.

Another thing to consider is that, for example, every language provides a specification of its operator precedence, but you would be foolish not to use parenthesis in even the simplest of cases where ambiguity might arise (for readers, not compilers); the languages leave these cases up to the user, because it would be ridiculous to provide require parenthesis for every operation.

Of course, you might side with John Carmack: "Whatever is syntactically valid will wind up in your codebase,” in which case your point stands.

[ZyX-I]

@tarruda I am completely against using votes for technical decisions.

My cons:

1. I am checking lua to moonscript comparison and find it using quite a lot magic. You can always say that it is not necessary to write this way, but neovim is going to have a lot of contributors thus if one can write this way he will. Lua is easier to understand.
2. Since moonscript version is 0.2.4 and provided it uses usual semantic versioning (meaning that 0.3 may introduce incompatibilities) it is insane to use it. (I have not actually found a word that it does use it, but it is expected that version looking like 0.2.4 is using semantic versioning.)
3. Moonscript is not present in main portage tree, debian repositories, ubuntu repositories, centos repositories. If pkgs.org is up-to-date (distributions from the previous sentence were searched without using it) then moonscript is only present in fedora. It is much easier to not use moonscript rather then push it to all these distributions especially if neovim is the only thing that requires moonscript.

[philix]

@ZyX-I nailed it.

[Gaelan]

because it would be ridiculous to provide require parenthesis for every operation.

But what about lisp? :)

[Gaelan]

Moonscript is not present in main portage tree, debian repositories, ubuntu repositories, centos repositories. If pkgs.org is up-to-date (distributions from the previous sentence were searched without using it) then moonscript is only present in fedora. It is much easier to not use moonscript rather then push it to all these distributions especially if neovim is the only thing that requires moonscript.

It is in luarocks (the Lua package manager) though.

[scott-linder]

@Gaelan he he, that's actually the exception that proves the rule, because even lisp inserts a great many parenthesis for you.

[scizo]

+Lua, moonscript is adding a needless layer.

[folago]

+1 for Lua

[tarruda]

@tbelaire

When it's not obvious where a function call ends due to a following comma and identifier, I wrap it over parenthesis like it's done in haskell. Eg: The given example would look like this:

Moonscipt
y = { (my_func 1,2,3,
   4,5),
  5,6,7
}

Lua
local y = {
  my_func(1, 2, 3, 4, 5),
  5,
  6,
  7
}

A linter would obviously enforce a 'sane' coding style and forbid writing crazy things like above. As @leafo commented, he's only explaining how the grammar works, no one would ever write something like that.

@ZyX-I

1. If magic means boilerplate reduction, then I'm in favor or it. Also, 'magical' is relative, I bet that for many C programmers, languages like python or java are also considered magical merely because the manage memory automatically. If something proves to be too 'magical' for the tastes of the community, we can always forbid it with a linter.
2. From what @leafo said, he would be working closely with us, so I doubt he would commit such a breaking change without giving us some support. Even if he did, we could always fork and maintain a separate version.
3. I can't consider that to be a problem. The fact that distributions dont package some software wont stop me from using it if it's free and I think it would be good for the project. In this particular case, the benefits would be a cleaner code that is easier to read, but since those benefits are relative (depend on personal taste) I'd like to share this decision with the community.

[clentfort]

2) From what @leafo said, he would be working closely with us, so I doubt he would commit such a breaking change without giving us some support. Even if he did, we could always fork and maintain a separate version.

The idea that at some point we might have to maintain an own fork of a language negates any benefit we have at the first point. Plus there is only one maintainer! Even if he has no plans to abandon Moonscript there is still the chance of events that occupy him otherwise.

Plus a lot of people are already familiar with Lua, not with Moonscript. Sure one can learn but it might scare a lot of contributors of if they have to get used to Moonscript before they can start hacking away.

[notpratheek]

I thought I'll add my $0.02 here :

I'm not familiar with Lua, but I'm willing to spend time to learn Lua (I'm beginning to see that its a simple and a powerful language). Most new coming contributors would mostly be comfortable to learn Lua and help with the development of neovim (I'm saying this for myself, not sure about others, they may/may not learn it ! :sweat_smile: )

Second, I have absolutely nothing against Moonscript. I in fact think its great and a wonderful dialect, but to start (learning and) writing in Moonscript, one must be pretty proficient in Lua, and I'm assuming most of them might be good at Lua, but not _that_ familiar with Moonscript. So, I hope we stick with Lua, so that we can have different developers contribute their ideas to neovim.

How about this ? Those who are proficient in Moonscript can write in that, compile it to Lua and submit, and others who are good at Lua can write in that and submit them ? :smile:

[ZyX-I]

28.02.14, 13:12, "Thiago de Arruda" [email protected]":

@tbelaire
When a function call makes it non-obvious where it sends, I wrap it over parenthesis much like it's normally done in haskell. Eg:Personally I would write the example like this:Moonscipty = { (my_func 1,2,3, 4,5), 5,6,7}Lualocal y = { my_func(1, 2, 3, 4, 5), 5, 6, 7}
A linter could be written to enforce a 'sane' coding style and forbid writing crazy things like above. As @leafo said, he's only explaining how the grammar works, no one would every write something like that.

@ZyX-I If magic means boilerplate reduction, then I'm in favor or it. If something proves to be too 'magical' for the tastes of the community, we can always forbid it with a linter.

And where is the linter with such capabilities?

From the experience of powerline development no contributors are going to use linter. And many of them are even too lazy to read travis logs (though this may be because they are sometimes too verbose). It also applies to all other code, but meaning of "func 'foo', 'bar'" does not change if there is no whitespace between "func" and "'foo'": the negative contribution of the magic construct is worse in moonscript.

From what @leafo said, he would be working closely with us, so I doubt he would commit such a breaking change without giving us some support.

I can't consider that to be a problem. The fact that distributions dont package some software wont stop me from using it if I think it would be good.

It is the problem to most users. And it is definitely a stopper for me. Also unless we plan to distribute neovim via luarocks this means no automatic dependency resolution. If we do this means the same because e.g. libuv is not in luarocks. Increasing number of steps required to install neovim is not good.

—
Reply to this email directly or view it on GitHub.

And do not forget that to understand what is going on you need knowledge of both lua and moonscript. There are much more lua developers then moonscript ones so choosing moonscript is doing negative contribution to the amount of developers able to work on neovim.

[aktau]

How about this ? Those who are proficient in Moonscript can write in that, compile it to Lua and submit, and others who are good at Lua can write in that and submit them ? :smile:

I believe the lua that moonscript generates is a bit ugly at times, mostly because of the auto-generated variables. I wouldn't want to check that in to a source tree _unless_ it is with the express plan to rewrite it into better lua later. (kind of like a pre-refactor).

After carefully weighing the pro's and con's I've decided that I would need to _see_ a unit test written in lua and one written in moonscript, so that I can make a more informed vote. As it stand, I prefer lua, but I'm willing to give moonscript the benefit of the doubt if it makes our testing way easier.

[Gaelan]

Homebrew formulae can depend on luarocks packages. Not sure about Linux.

[ZyX-I]

When it comes to installing software there generally no such thing as Linux: there are only certain distributions. AFAIK all maintainers in all distributions I know will think about neovim installing moonscript on its own in place of depending on _their distribution_ package an abuse of their package manager system.

28.02.14, 19:11, "Gaelan" [email protected]":

Homebrew formulae can depend on luarocks packages. Not sure about Linux.
—
Reply to this email directly or view it on GitHub.

[jszakmeister]

@ZyX-I I'm certain that it can be arranged so that those with the dependencies already installed don't need need to build the bundled versions.

[gilligan]

Based on the concerns raised by @ZyX-I I'm personally strongly against the use of moonscript. Dependencies/packaging/added layer of abstraction. I did not even know moonscript until now. I don't see the advantages justifying this.

[ZyX-I]

No. RPM and debs do not use build scripts except for distribution maintainers with special debs and RPMs types not intended to be used by users. They do not build. It is why distributions are called "binary". So version is either bundled or there must be another package.

And this is worse abuse of package management system (of those distributions that do build: e.g. Gentoo) since deciding what to install is the job of package manager and not the package build script.

28.02.14, 20:02, "John Szakmeister" [email protected]":

@ZyX-I I'm certain that it can be arranged so that those with the dependencies already installed don't need need to build the bundled versions.
—
Reply to this email directly or view it on GitHub.

[jszakmeister]

@ZyX-I What I'm saying is as long as we can make using the bundled version optional (just like what was done for libuv), it's not a problem for maintainers. The issue will get fixed. No one wants to prevent good things from happening on the packaging front.

It'd be better to discuss other merits of moonscript vs. lua than to focus on the packaging bit, IHMO.

[marcusm]

@ZyX-I is dead on here. I am +1 for Lua. I have used Lua as an embedded language in several tools and even games. Lua works very well and is easy to understand.

[tbelaire]

I would also like to say that I feel like the tests are going to be read
more times than they are written. I agree that moonscript looks awesome to
write, but its not as easy as lua to read.

I do think that it'd be good to support moonscript files for plugins, where
I feel the loss of readability is a totally acceptable trade off.

I might change my mind if we saw some changes to moonscript 0.3.0 that
forced code to avoid the ugly parts.

I do think that whatever is syntactically valid will end up in the code
base.

Lua is a really nice, _very_ simple language.
On Feb 28, 2014 8:35 AM, "Marcus Martin" [email protected] wrote:

@ZyX-I https://github.com/ZyX-I is dead on here. I am +1 for Lua. I
have used Lua as an embedded language in several tools and even games. Lua
works very well and is easy to understand.

Reply to this email directly or view it on GitHubhttps://github.com/neovim/neovim/issues/207#issuecomment-36368668
.

[ZyX-I]

28.02.14, 20:28, "John Szakmeister" [email protected]":

@ZyX-I What I'm saying is as long as we can make using the bundled version optional (just like what was done for libuv),

libuv a) has packages in a number of distributions, including Gentoo and b) the only alternatives I know are maintaining similar library on your own like vim does (though it is not a "library", but code is more or less isolated) or simply scattering platform-specific #ifdefs all over the code.

it's not a problem for maintainers. The issue will get fixed. No one wants to prevent good things from happening on the packaging front.
It'd be better to discuss other merits of moonscript vs. lua than to focus on the packaging bit, IHMO.

I will try to write a summary below:

Pros:

1. better scoping
2. less verbose syntax
3. easier to write OO code
4. specifically easy to write tests from the template
5. author is easy to reach and is willing to help

Cons:

1. yet another abstraction layer
   1.1. slows down code
   1.2. requires more knowledge from the developers
   1.3. adds more places that may break
2. moonscript is not mature
3. easy to write code that is hard to understand
4. highly unpopular among developers compared to lua
5. not present in distribution repositories

I have also questions about tools that are to be asked before I put it in pros or cons (my bet it will go in cons): lint tool(s), debugging support (including static analysis if any) (if using lua debugging then how to map lua lines to moonscript ones), syntax highlighting support (vim, github, other editors and common highlighting libraries).

Hope I have not missed anything.

—
Reply to this email directly or view it on GitHub.

[tbelaire]

Just to clarify, where would moonscript be used?
Tests, anywhere else? The core runtime files? Plugins?

[ZyX-I]

Since moonscript translates to lua nothing can prevent plugin authors from using it. But I have not seen plans for adding new plugins at the first stage so you can assume tests, core or both. Since I was suggested to write VimL translator in moonscript it is core. And there were snippets of tests code so you can assume both.

28.02.14, 21:32, "Theo Belaire" [email protected]":

Just to clarify, where would moonscript be used?
Tests, anywhere else? The core runtime files? Plugins?
—
Reply to this email directly or view it on GitHub.

[notpratheek]

@tbelaire

See the 25th comment made by @tarruda or click here, it links to that

[tbelaire]

On Feb 28, 2014 9:43 AM, "ZyX-I" [email protected] wrote

Since I was suggested to write VimL translator in moonscript it is core.
And there were snippets of tests code so you can assume both.

Ah so we'd be coding parts of the actual core in one of the two, not just
runtime files or tests.

[egonSchiele]

+1 for moonscript

[commonquail]

I have no practical experience with neither Lua, MoonScript, nor CoffeScript. Lua, because I've never needed it for anything; MoonScript, because this is the first I've ever heard of it; and CoffeeScript, because I have very deliberately avoided it on the basis that it smells badly of a language I wouldn't want to maintain a code base in for any significant amount of time. It is my opinion that languages like CoffeeScript focus on the wrong things: productivity now versus productivity in six months.

[elentok]

@commonquail This is just my opinion, but I have to disagree about CoffeeScript long-term productivity,
From my experience working on multiple projects with a large coffee script code base (tens of thousands of lines) for about two years, it makes the code so much clearer and easier to read.

When I get back to code I haven't touched in several months it's much faster to get into than vanilla javascript code.

Haven't used moonscript much, but I've been using CoffeeScript extensively for the past couple of years and I just love it.

I think code should be as clean and readable as possible.

+1 for moonscript

[justinmk]

Lack of parentheses and braces does not make code more readable. That's really a superficial and arbitrary improvement, that may actually reduce readability insofar as it introduces ambiguity.

Also, tens of thousands of lines is not really a large codebase.

[jszakmeister]

On Fri, Feb 28, 2014 at 5:53 PM, justinmk [email protected] wrote:

Lack of parentheses and braces does not make code more readable. That's really a superficial and arbitrary improvement, that may actually reduce readability insofar as it introduces ambiguity.

Also, tens of thousands of lines is not really a large codebase.

Perhaps not, but it's comparable to what the test suite would be.

-John

[aktau]

For anyone that's interested in what busted + lua could look like, I made a pull request with some example tests for string-handling functions: https://github.com/neovim/neovim/pull/229

(direct link to the lua file)

[tbelaire]

Thanks. That's quite readable.

On Sat, Mar 1, 2014 at 1:09 AM, Nicolas Hillegeer
[email protected]:

For anyone that's interested in what busted + lua could look like, I made
a pull request with some example tests for string-handling functions: #229https://github.com/neovim/neovim/pull/229

Reply to this email directly or view it on GitHubhttps://github.com/neovim/neovim/issues/207#issuecomment-36420147
.

[lslah]

We shouldn't commit much code before we are able to write unit tests. We can't write any unit test before we've made a decision in this issue. Would be great if we can get this done sooner rather than later. I'd really love to start contributing some unit tests and other code.

[simendsjo]

I say it's OK to write code now, we just shouldn't pull the requests before
they include tests. Keeping the community active by writing and reviewing
code is still good.
On Mar 1, 2014 2:02 PM, "lslah" [email protected] wrote:

We shouldn't commit much code before we are able to write unit tests. We
can't write any unit test before we've made a decision in this issue. Would
be great if we can get this done sooner rather than later. I'd really love
to start contributing some unit tests and other code.

—
Reply to this email directly or view it on GitHubhttps://github.com/neovim/neovim/issues/207#issuecomment-36424114
.

[quark-zju]

+1 for lua. one can always compile moonscript to lua.

[dsawardekar]

@justinmk / @simendsjo I do not share these concerns about moonscript being abandoned, especially because it's very easy to write a 'transpiler'(I think vimscript wont be so easy since it seems to have an 'obscure ' grammar).

@tarruda With regards to the complexity the Vimscript grammar, I think @luke-gru might be able to help. Luke is the author of Riml which is a pretty nice ruby-esque language that compiles to Vimscript. He was able to implement a completely working OO layer on top it too.

In Riml, Luke left out Vimscript's ex-literals which is the most obscure part of Vimscript's grammar. They are treated as inline Vimscript instead.

@luke-gru I'm not sure how far you got into the ex-literal grammar, Maybe you could share notes with @tarruda. :)

[dsawardekar]

For tests, an RSpec like DSL is so much more expressive than writing asserts. This is the first time I'm hearing about Moonscript. But I don't mind the language at all. The example linked is much better due to the DSL.

[leafo]

For those concerned about the version number and maturity: I use arbitrary version numbering, not semantic versioning. As far as I'm concerned the language is mature. I'll change it to version 1.0.0 right now if that will satisfy you. I have no plans in my roadmap to add any syntax breaking changes. I'm fine with adopting semantic versioning, but I should have a milestone version number to differentiate between the two, e.g. the proposed 1.0.0.

For those concerned about a linting: MoonScript has a linter, but it doesn't do code style checking. It would be a nice addition. If coding style becomes an issue I see no problem writing something like that. MoonScript also has a code coverage tool.

For those concerned about adding an additional dependency: MoonScript has its own tools to bundle the project. Here's all of MoonScript ready to be statically included into your C/C++ program (sans dependencies): https://github.com/leafo/moonscript/blob/binaries/moonscript.h It's also easy to bundle it into a single Lua file, here's that: https://gist.github.com/leafo/9295119

And lastly, for those who talk of magic: I don't know what you are talking about. The grammar is well defined with no ambiguity (Because PEGs by definition can not be ambiguous :tada:). The language specification is _specific_. There is nothing magical about it. Just a set of translations to help you write Lua fast while keeping things organized. :wink:

[dpgailey]

+1 for moonscript

[ilAYAli]

The use of esoteric libraries- and languages (MoonScript, third-parties/*,...) is a bit concerning:

• Stability is uncertain due to limited test coverage .
• Too many unfamiliar factors might discourage people from contributing.
• Too many unknown factors makes debugging hard.
• The barrier for contribution is high as existing knowledge is limited.
• There might be limited motivation to learn something that does not have any personal relevance (school, work etc.).
• Code quality might be subpar as it takes time to master a new language(s)

+1 Lua

-b.

[ZyX-I]

@leafo

For those concerned about a linting: MoonScript has a linter, but it doesn't do code style checking. It would be a nice addition. If coding style becomes an issue I see no problem writing something like that. MoonScript also has a code coverage tool.

C code coverage?

For those concerned about adding an additional dependency: MoonScript has its own tools to bundle the project. Here's all of MoonScript ready to be statically included into your C/C++ program (sans dependencies): https://github.com/leafo/moonscript/blob/binaries/moonscript.h It's also easy to bundle it into a single Lua file, here's that: https://gist.github.com/leafo/9295119

Dependency managing was created not for continuing bundling dependencies inside a project. I also cannot say what is worse: moonscript bundled inside neovim or moonscript as an external dependency.

First means that neovim developers sign up for continuous job for tracking upstream updates.
Second means that neovim developers sign up for one-time job for convincing maintainers to add moonscript to their repositories.

And lastly, for those who talk of magic: I don't know what you are talking about. The grammar is well defined with no ambiguity (Because PEGs by definition can not be ambiguous :tada:). The language specification is specific. There is nothing magical about it. Just a set of translations to help you write Lua fast while keeping things organized. :wink:

Magic is not ambiguity from the parser point of view. It is ambiguity from developer point of view. I cannot trust any language where bar foo'abc', 1 and bar foo 'abc', 1 mean different things because it is a difference that is very easy to miss when reading.

I am also completely not good at counting levels of indentation. Especially not good if it is 2-space indentation. Python PEP8 at least uses 4-space indent. Bad they have not included an obvious nesting level limit as well (unobvious: with 4-space indent and 79-width line you cannot possibly have more then 19 levels and last half of the levels or so is unusable due to line breaks).

---

I have not heard about highlighting and indentation scripts. I definitely do not have them in my vim. Neither they are in www.vim.org. I have found one on github among your repositories though, but this is going to do _yet another_ negative contribution to the number of things one must do before starting writing tests for neovim: before using moonscript vim should be set up.

Github seems to have a decent highlighting though.

[ZyX-I]

Note about indentation: I am not saying _moonscript_ requires 2-space indentation. But 2-space indentation was chosen for neovim project and is currently used almost everywhere in it, including example test/unit/*.moon files.

[ilAYAli]

@ZyX-I Completely agree regarding indentation level.
There has been a lot of talk about code style, but all the respective styles (except for Python) has been presented with the option of only two spaces which I feel is insufficient to emphasise indentation.

[ZyX-I]

@badeip In C you have some visual indication of where block starts and, especially, ends other then indentation. So it is though not the best variant to my taste it is still readable. Lua also has end tokens. Moonscript does not.

To be fair Linux Kernel style does not use 2-space indent: it has 1-tab 8-cells indent.

[cespare]

Wow, such FUD.

Dependency managing was created not for continuing bundling dependencies inside a project. I also cannot say what is worse: moonscript bundled inside neovim or moonscript as an external dependency.

Explain why bundling moonscript in neovim is a problem. It's not very big. It's trivial to drop in as a single file.

First means that neovim developers sign up for continuous job for tracking upstream updates.
Second means that neovim developers sign up for one-time job for convincing maintainers to add moonscript to their repositories.

Why do the maintainers have to track upstream updates?

These issues go away if you just bundle moonscript in neovim.

Magic is not ambiguity from the parser point of view. It is ambiguity from developer point of view. I cannot trust any language where bar foo'abc', 1 and bar foo 'abc', 1 mean different things because it is a difference that is very easy to miss when reading.

This is just personal preference. This is entirely subjective. You can construct easy-to-miss programming errors in any language. With conciseness comes increased possibility of mistakes being parseable as incorrect code -- see python vs. ruby, javascript vs. coffeescript, java vs. scala, etc. This is a tradeoff every language makes.

---

I don't even care about Lua vs. Moonscript, but this thread is now full of strong opinions about them from people who haven't used Moonscript and it's not making progress towards a decision. I think @tarruda should just use Moonscript if he's comfortable with it; I'm sure that further on down the road if it proves to be problematic he'll recognize that and change as necessary.

[ilAYAli]

@ZyX-I I have been programming C/C++ for ~ 15 years, and prefer a more explicit indentation.
Deeply nested indentation should be avoided, so only using two characters is not very beneficial.
I don't really care though, I just found it strange that style was up for debate, but not indentation.

[simendsjo]

@badeip: There's no way to use > 2 indentation in the codebase yet. I've been working on a file with 15 levels of indentation now... Thats "only" 30 characters with 2, but 60 with 4.. We should revisit the indentation debate in a couple of years :)

[ZyX-I]

@simendsjo Original vim was 4-shift space+tab indentation with 80-columns limit. So I would not say “no way”.

[1100110]

lua, not moonscript

[simendsjo]

@ZyX-I Did you mean original vi (-m)? Because this codebase has a _lot_ of indentation.

[ilAYAli]

@simendsjo 15 indentations! I guess using only two spaces makes sense in that wicked context.

[ZyX-I]

Why do the maintainers have to track upstream updates?

Upstream updates mean things like bug fixes. They have to be tracked.

This is just personal preference. This is entirely subjective. You can construct easy-to-miss programming errors in any language. With conciseness comes increased possibility of mistakes being parseable as incorrect code -- see python vs. ruby, javascript vs. coffeescript, java vs. scala, etc. This is a tradeoff every language makes.

This is entirely subjective only because nobody is trying to conduct a good experiment based on rules for conducting psychological experiments. I do not have resources to conduct it so I just say my opinion on the matter and so do other people complaining about “magic” here. Given how many languages have more traditional rules for calling functions (ruby and F# are something like the only exceptions, maybe also CoffeeScript (I checked languages in tiobe index and CoffeeScript is not there though they claim it is tracked as well)) I am almost sure in the results. None of the languages I know have syntax where space before the first argument matters.

[ZyX-I]

Did you mean original vi (-m)? Because this codebase has a lot of indentation.

I mean the one maintained by Bram Moolenaar. Though I have not checked where exactly 80-characters limit was being broken (at least forward function declarations do not follow it).

[simendsjo]

@ZyX-I So someone has reindented from 4 to 2 in this codebase? Good call in that case, otherwise my entire screen would only be spaces...

[ZyX-I]

03.03.14, 02:11, "simendsjo" [email protected]":

@ZyX-I So someone has reindented from 4 to 2 in this codebase? Good call in that case, otherwise my entire screen would only be spaces...

Someone is @tarruda. And I would not say so as the script used for this task has screwed up readability in a number of places: e.g. there are things like

case C:          foo = ...;

(note: executed line on the same line as case and it has a number of spaces before itself). You can see this at least in eval.c.

I do not know what exactly script did so it may appear that there was no such insane indentation level, but it appeared after script was run.

—
Reply to this email directly or view it on GitHub.

[gryftir]

edit:
Lua > MoonScript

end edit:

So Lua interfaces with C/C++ really well. I know much less Lua then python or perl, but I'd rather use Lua for scripting logic. More to the point the project lead @tarruda has said that those are the choices he likes, and I don't want to push choice he will be deeply unhappy with.

My feeling is that Neovim will benefit more from a broader variety of people hacking on it, and that means that an older language with a _bigger user base_ is going to be advantageous. More people know Lua. More people have heard of Lua. There is more documentation, books, etc. It will make it easier to get people involved and contributing in the future. I don't know that Moonscript is going away, but I don't think it's going to surpass Lua in popularity or familiarity.

There are 5600+ lua tagged questions on stack overflow, and 2 for moonscript. Compare to Python, C, ruby, or even perl for more popular languages, and elisp, forth and smalltalk for less popular ones. I consider that a rough metric for how many people are learning/using the language now days.

Lua is already somewhat obscure, at least for english users, but not totally so. And I think there is more tooling around it.

Given that MoonScript apparently compiles to Lua, but the reverse is probably not true, using Lua allows us to include any MoonScript programmers as well as the broader Lua base. @leafo is there a Lua to MoonScript converter? You already said there isn't a code style checker.

So my vote is for Lua.

[knubie]

+1 for moonscript, it's just lua but better.

[daGrevis]

+1 for Lua. What if Moonscript dies after a few years and all tests for new Vim are in language that's no longer maintained and no one really knows how it works anymore?

[UncleBill]

+1 for Lua. It's pure.

2014-03-03 16:56 GMT+08:00 Raitis Stengrevics [email protected]:

+1 for Lua. What if Moonscript dies after a few years and all tests for
new Vim are in language that's no longer maintained and no one really knows
how it works anymore?

Reply to this email directly or view it on GitHubhttps://github.com/neovim/neovim/issues/207#issuecomment-36491364
.

[darthdeus]

I have to admit that after reading this thread I've lost a bit of faith in the project.
Just because there are a lot of people out there using vim, and a lot of people write
plugins for vim, it doesn't necessarily mean that those people will just jump the ship
and start using neovim. There are obstacles on the way and we should be trying to minimize
the friction and make it as easy as possible for people to hop on board.

I can't speak for Lua/Moonscript as I've never really used it, but I do have a lot of experience
with JavaScript and CoffeeScript.

At first I really loved the benefits of CoffeeScript, it has a very nice and compact syntax
and provides a lot of shortcuts for many common things. But there's a huge price to pay for that.
It is not just JavaScript, in a same way that Moonscript isn't just Lua. There is a non-trivial
overhead in learning the language, learning the build tools, learning how to debug it, learning
how it transpiles and what are some common patterns to avoid. The language itself is also more complicated,
which means it's easier to write bad or non-idiomatic code.

There's one last thing we should also consider. A lot of people have strong opinions,
and just by reading this thread I can see that a lot of people really don't like the idea
of using Moonscript. This means that if we decide to use it, we'll instantly lose
a lot of potential contributors, just because they won't be willing to learn/bother with Moonscript.

Additional complexity with packaging is just one more reason to use plain Lua.

tl;dr: Please use Lua and save yourself a lot of trouble down the road. Having a bit of syntactic
sugar might seem like a good idea now, but it will cause problems down the road.

[aktau]

After having written some tests in lua myself (mentioned earlier, see here), I now also feel confident in saying that my preference goes to pure lua, there's not a lot of extra boilerplate in my opinion, just some lines here and there which in some cases even improve readability (just my opinion). It was easy and quick writing in lua, the language just makes sense (I'm not a lua expert by any stretch of the imagination). I think it will maximize developer uptake as well. God knows, we need tons and tons of unit tests so that we can start making more invasive changes.

Moonscript being abandonded didn't phase me at first thought, from the comments of the author here I think it stands a chance of being maintained for at least a couple of years more (say, 5). But we want neovim to be long-lived. 15 years or more. That's a really long time, and I think a quite well established language like lua stands a better chance. Not just for the fact that prob(moonscript dying) >= prob(lua dying) by definition (moonscript depends on lua), but also because there's a (university) team behind lua, an alternative implementation (luajit) and a pretty large community (many programs have embedded lua: wireshark, ...). At this point I would rate the chances of lua surviving to be higher than for example node.js or golang, and at about the same as python, which is pretty good!

That said, I really like some things about moonscript, such as the local by default thing. It's the main cause of carpal-tunnel with lua. The other arguments are a bit less convincing for me. The object-orientation, at least for tests, doesn't seem like a big deal: tests are mostly imperative code, and should stay that way to be readable. I actually _like_ the imperativeness of lua, it makes it more of a get down and dirty language. Don't think, just write.

As many have said, moonscript is an extra step. Just like there's no coffeescript developer that knows nothing of javascript, there won't be any moonscript dev that knows nothing of lua. It might become a bit easier to write moonscript than it is to write lua _after_ learning both fully, yet I don't think that up-front cost is a good tradeoff.

Lua is immediately readable even by those uninitiated in the language. What this means is that tests can be read and verified by (C) programmers that don't know lua, this is a big boon. This community has affirmed that reviews of other peoples code are required, and we've been doing great at that. I have to admit that the first time I read @tarruda's tests, I took me a bit before I grokked all of it, just because of my unfamiliarity with moonscript. It provides handy shorthands, but that also makes it more opaque (less readable).

I could ramble on and on about it, but the crux is that lua just feels right in my gut, and I've been able to say no to the forbidden fruit that moonscript offers.

+1 lua.

[tarruda]

Time to end this useless debate. We are going to use moonscript and here are my reasons:

• It takes common Lua idioms and turns them into language features, removing the need for libraries and boilerplate.
• It makes code more easier to read
• It makes code more easier to write
• It has no performance penalty compared to lua. Just a small overhead of compiling and program startup, which can be removed by pre-compiling during build stage. Either way it all happens automatically and no one will notice it's happening.
• As the main responsible for the project, I will be writing most of the code, and moonscript makes me more productive

I'm still very new to the idea of managing such a big open source project, so I'm sorry for making the mistake of opening this up for votation only to take the decision back into my hands. The truth is, no matter what path I take, there will always be people who are unhappy about it, so I will just choose what I think it's best for the project.

The decision is final. If someone thinks that dealing with moonscript unbearable, just don't look at it or pretend it doesn't exist. I bet that there are many vim users who never use vimscript, despite it being an integral part of vim. Neovim will be extensible in any language, so you won't be tied to moonscript, lua or vimscript.

[simendsjo]

@tarruda: Ok, you've established your role as a dictator :/
Let's hope this is the right decision.

There's a couple of things I'd like to see resolved quickly:
1) Choosing documentation system and integrating with the makefile
2) Finishing the document on how the testing should be done

[cweagans]

If it turns out that this bites us in the future, I imagine it will not be difficult to convert from Moonscript to Lua. I feel that this was not the right decision, however, @tarruda is the project lead and we should defer to his decision (especially since this conversation was largely a matter of opinion).

[tbelaire]

I'm just happy we've reached a decision. It wasn't that productive a
discussion, though hopefully some of the concerns are addressed in the next
version of moonscript.

[aktau]

If it turns out that this bites us in the future, I imagine it will not be difficult to convert from Moonscript to Lua.

I think it will be a bit of work, but definitely doable! What I'm more concerned about is if/when/how it will be known if it was the right or wrong choice? How do we know that for example a dearth of testing PR's is because of the choice of language?

To be perfectly honest, I think a compromise would be best: allow people to write tests in either lua or moonscript. They're compatible anyway! The only thing that would have to change is the testscript, as @ZyX-I illustrates in his luaviml branch we would just have to add one line:

busted --pattern=.moon ./test
busted --pattern=.lua ./test

Yet if it's moonscript exclusively as @tarruda seems to have decided, that's fine and we should carry on with more interesting endeavours.

[Gaelan]

Remember, if for whatever reason we want to go back to Lua, we can just compile all of the MoonScript to Lua and put the Lua in its place.

[apenney]

Like many of the other people here I'm excited to see @tarruda be willing to step up and make decisions. While it's important, and nice, to get community input it can only be one of a number of factors that goes into a decision like this and people have put real money behind @tarruda to see this refactoring happen.

[hems]

it's 2016 do people still use curly braces and type "end" ?

i heard that is a vintage hipster thing.