Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

lua or moonscript #207

Closed
aktau opened this Issue · 103 comments
@aktau
Collaborator

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
Owner

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

@tarruda
Owner

@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
Collaborator

@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
Owner

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

It seems that busted works without plain lua, too.

@aktau
Collaborator

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
Collaborator
@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
Owner

@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
@tarruda
Owner

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

@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
Owner

@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:

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
}

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
Collaborator

@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
Collaborator

@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
Owner

@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
Collaborator
@aktau
Collaborator

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
Collaborator
@jszakmeister
Collaborator

@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
Collaborator
@jszakmeister
Collaborator

@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
@ZyX-I
Collaborator
@tbelaire
@ZyX-I
Collaborator
@tbelaire
@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
Owner

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
Collaborator
@aktau
Collaborator

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: #229

(direct link to the lua file)

@tbelaire
@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
@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:

@ctwiz

+1 for moonscript

@badeip

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
Collaborator

@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
Collaborator

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.

@badeip

@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
Collaborator

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

@badeip

@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
Collaborator

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

@badeip

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

@ZyX-I
Collaborator

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
Collaborator

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
Collaborator
@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
@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
Collaborator

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
Owner

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.

@tarruda tarruda closed this
@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
@aktau
Collaborator

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.

@a13xb

@simendsjo And this is fantastic news, if you ask me. I was afraid the project would lose direction in the cacophony of many dissenting voices so early in the life of the project. Strong leadership is vital.

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

@jdavis jdavis referenced this issue from a commit in jdavis/neovim.github.io
@jdavis jdavis Add section on dropping MoonScript b0b079b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.