Lua application programming (Big message)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua application programming (Big message)

Joao Von
Hello folks. Is everything okay with you? I hope everything fine.

I want to obtain a Lua community help about serious Lua application programming.

 I watched Hisham´s lectures on programming Lua applications on Youtube (LuaConf 2017), which led me to try to get some help on this subject. I found very interesting his vision of how to program Lua in the form of libraries, but I still have a certain difficulty in translate this into my projects (and find LOA references in internet).

I have been developing some applications (with various sizes) in Lua at University of Campinas in the O&G area and I contacted (when I worked to a oil company) with the development of a big Lua application. I knew some members of the development group and as it was a large application, programmed 100% in Lua, generated a huge effort of code control, revisions, etc. But this was a long time ago, and today I miss some references that would guide in a proper way to develop large code in Lua, so that it had a more solid architecture.

As I did not graduate in Computer Science, but in Engineering, so I had to improved my knowledge through complementary readings. My beginning with Lua was greatly simplified, based on knowledge of structural programming for Basic and Fortran. But due curiosity and need in the new job at university, I started (re)programming in Lua with the Java-based object orientation paradigm, using a lot of Design Patterns (GoF and GRASP) concepts.

The gain in the quality of the code was immense, because I got “full documentation” of the code, low cohesion and high coupling in the classes (allowing to expand very quickly), greater clarity in the structure of the program, in short, many benefits (besides getting faster by to make time measurements via profiler and removing unnecessary things). 

But thinking Lua only in OO breaks down a little bit the essence of language, which in some moments "claims" for a light way of programming. As an example: I implemented an ArrayList (Java type) to encapsulate lists. It has become the most frequent object in large code, but staying instantiating always seems to me a waste of processing time (which thousands begin to count) within functions that call ArrayList locally. It seems like a not optimized code. On the other hand, the use of simple Lua table is too generic for a serious programming (Anemic Object would be the option?).

I keep thinking about the gain between defining what part of the code should be written in the structural paradigm and part of the code should be written OO. But how to live with both at the same time seems not so simple. Or even the functional paradigm ...

These are doubts of this type (and others - how to organize the modules efficiently - error management - always gives problem when I fall into an exception - etc).  Is there any book or reference that would help clarify these points? There are good books of Lua (I have the main ones), but the heavy work is not explained in the details.

I found something in internet pages, but it's still a long way to go. Unfortunately I do not have access to large codes of applications similar to mine, which would be a good way to grow in language and help spread here at university.

