10 ms·

LambdaNative

287 points by macco 11y ago

iLoch 11y ago
Interestingly the developers of this platform have chosen to adopt the "write once, run everywhere" mantra. It appears they've also chosen to provide a unified visual framework, which means no native feel. Can someone from the LambdaNative team tell me why it would be advantageous to take this route instead of using something like Cordova/React Native/Titanium/Xamarin? Are there any apps in the app store that are currently built using this technology?
- deleted 11y ago
  [deleted]
- deepaksurti 11y ago
  >> Are there any apps in the app store that are currently built using this technology? uSquish, the simple example game included in the LambdaNative repository, is available as a free download on the Apple[1] and Google stores[2]. [1] https://itunes.apple.com/us/app/usquish/id647308142 https://itunes.apple.com/us/app/usquish/id647308142 [2] https://play.google.com/store/apps/details?id=ca.bccw.usquish https://play.google.com/store/apps/details?id=ca.bccw.usquis... PS: I am not from the LambdaNative team.
- i_feel_great 11y ago
  The original (and still primary?) target market is clinical applications on mobile devices, where I assume it is highly desirable to have everything look exactly the same across different devices. This aids in accuracy when describing patient data remotely.
  - dtd83 11y ago
    Yes, this is quite true. When developing mobile apps for global health projects they are typically in Android. 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.
- tluyben2 11y ago
  Because this targets more platforms than the ones you named with (as far as I can make out from experience with those platforms) less code.
- kitd 11y ago
  For Pythonistas, Kivy would be another WORA option, though not quite as many supported platforms (yet). https://kivy.org/#home https://kivy.org/#home
- dtd83 11y ago
  I am part of the LambdaNative team. >> Are there any apps in the app store that are currently built using this technology? Yes, as mentioned there is the uSquish game, but our more useful app is RRate, for measuring repiratory rate. https://play.google.com/store/apps/details?id=ca.bccw.rrate https://play.google.com/store/apps/details?id=ca.bccw.rrate https://itunes.apple.com/ca/app/rrate/id581390517?mt=8 https://itunes.apple.com/ca/app/rrate/id581390517?mt=8
known 11y ago
Is it a code generator?
- i_feel_great 11y ago
  Based on Gambit Scheme, which compiles to C. Then you use the C compiler for your target platform.
lqdc13 11y ago
So on the front page they have in the center a graph that shows lisp doing better in practical applications. They are basically using one paper to claim performance/productivity improvements. This comes from this paper from 16 years ago: http://dl.acm.org.sci-hub.io/citation.cfm?doid=355137.355142 http://dl.acm.org.sci-hub.io/citation.cfm?doid=355137.355142 That paper has all kinds of issues including self-selected participants and a tiny sample size. We should really do a hackathon "study" mandatory for a specific group of people e.g. coworkers, something like a surprise pre-hackathon to a real hackathon or something else. Dev time is so expensive that nobody will ever do a real study it seems. What we have now is people selecting arbitrary technologies to use for their projects. There are so many different ones floating around that it's impossible to get proficient at all of them.
- sspiff 11y ago
  This was the first thing I noticed as well. I mean, that's from an age where Java and C++ libraries, frameworks and build systems were nowhere near as advanced as today. Scheme has seen little investment in their infrastructure and ecosystem in the past 15 years, whereas C++ and Java have seen millions of dollars and many man-years invested in libraries etc. I doubt this data is still valid today, even if it was a decade and a half ago.
  - kryptiskt 11y ago
    Racket has a lovely environment, and as a language it has progressed far more than Java has. C++ remains nobody's idea of a language for rapid development.
    - cmrdporcupine 11y ago
      I find with the right choice of libraries, and using CLion IDE I'm as efficient in C++ as I was in Java. The introduction of c++11, along with modern refactoring IDEs for C++ has been a godsend. I prefer the Rust language, but until there's an IntelliJ/CLion class IDE for it, I don't know if I'd go down that route...
    - 11y ago
pmalynin 11y ago
Nice to see something from Canada, and especially from UBC!
jrapdx3 11y ago
Curiously the list of supported platforms includes NetBSD and OpenBSD but not FreeBSD. Since FBSD can run gambit, and install it as a package, it would seem LambdaNative should work on FBSD. Haven't looked into the question yet so maybe there's a logical reason for leaving FBSD off the list. Would be interesting to find out what it's about.
- c_l_p 11y ago
  FreeBSD support has now been added. There was no particular reason for leaving FreeBSD off the list, we just haven't been using that system so far.
