Re: ActiveState seeking Lua community feedback

[Eric Wing <ewmailing@...>]

On 11/1/16, Jeff Rouse <jeffr@activestate.com> wrote:
> *
>
> Hi all,
>
>
> At ActiveState we feel Lua has a bright future in a variety of
> application areas (IoT, embedded scripting, and many others), and we are
> looking for ideas on how to support the community, increase adoption and
> help enterprises utilize the language more effectively. I’m proud to say
> that in 2017, we will be providing a community- and enterprise-ready Lua
> distribution on a variety of platforms, shaped in part by the feedback
> we receive from the community.
>
>
> At ActiveState we have been in the open source tools and languages
> business (Python, Perl, Tcl) for almost 20 years. We also build
> developer tools, which are our Komodo Edit (open source) and IDE, which
> has basic Lua support, and we are actively making further Lua
> development improvements in those products.
>
>
> If you would like to ask any questions or provide thoughts on where we
> can best help the Lua community, feel free to respond to this thread,
> email me, or sign up to our mail list (http://www.activestate.com/lua)
> for advanced notice of when our distribution is available. We look
> forward to hearing from you!*
>
> Cheers,
> -JR
>


Hi Jeff,
I was introduced and used ActiveState Perl in the late 90’s. I was
absolutely blown away by the Perl debugger you guys had. It has left a
lasting impression on me.

Unfortunately, for me at the time, our development environment was
Solaris, and ActiveState only worked on Windows at the time. I did
some hoop jumping to make some of our Perl modules cross-platform
capable so I could do isolated testing/debugging with ActiveState, but
we were doing things tied to custom hardware (phones and satellites),
so the entire environment could not be brought over to Windows.
Ultimately, ActiveState Perl was cool and useful for debugging small
modules, but not overwhelmingly useful to us because ActiveState did
not support our platform. And I couldn’t get my team to buy into using
ActiveState Perl themselves because the work involved making stuff
work on Windows was a pain.


Back to the present and Lua, I would warn you about the same kind of
problems. Even more so with Lua, Lua’s typical usage case is embedded
in larger systems, and can be tied with a lot of platform specific
libraries. The video game industry is one good example, where Lua is
used to provide a scripting interface to a core engine written in
C/C++ which has a degree of platform specific things (graphics APIs,
input systems, etc). And many of these engines are cross-platform. And
in particular mobile is a much bigger concern as mobile now makes up
about half of the video game market.

I gave a talk at the Lua Workshop which talked a little about how
hostile Android and iOS are in terms of conforming to standards which
we sort of take for granted now on desktops (even Windows). Some of
these things require some modifications to Lua to deal with well.


So I think whatever ActiveState is planning for Lua should take into
account these issues, particularly embedding, cross platform, and
dealing with slightly customized Lua’s. (Other people have mentioned
LuaJIT so I'll skip that.)



As far as libraries, some people mentioned GUI libraries being useful.
I want to plug IUP. (I also briefly mentioned it in one of my talks.)
It is made at the same university as Lua. It is a cross-platform,
lightweight, native GUI toolkit, designed with the idea of languages
being bound to it. So of course, Lua is already a first class citizen
with IUP. It doesn’t try to be a kitchen sink of all things (e.g.
network, data structures, etc.) but instead just focuses on native
GUIs, which helps keep it lightweight and maintainable. It’s major
Achilles Heel is that while it supports native Windows and has GTK and
Motif backend for most Unix systems, there is no native Mac Cocoa
backend. But this is something I’m hoping can be fixed. I started
writing a Cocoa port in my (theoretical) free time:
https://github.com/ewmailing/IupCocoa, I also see this as a stepping
stone to an iOS backend and then an Android backend.

Since you asked about where you could put resources to make a
difference, you could really make IUP for the remaining platforms
happen. Also, since you are cross-language, since IUP is designed for
language bindings in mind (its entire interface is pure C), you can
also make this available for your Perl, Python, and all your other
products.


I spent some time with wxLua with Cocoa, GTK, and Windows many years
ago. It was a fairly large and complicated system to deal with. I find
Qt (and not even with Lua in the picture) to be even more daunting,
and it isn’t even native GUI. Since you addressed the concern of being
able to maintain something, I suspect your engineers would probably
come to a similar conclusion for these, that they are too big and
probably not something you guys want to venture in to. I would suggest
that IUP is small enough and useful enough that your engineers might
see it as plausible. (As a data point, I recently did a tiiny Qt app.
After fighting a ton of platform specific bugs in the SDK, it was
about 60MB of Qt binaries on my Mac. And it failed to work on a
Raspberry Pi due to the way they try to use OpenGL. I wrote an
equivalent IUP program. The IUP library was about 800KB.)

Thanks,
Eric