On a previous project I had a similar issue.
The application developers fiercely resisted our choice of
using Lua. As best I could figure out, this was all “I don’t
want to learn a language that won’t help me get my next job”.
You might run in to this form of resistance.
We had two real counter arguments
1) licensing meant that Python, Java, (the app developers
favorites) etc we’re not options and
2) PiL has “all you need to know about Lua” and it’s like
1/4 the size of the equivalent Python, etc, books from
O’Reilly. In other words, “Lua is easy”.
Our app developers became reasonably proficient in Lua in
about a week, learning the library & environment my team
was developing took another week or so
With the addition that these advanced things are not
mandatory for core proficiency in writing basic applications
I would also add that app developers might be assuming that
the compiler does a lot of optimization, etc. PUC-Rio Lua does
not do any optimization.
This was an issue in my old project. The app team said
that the Lua version of their code ran 50-500x slower than C.
I spent about 2 days getting that to 5-10x slower. I just
did some basic optimizations that we all learned when we
started programming (back in the dark ages).
(The app developers really didn’t like me or Lua after that
... but that’s another, nontechnical, story :-)
Yes - ish
If Lua will be running on some standard cpu with an OS of
some sort, etc, and you’d have things that look like function
calls that actually send data into the FPGA to do its magic.
The project I was on did sort of the same thing. It worked
well ... but you need to put time into figuring out the
programming model for the lua apps and the interfaces that the
model requires. In addition you need to put a lot of time
into designing the api between the Lua apps and the special
functions embedded in the FPGA.
All were rehjectwd because of size/performance issues and/or
the license being unacceptable