xyzzy123 11y ago
Reading the calc app reminded me of tcl/tk
- lmm 11y ago
  TCL is a very elegant language that combines many lisplike properties with a healthy dose of pragmatism. But somehow it never gets any respect.
  - eggy 11y ago
    I just picked up the book "Tcl/Tk: A Developer's Guide" by Clif Flynt. I see Tcl/Tk in PureData, Pd, that I am using, and so many other apps that I decided it was worth learning. The short code examples were also enlightening. I have used it so far to write some utilities on Windows that I would have used Powershell for, but now I can use them on my Linux partition too. And the Tk widgets are not as bad as the press they get, especially for personal, rather than distribution to the 'design' saavy ;) I like it so far.
  - qwertyuiop924 11y ago
    Weirdly, everybody whines about the different quoting mechanisms and the use of upvar and uplevel in TCL. Coming from scheme, it's a breath of fresh air: Macros are no longer a special class! everything is unified! Sure, you lose some abstraction power with the quoting, but that's AWESOME! And if you're wondering why lisp didn't do this, it used to, in the form of fexprs. Although there was never any equivalent of uplevel, AFAIK. Some lisps, like newlisp (which thinks we'll LOVE solving the funarg problem again) and picolisp (which also has a version of uplevel, but apparently thinks that alists are an acceptable replacement for hashmaps and other data structures, so fuck that noise), actually still have this, but it lost favor in the mainstream, partly due to the Wand paper, which proved that it makes many common compiler optimizations impossible.
  - makecheck 11y ago
    I don’t like TCL because it can be extremely hard to debug and cause fatal errors very late in the game. Since both "varname" and "$varname" can appear almost anywhere, it is very hard to conclusively tell where something is used (or even if what you see is a mistake). What’s that, you have a 1.5-hour job that died because of a TCL syntax error, because TCL can’t parse far enough ahead, and the stack trace is useless? Par for the course.
nyc_cyn 11y ago
What's the TLDR of this? Is it scheme that transpiles to LLVM? If you want to code in lisp, why use this over clojure(script)?
- mikelevins 11y ago
  It's a set of tools and frameworks that make it convenient to use the Gambit Scheme compiler to develop apps for several platforms. There are a variety of reasons that someone might choose it over Clojure or ClojureScript: - they like Scheme better than Clojure - they like the frameworks in LambdaNative better than the libraries available for Clojure - they like the toolchain used with LambdaNative better than the toolchain around Clojure (both toolchains are kind of baroque compared to, say, Lispworks or ClozureCL) - they want to build for a platform (such as iOS) where Gambit provides a convenient solution and Clojure doesn't - they want to deliver apps to more platforms than Clojure currently supports - they want to deliver compiled binaries that don't need a JVM or javascript VM to run
deepaksurti 11y ago
Has anyone who has used this know if like any other Lisp, one can do live editing while the app is running on the actual mobile device? For example: i have the app running and it fails, I go to emacs, fix the culprit code, compile and load, go back to app, it starts working again without having to re-run the app. If yes, that will be awesome. I hate the edit, compile, test cycle really.
- mekazu 11y ago
  No idea but coding against unit tests, rather than testing every change on a running app, should help avoid that frustration.
  - deepaksurti 11y ago
    While I do not deny the value of automated tests, the ability to do incremental, live updates when rapidly prototyping is indispensable.
  - kryptiskt 11y ago
    Unit tests doesn't help when exploring the behavior of the app. Working in a live environment is wonderful for debugging.
- junke 11y ago
  I did not use them, but look at mocl[1] and Lispworks[2] for Mobile. [1] https://wukix.com/mocl https://wukix.com/mocl [2] http://www.lispworks.com/products/lw4mr.html http://www.lispworks.com/products/lw4mr.html
  - deepaksurti 11y ago
    I have tried both, but then do not offer the live interactivity that is possible when running off a desktop Lisp implementation. I guess this is so because we are not running a lisp image on the mobile device. I just now prototype any mobile app using LW CAPI and then port it to the actual platform!!!
manishsharan 11y ago
I have always wondered why people think "terseness" of the programming language leads to being able to deliver solutions faster. I have found that the nailing down business requirements ,end user expectations and integration with other enterprise components is the most time consuming part of my solution development cycle.
- jerf 11y ago
  Because for a good long time, programming languages were accidentally complex, and verbosity and hoop-jumping were a legitimately large amount of the development time. 1990s-era C++ GUI programming makes my eyes bleed. I don't think this is particularly true anymore, but ideas take 15-20 years to finally die out in the programming world, and we're only 5-10 years into that cycle. Languages still have varying degrees of accidental complexity but compared to where we used to be, you almost always have the choice of some nearly-optimal language. (Many may still not avail themselves of those choices but that's their own problem.)
bikamonki 11y ago
Typo in the home page: 'electical'
- DigitalJack 11y ago
  I believe those are optional gonads.
- dtd83 11y ago
  Thanks for catching that. It has now been fixed.

287 points by macco 11y ago

iLoch 11y ago

Interestingly the developers of this platform have chosen to adopt the "write once, run everywhere" mantra. It appears they've also chosen to provide a unified visual framework, which means no native feel. Can someone from the LambdaNative team tell me why it would be advantageous to take this route instead of using something like Cordova/React Native/Titanium/Xamarin? Are there any apps in the app store that are currently built using this technology?

deleted 11y ago
[deleted]
deepaksurti 11y ago
>> Are there any apps in the app store that are currently built using this technology? uSquish, the simple example game included in the LambdaNative repository, is available as a free download on the Apple[1] and Google stores[2]. [1] https://itunes.apple.com/us/app/usquish/id647308142 https://itunes.apple.com/us/app/usquish/id647308142 [2] https://play.google.com/store/apps/details?id=ca.bccw.usquish https://play.google.com/store/apps/details?id=ca.bccw.usquis... PS: I am not from the LambdaNative team.
i_feel_great 11y ago
The original (and still primary?) target market is clinical applications on mobile devices, where I assume it is highly desirable to have everything look exactly the same across different devices. This aids in accuracy when describing patient data remotely.
- dtd83 11y ago
  Yes, this is quite true. When developing mobile apps for global health projects they are typically in Android. 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.
tluyben2 11y ago
Because this targets more platforms than the ones you named with (as far as I can make out from experience with those platforms) less code.
kitd 11y ago
For Pythonistas, Kivy would be another WORA option, though not quite as many supported platforms (yet). https://kivy.org/#home https://kivy.org/#home
dtd83 11y ago
I am part of the LambdaNative team. >> Are there any apps in the app store that are currently built using this technology? Yes, as mentioned there is the uSquish game, but our more useful app is RRate, for measuring repiratory rate. https://play.google.com/store/apps/details?id=ca.bccw.rrate https://play.google.com/store/apps/details?id=ca.bccw.rrate https://itunes.apple.com/ca/app/rrate/id581390517?mt=8 https://itunes.apple.com/ca/app/rrate/id581390517?mt=8

known 11y ago

Is it a code generator?

i_feel_great 11y ago
Based on Gambit Scheme, which compiles to C. Then you use the C compiler for your target platform.

lqdc13 11y ago

So on the front page they have in the center a graph that shows lisp doing better in practical applications. They are basically using one paper to claim performance/productivity improvements. This comes from this paper from 16 years ago: http://dl.acm.org.sci-hub.io/citation.cfm?doid=355137.355142 http://dl.acm.org.sci-hub.io/citation.cfm?doid=355137.355142 That paper has all kinds of issues including self-selected participants and a tiny sample size. We should really do a hackathon "study" mandatory for a specific group of people e.g. coworkers, something like a surprise pre-hackathon to a real hackathon or something else. Dev time is so expensive that nobody will ever do a real study it seems. What we have now is people selecting arbitrary technologies to use for their projects. There are so many different ones floating around that it's impossible to get proficient at all of them.

sspiff 11y ago
This was the first thing I noticed as well. I mean, that's from an age where Java and C++ libraries, frameworks and build systems were nowhere near as advanced as today. Scheme has seen little investment in their infrastructure and ecosystem in the past 15 years, whereas C++ and Java have seen millions of dollars and many man-years invested in libraries etc. I doubt this data is still valid today, even if it was a decade and a half ago.
- kryptiskt 11y ago
  Racket has a lovely environment, and as a language it has progressed far more than Java has. C++ remains nobody's idea of a language for rapid development.
  - cmrdporcupine 11y ago
    I find with the right choice of libraries, and using CLion IDE I'm as efficient in C++ as I was in Java. The introduction of c++11, along with modern refactoring IDEs for C++ has been a godsend. I prefer the Rust language, but until there's an IntelliJ/CLion class IDE for it, I don't know if I'd go down that route...
  - 11y ago

pmalynin 11y ago

Nice to see something from Canada, and especially from UBC!

jrapdx3 11y ago

Curiously the list of supported platforms includes NetBSD and OpenBSD but not FreeBSD. Since FBSD can run gambit, and install it as a package, it would seem LambdaNative should work on FBSD. Haven't looked into the question yet so maybe there's a logical reason for leaving FBSD off the list. Would be interesting to find out what it's about.

c_l_p 11y ago
FreeBSD support has now been added. There was no particular reason for leaving FreeBSD off the list, we just haven't been using that system so far.

xyzzy123 11y ago

Reading the calc app reminded me of tcl/tk

lmm 11y ago
TCL is a very elegant language that combines many lisplike properties with a healthy dose of pragmatism. But somehow it never gets any respect.
- eggy 11y ago
  I just picked up the book "Tcl/Tk: A Developer's Guide" by Clif Flynt. I see Tcl/Tk in PureData, Pd, that I am using, and so many other apps that I decided it was worth learning. The short code examples were also enlightening. I have used it so far to write some utilities on Windows that I would have used Powershell for, but now I can use them on my Linux partition too. And the Tk widgets are not as bad as the press they get, especially for personal, rather than distribution to the 'design' saavy ;) I like it so far.
- qwertyuiop924 11y ago
  Weirdly, everybody whines about the different quoting mechanisms and the use of upvar and uplevel in TCL. Coming from scheme, it's a breath of fresh air: Macros are no longer a special class! everything is unified! Sure, you lose some abstraction power with the quoting, but that's AWESOME! And if you're wondering why lisp didn't do this, it used to, in the form of fexprs. Although there was never any equivalent of uplevel, AFAIK. Some lisps, like newlisp (which thinks we'll LOVE solving the funarg problem again) and picolisp (which also has a version of uplevel, but apparently thinks that alists are an acceptable replacement for hashmaps and other data structures, so fuck that noise), actually still have this, but it lost favor in the mainstream, partly due to the Wand paper, which proved that it makes many common compiler optimizations impossible.
- makecheck 11y ago
  I don’t like TCL because it can be extremely hard to debug and cause fatal errors very late in the game. Since both "varname" and "$varname" can appear almost anywhere, it is very hard to conclusively tell where something is used (or even if what you see is a mistake). What’s that, you have a 1.5-hour job that died because of a TCL syntax error, because TCL can’t parse far enough ahead, and the stack trace is useless? Par for the course.

nyc_cyn 11y ago

What's the TLDR of this? Is it scheme that transpiles to LLVM? If you want to code in lisp, why use this over clojure(script)?

mikelevins 11y ago
It's a set of tools and frameworks that make it convenient to use the Gambit Scheme compiler to develop apps for several platforms. There are a variety of reasons that someone might choose it over Clojure or ClojureScript: - they like Scheme better than Clojure - they like the frameworks in LambdaNative better than the libraries available for Clojure - they like the toolchain used with LambdaNative better than the toolchain around Clojure (both toolchains are kind of baroque compared to, say, Lispworks or ClozureCL) - they want to build for a platform (such as iOS) where Gambit provides a convenient solution and Clojure doesn't - they want to deliver apps to more platforms than Clojure currently supports - they want to deliver compiled binaries that don't need a JVM or javascript VM to run

deepaksurti 11y ago

Has anyone who has used this know if like any other Lisp, one can do live editing while the app is running on the actual mobile device? For example: i have the app running and it fails, I go to emacs, fix the culprit code, compile and load, go back to app, it starts working again without having to re-run the app. If yes, that will be awesome. I hate the edit, compile, test cycle really.

mekazu 11y ago
No idea but coding against unit tests, rather than testing every change on a running app, should help avoid that frustration.
- deepaksurti 11y ago
  While I do not deny the value of automated tests, the ability to do incremental, live updates when rapidly prototyping is indispensable.
- kryptiskt 11y ago
  Unit tests doesn't help when exploring the behavior of the app. Working in a live environment is wonderful for debugging.
junke 11y ago
I did not use them, but look at mocl[1] and Lispworks[2] for Mobile. [1] https://wukix.com/mocl https://wukix.com/mocl [2] http://www.lispworks.com/products/lw4mr.html http://www.lispworks.com/products/lw4mr.html
- deepaksurti 11y ago
  I have tried both, but then do not offer the live interactivity that is possible when running off a desktop Lisp implementation. I guess this is so because we are not running a lisp image on the mobile device. I just now prototype any mobile app using LW CAPI and then port it to the actual platform!!!

manishsharan 11y ago

I have always wondered why people think "terseness" of the programming language leads to being able to deliver solutions faster. I have found that the nailing down business requirements ,end user expectations and integration with other enterprise components is the most time consuming part of my solution development cycle.

jerf 11y ago
Because for a good long time, programming languages were accidentally complex, and verbosity and hoop-jumping were a legitimately large amount of the development time. 1990s-era C++ GUI programming makes my eyes bleed. I don't think this is particularly true anymore, but ideas take 15-20 years to finally die out in the programming world, and we're only 5-10 years into that cycle. Languages still have varying degrees of accidental complexity but compared to where we used to be, you almost always have the choice of some nearly-optimal language. (Many may still not avail themselves of those choices but that's their own problem.)

bikamonki 11y ago

Typo in the home page: 'electical'

DigitalJack 11y ago
I believe those are optional gonads.
dtd83 11y ago
Thanks for catching that. It has now been fixed.