etiene

Interesting work!

Thanks!

is there a way for users to report/flag bad suggestions?

For the word hints there isn't a way yet, but this is a great point, I should add it in the future! For the sentence examples, it depends on what you mean with "bad". There's a "..." pop-up menu with an option to flag the example as incorrect or report it (for being inappropriate, abusive etc).

edit: For both cases, it is also possible to shuffle / fetch another suggestion.

There is also another side to that question. If you were a pizza maker and you loved what you did, would you sell your pizza to someone who wishes you and your loved ones die? Maybe that would make you uncomfortable.

These situations are usually framed on how it bothers us, as outsiders to these companies. We tend to put outselves only in the shoes of the pizza consumers, neither the evil entity, nor the pizza maker. But these companies have workers, who put their labor into some product, only then to see that product in the hands of entities that go directly against their core values and existence. I find very understandable that they are mad. Shouldn't we also question these problems from this perspective?

When there are many employees uncomfortable with things like this, maybe it's not a necessity, but I still think it's very nice for outsiders to support them.

However that was in the case where the product is something innocuous, like pizza. Because you know, it might also be case that the product is actually enabling or helping evil to be evil. Such as "being part of the critical toolkit to conduct invasive surveillance". So getting mad could be even more substantiated in those cases.

Oh, I understand your question now. From an European perspective, there is hardly any reason to hold our governments standards as having the moral grounds to establish what's the most efficient way to act in ethical issues like this. Perhaps relative to the USA, yes, so you could be correct that certain government's ineptitudes have a correlation with how creative people get to get heard.

Either way, the whole question of dealing with ethics from the efficiency perspectice is one that bothers me and a whole discussion in itself.

Sure, 'should the tax rate be 25%' seems like an unimportant discussion for companies to debate internally. Do you think all political questions carry similar weights of debate importance or that some questions might be different?

Lua was made specially for non programmers. I think it is really intuitive and easy. I agree with the comment that perhaps understanding optmisation details is hard. But that's hard in every language.

The talk was great! I'm incredibly impressed with the benchmarks.

Here is a quick link to Pallene's github repo as well, since it's a bit hidden in the paper: https://github.com/pallene-lang/pallene

"I took a sabbatical". If the company has a problem with that they are not a good place to work anyway.

Given that, looking for jobs sucks, a couple of rejections can easily make people feel really down. So after some failed attempts I know it's hard to keep the mindset that you are also interviewing the companies, but do try to keep in mind that you deserve a good work environment!

There's an excellent book about the software community in peripheral areas that talks about Lua's development

https://mitpress.mit.edu/books/coding-places

I don't like perl a lot exactly because it's easy to make it hard to read, but I gotta give that CPAN is the best language specific package manager I've ever encountered.

My thoughts exactly on the difference on underrated and underused. Lua is quite widespread in the industry in sneaky ways. It just doesn't get the love it deserves.

+1 to Lua, it is my favorite interpreted language. I like that the design is extremely clean and consistent, not to mention it is way faster than the alternatives.

I have used torch without issues but that was a while ago. It looks like Lua Torch was sort of deprecated in favor of PyTorch

It's not my job to convince you of anything. But while I agree with the lack of universal standard, PEP8 is great, I disagree with all the rest.

The changes between Lua versions are nothing like the abysmal difference between python 2 and python 3. Not only 5.1 code is very likely to run on 5.3 and JIT without issues, if there are ever any issues they are always very minor and solvable with requiring a simple compat library.

As someone who has done a lot of Lua and Javascript, I had always had the feeling that coding in Lua feels better by orders of magnitude. It's a way more consistent language.

As a member of the Lua community I cry every time...

But congrats on the hard work! I've been planning to try it out for a while now and the amount of resources and docs is great.

seems wonderful! just requested a membership :)

I've been part of some online tech communities for women, but I found they were too US-centric and it was difficult for me to obtain value from it, hoping Leap will be different

Yea, I was hoping to see it there on the comparison list. I guess it fails some criteria.

I don't understand... This doesn't look like a programming language. It looks like a new VM for the Lua language, but with batteries included.

There's a difference between "language" and "language implementation". With this you have a new language implementation, but not a new language per se.

Furthermore, I think it could benefit from marketing as batteries for Lua, instead of a new thing Lua compatible. Your runtime would benefit from things like Lua's package manager (LuaRocks) and getting the existing Lua community to try this?

This is true, but the reason is just people already knowing python / python being more popular. Lua is a much simpler language than python or julia though, I'd absolutely still recommend it for data scientists who are new to programming.

If you compare LuaJIT with PyPy or Numba, the “much faster” argument will simply not be true

