LambdaNative is an open-source Scheme-based cross-platform development framework that supports a wide range of platforms, including iOS, Android, Blackberry, OS X, Linux, Windows, OpenBSD, NetBSD and OpenWrt.
Developed at the Pediatric Anesthesia Research Team at British Columbia Children’s Hospital and at the University of British Columbia, Vancouver, Canada, LambdaNative is based on Gambit Scheme and is able to generate C code from a single Scheme source on all supported platforms. The use of Scheme, claims LambdaNative’s team, enables creating high-quality code while shortening development time in comparison to alternative languages such as Java or C/C++.
Additionally, LambdaNative uses OpenGL-based glGUI as a user interface programming kit. As a consequence, it does not support the creation of native UIs and thus takes the opposite stance to alternative mobile cross-platforms development frameworks such as Ionic, React Native, and others. This is surely one very distinctive feature of LambdaNative that could make it not suitable for the development of every possible kind of mobile applications. On the other hand, enforcing the exact same UI across all supported devices can be an enabling factor in specific scenarios, as one member of the LambdaNative team explains:
We are working with research teams on the other side of the planet and it is handy to send them a Windows version of an app which they can easily run without needing to install each time on a tablet or phone.
LambdaNative has been used for a number of projects in the field of clinical trials, some of them in developing countries, and it also sports a few example apps both on the App Store and Play Store.
InfoQ has spoken with Chris Petersen, Ph.D., leader of the development team behind LambdaNative.
On LambdaNative web page, you claim that LambdaNative makes it possible to hugely reduce development time in comparison to Java and C/C++? Could you elaborate more? Under which conditions was that the case? What are the specific advantages brought by LambdaNative that enable shrinking development time?
Yes, the LambdaNative website displays some results from a paper by Erann Gat (unrelated to our team) comparing Java, C/C++ and Scheme/LISP. Such comparisons are difficult to perform objectively and often disputed. However, these results are in line with our own experience. The primary purpose of LambdaNative is to reduce development time in a resource constrained environment, where applications need to be delivered on short timelines using minimal funds.
We’ve found the advantages of developing in Scheme to be a) the extremely simple syntax and expressive nature of the language, b) the equivalence of code and data, and c) the free mixing of interpreted and compiled code. LambdaNative itself manages the application resources, artwork, code signing etc., which reduces the level of complexity of the app development process and increases overall productivity.
What kind of applications/developers are you targeting with LambdaNative?
LambdaNative is being developed by the Pediatric Anesthesia Research Team (PART) at BC Children’s Hospital and the University of British Columbia, in Vancouver, Canada. The purpose of LambdaNative is to support the development of software for clinical trials in our research group. This includes mobile, server, and desktop applications, deployed on many different platforms. Our internal use of LambdaNative is thus all health-related. However, we have decoupled the medical elements of our work from the framework, making LambdaNative a generic toolkit to be used in creating applications for any purpose. We have moved health-related app content to the LNHealth GitHub repository, which uses LambdaNative.
What is LambdaNative’s approach to accessing OS-specific resources such as UI widgets, sensors, etc.? Along the same line, what kind of interoperability with the host OS does LambdaNative provide?
LambdaNative can access OS-specific resources like sensors and the devices’ camera through Scheme module wrappers. Getting an accelerometer reading, or taking a picture, is then done in a universal way from Scheme, allowing application level code to be written only once while supporting all architectures. To maintain this ability of writing application level code only once, LambdaNative implements its own UI widgets directly on top of OpenGL. This is a trade-off. On the negative, LambdaNative does not have direct access to OS-specific UI features and thus it looks quite different than native apps. On the positive, LambdaNative apps look and behave the same on all platforms, and a new target OS can be added in the future without altering application level code.
What’s on LambdaNative roadmap?
Our current non-health related project plans will see LambdaNative expanded in areas related to Internet of Things protocols, and strong authentication technologies like YubiKey support. In the health-related space we are expanding LNhealth, a framework supporting surveys using manual entry and sensor data. We are considering additional native support for Bluetooth and the native keyboard. Otherwise, LambdaNative does not have an independent roadmap per se, as it is driven by the needs of the projects that we support with it. There is really only one independent goal for LambdaNative itself, which is to maintain maximum portability and reliability to support the mission critical projects created using it.