I really like the language (besides the appreciation for being native), but I have a lot of difficulty in extending its use in my group (basically Java and C# programmers). Generally I used it via the command line, without compiling the code - which gives me a greater dependence on own libraries ("my world", which has been cool to understand computer science).

So, I don't use LuaRocks... I feel apprehensive about having difficulties compiling, etc. I don't even use the interface with C (and derivatives), because the performance issue has not yet reached me (and because I find C too annoying).

Many times I do integrating with other tools (JS, GNUPlot, numerical simulators, ...), whichever is easier to generate quick results. More or less similar to the applications Hisham commented on in an application for power networks.

One point Hisham commented is the use of IDEs. I use LDT, but unfortunately it's running out of support, and a lot that could be added, like programming aid tools, etc. I downloaded ZeroBraine, but the LDT is more elegant (due Eclipse framework). And I also have versioning via git, by the help of my group staff.

Anyway, thank you for your attention. It's nice to talk to people who knows what you're talking about, in a world dominated by programmers for Java, C++ and Python... 

Sincerely yours,

João Carlos

Reply | Threaded
Open this post in threaded view
|

RE: Lua application programming (Big message)

Tom Becker

In my experience, the most important best practices for programming at scale are source control, modularity, and automated testing.

 

Source control should need no explanation, but it needs to be said, because many programmers get started without using source control and never get around to using it. Also, the quality and affordability of source control systems has improved dramatically in recent years. There are multiple competing cloud hosted Git services with pull request workflows that are essentially free for most projects. There is no excuse not to be using source control.

 

The Lua module system is perfect for modularity. Modules abstract dependencies. The Lua module system enables service-oriented architecture, dependency injection, and programming by composition. It may be hard for people to appreciate how powerful and useful the module system is, because it is so simple.

 

Automated unit testing requires modularity. The code under test is isolated by replacing its dependencies with stubs or mocks. A unit test framework and a mock framework are helpful. If you don’t use an off the shelf framework, be aware that you may end up writing one. The main thing is to write automated unit tests at the same time as the code, or earlier if possible (Test Driven Development). Code coverage of 100% is achievable. If a line of code cannot be unit tested, it should be considered unreachable and deleted.

 

Automated integration testing is a huge area. Techniques include simulation, instrumentation, fault injection, fuzzing, and A/B testing.

 

HTH,

 

Tom

 

 

From: Joao Von <[hidden email]>
Sent: Wednesday, August 19, 2020 2:29 PM
To: [hidden email]
Subject: Lua application programming (Big message)

 

Hello folks. Is everything okay with you? I hope everything fine.

I want to obtain a Lua community help about serious Lua application programming.

I watched Hisham´s lectures on programming Lua applications on Youtube (LuaConf 2017), which led me to try to get some help on this subject. I found very interesting his vision of how to program Lua in the form of libraries, but I still have a certain difficulty in translate this into my projects (and find LOA references in internet).

*******************************************************************
IMPORTANT MESSAGE FOR RECIPIENTS IN THE U.S.A.:
This message may constitute an advertisement of a BD group's products or services or a solicitation of interest in them. If this is such a message and you would like to opt out of receiving future advertisements or solicitations from this BD group, please forward this e-mail to [hidden email]. [BD.v1.0]
*******************************************************************
This message (which includes any attachments) is intended only for the designated recipient(s). It may contain confidential or proprietary information and may be subject to the attorney-client privilege or other confidentiality protections. If you are not a designated recipient, you may not review, use, copy or distribute this message. If you received this in error, please notify the sender by reply e-mail and delete this message. Thank you.
*******************************************************************
Corporate Headquarters Mailing Address: BD (Becton, Dickinson and Company) 1 Becton Drive Franklin Lakes, NJ 07417 U.S.A.

Reply | Threaded
Open this post in threaded view
|

Re: Lua application programming (Big message)

Joao Von
In reply to this post by Joao Von

Thank you for your help, Tom.

Source control is fine. I suffered a lot with new versions that “crashes on the fly” and forced me to find where the problem was. Source control is frequent in our IT group and I agree (now) with this practice.

Have you some Lua modularity “best practices”? I think we need to write some API for each module. There are a lot of type checks? Procedural or OO modules?

Automated testing is a weak in my programming experience (Automated integration subsequently …) . I got enthusiasm using few mocks, but it is far from a good practice.

Sincerely yours,

João

_____________________________

In my experience, the most important best practices for programming at scale are source control, modularity, and automated testing.

Source control should need no explanation, but it needs to be said, because many programmers get started without using source control and never get around to using it. Also, the quality and affordability of source control systems has improved dramatically in recent years. There are multiple competing cloud hosted Git services with pull request workflows that are essentially free for most projects. There is no excuse not to be using source control.

The Lua module system is perfect for modularity. Modules abstract dependencies. The Lua module system enables service-oriented architecture, dependency injection, and programming by composition. It may be hard for people to appreciate how powerful and useful the module system is, because it is so simple.

Automated unit testing requires modularity. The code under test is isolated by replacing its dependencies with stubs or mocks. A unit test framework and a mock framework are helpful. If you don’t use an off the shelf framework, be aware that you may end up writing one. The main thing is to write automated unit tests at the same time as the code, or earlier if possible (Test Driven Development). Code coverage of 100% is achievable. If a line of code cannot be unit tested, it should be considered unreachable and deleted.

Automated integration testing is a huge area. Techniques include simulation, instrumentation, fault injection, fuzzing, and A/B testing.

HTH,

Tom