Source? AFAIK it does hold true. Last time I benchmarked those, LuaJIT was significantly faster, with PyPy almost being on pair with vanilla Lua, due to Python being a much more complex language and harder to optimise.

Using the C api instead of the FFI is slower in LuaJIT than Lua and vice-versa. So there are still optimal solutions for each one.

Do you think Roberto Ierusalimschy is confused about that ?

No, of course not. I think you are. You are clearly misinterpreting his words. I will repeat, (PUC)Lua is not compiled to machine code, but to an intermediate bytecode form. Those are completely different things, and what I said does not come in conflict at all with the quote you took from PiL, so I don't know what you are confronting me about.

Lua is not compiled to machine code. It compiles to an intermediate bytecode, which is then interpreted. So you could say it is a VM. Also bear in mind, LuaJIT is not Lua. It's a different implementation.

I guess you misinterpreted my comment. I didn't imply there are no reasons to compare C and Ruby. I said the reason is important and the way you portray that, and the way you portray your results, changes things.

Are they likely to be expert in all those programming languages?

No, but again, I take paper results very seriously. Misleading results are bad for science, period. Here is an example of more rigorous research: https://arxiv.org/pdf/1602.00602.pdf

If Lua wasn't included would you complain ?

Maybe I would, who knows. I did also mention in another comment it would be nice if Julia was there. It depends how relevant they are for the research being conducted. As a language used very often in microcontrollers, Lua is very relevant for energy efficiency research. I don't know anything about Forth, but I wouldn't just dismiss people saying it should be there with "then contribute forth algorithms to the benchmarks game yourself".

Firstly, the paper separates languages into compiled languages and interpreted languages to begin with. So I was expecting it would follow this pattern correctly.

Secondly, why would you compare the performance of C and Ruby, for example? Ruby is bound to be slower for design reasons. Doing it to say "Look, C is fast!" doesn't mean anything. There are different reasons one would compare C and Rust, or C and Ruby. The way the results are displayed and what it tries to convey is very important.

If you're not making a baseline, or being very clear, etc. then it's just misleading to have a benchmark portraying Javascript as faster than Ruby, Python and Lua. Either you put those into their correct classifications clearly, or you compare it with LuaJIT, PyPy, Julia etc.

If your intention is not to make a good comparison, then sure. I've seen other papers on language implementation and benchmarks, and researchers were way more careful than this, individually inspecting the algorithms they were using.

I happened to spot a problem on this one on the Lua part and also on some other parts concerning how they classify things, because it happens to be things I know more. I'm not going out of my way to look for problems in the rest of the paper because I'm not a reviewer and I have better things to do.

But if I was the one way conducting this academic research, then I would want the results not to be bogus. The difference here is this is not a blog post about some bullshit comparison someone is making. If that was the case, then alright, if public contributed algorithms failed to represent exactly what was being looked for, why not go for whatever is out there. I just expect a more rigorous procedure from academics.

This is insane. I've actually been looking to reduce my work hours to about 30, because even 40 seems too much. Having had a couple of burnouts before, I want my life to be more than my job, and I truly believe this would make me better at my job in the long term. After a day of full time work I almost never have the energy to do some of the other things I want to do. I want to be able do more open source, learn a foreign language or a musical instrument, spend time with my partner, study some new cool technology, do some exercise etc. I was very disappointed to see a big name in the industry to promote exploitation like that.

Oh yes, that is true. But the person making the benchmarks should be aware of that and either look for better matching algorithms or implement them themselves.

Because they're "different families" of language implementation. A Just In Time compiler is a compiler. It looks like an interpreter, but it compiles the code to machine code and runs it.

The industry standard in Lua is to have multiple Lua states doing stuff. A different approach, but it is there

5. I wonder which implementation of Lua they used. Lua can be pretty fast, one of the fastest dynamic languages out there.

Apparently 5.3, but I am very skeptical of these results. Also the way the data is organised is very weird. One should not compare a JIT compiled VM (JavaScript) with interpreters (Lua, Python, Ruby...). An honest approach would have used LuaJIT, PyPy etc. or separated the languages into "families" better. Not to mention the choice of algorithms they used. Some of the algorithms in the benchmark game have many flaws.

As it was already stated in this thread, some of the Python ones were multithreaded but the ones in Lua weren't. Why? In a different benchmark I've seen algorithms using C wrappers for Python, but not in Lua. While I understand wrapping C and multithreading reflect the industry use in Python, so they do in Lua. Benchmarks are useless if you are not consistent in the implementations of the things you are comparing with. It disgusts me, to be honest, when I see benchmarks comparing JIT compilers with vanilla Lua just to say "hey we're faster", as LuaJIT does not even exist. It looks like pure dishonesty. In the case of this paper in particular, as they do not represent any language, it strikes me as lack of research / understanding.