LambdaNative

http://www.lambdanative.org

by macco • 10 years ago

287 73 10 years ago

iLoch• 10 years 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?

deepaksurti7• 10 years 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 [2] https://play.google.com/store/apps/details?id=ca.bccw.usquis...

PS: I am not from the LambdaNative team.

i_feel_great2• 10 years 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.

dtd834• 10 years 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• 10 years 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• 10 years ago

For Pythonistas, Kivy would be another WORA option, though not quite as many supported platforms (yet).

https://kivy.org/#home

dtd834• 10 years 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://itunes.apple.com/ca/app/rrate/id581390517?mt=8

known• 10 years ago

Is it a code generator?

i_feel_great2• 10 years ago

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

lqdc132• 10 years 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

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.

sspiff2• 10 years 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.

kryptiskt2• 10 years 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.

wtbob• 10 years 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 think that 15 years ago Java and C++ had more libraries than Scheme and Common Lisp, and that even with millions of dollars invested the infrastructure around Java and C++ isn't nearly as powerful as what Common Lisp provides in the standard.

nostrademons4• 10 years ago

Here's the big secret about the tech industry: arbitrary technology is exactly what you want for your project. It doesn't actually matter. Any inherent differences in productivity are dwarfed by the effects of being emotionally invested in your work and having lots of other people emotionally invested in the outcome. Besides, regardless of what you choose, if it becomes successful it will be rewritten multiple times by multiple groups of people, and the effect of having them emotionally invested in their work will far outstrip any inherent differences in technologies. So pick whatever you want, and then let your employees pick whatever they want subject to the constraint that groups who work on the same codebase better agree on the same technology.

lordnacho• 10 years ago

Someone needs to tell this to recruiters.

There's too many job adverts for jobs that any programmer could do in any language, but they WANT a Java/c#/etc guy.

lqdc132• 10 years ago

Not sure about dwarfed. I'm at least 50x more productive at prototyping Python than in C.

I don't understand what passion has to do with the language/library choice.

Assuming there are some people who are primarily motivated by the language they use or syntax of that language, what about people who don't care about the language and are more interested in algorithms and data structures? What about people who are motivated by the final product?

Also, lack of such studies leads to people not trying new "stacks" because they are afraid that it's a new unproven technology that probably won't work.

shitgoose• 10 years ago

I totally agree with you that it doesn't matter what language you chose for the project. I would just replace references to "emotional this and that" with "understanding the business domain". If you know what you are doing, it absolutely doesn't matter how you do it, you will get it right anyways.

mwcampbell• 10 years ago

Is it truly inevitable that a successful product will be rewritten? That's so wasteful that it seems irresponsible to let personal preference or emotional investment influence foundational decisions that might later prove wrong, requiring a rewrite. We should do our best to make such decisions carefully, dispassionately, and scientifically.

jimbokun2• 10 years ago

"Any inherent differences in productivity are dwarfed by the effects of being emotionally invested in your work and having lots of other people emotionally invested in the outcome."

In my experience, technology choices can make a massive difference in my ability to stay emotionally invested. If I'm constantly spending mental energy on the idiosyncrasies, strange bugs, and repetitive code required by my technology stack, I have much less time and energy to devote to making changes the customers will actually notice.

eggy2• 10 years ago

I am more impressed by the bevy of citations that go back to March 2010, and involve LambdaNative. That and the 10 countries and 100,000 subjects. The interfaces are not iOS/Android app polished, but very functional looking. I evaluated it last year, and I may look at it again. I think the market it targets isn't looking for the polish so prevalent in web tech apps, but function first. They could use help in that department, and it seems for a good cause. Hats off to the team!

MichaelGG• 10 years ago

This data might exist. YC has funded many startups, and pg supposedly has a very pro-LISP stance. By looking at the technology choices and results, wouldn't there be something interesting to be found? If they don't collect any sorts of stats (that'd be unfortunate), perhaps they could poll YC alumni and see if there are any trends.

nickpsecurity4• 10 years ago

There have been a number of studies in the past showing LISP or other VHLL's outperform C-like 3GL's in productivity or defect ratios. There's been some consistency in results regardless of the methods. The consistency on those is more that C sucks than that LISP is great. ;) Java seemed to suck too except not as bad as C.

I'd like to see a batteries-included LISP with dev environment put against Python, Ruby, etc by people with similar skill level in respective mindsets on same types of apps. Quite a lot of people. That would tell me more. Of course it will outperform C, C++, and Java in productivity: it's a safe-ish, malleable, dynamic language with macros. LISP beating scripting languages would speak volumes given it also compiles to efficient native code, was used in OS's, and can use dedicated CPU's.

AnimalMuppet• 10 years ago

I'd like to see that study, too, but have it maintained and enhanced for a decade by people who are not all members of the original team.

jimbokun2• 10 years ago

I loved the prominent placement of that graph.

Makes a strong, unambiguous statement right off the bat as to why I should be interested in this project. If nothing else, shows me the project's goals and priorities are aligned in the right direction.

Having said that, I suppose the best approach would be to randomly assign developers to learn a language/technology stack they haven't used before, then have them learn the technology and implement a project in the language. Would evaluate difficulty of learning the language, availability of resources, and the strength of the community.

If you evaluate performance based on language/stack the developers already know, would be difficult to tease apart the correlation between technology stack and developer ability.

pmalynin• 10 years ago

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

jrapdx3• 10 years 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• 10 years 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• 10 years ago

Reading the calc app reminded me of tcl/tk

lmm• 10 years 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.

eggy2• 10 years 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• 10 years 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• 10 years 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• 10 years 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• 10 years 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

deepaksurti7• 10 years 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• 10 years ago

No idea but coding against unit tests, rather than testing every change on a running app, should help avoid that frustration.

deepaksurti7• 10 years ago

While I do not deny the value of automated tests, the ability to do incremental, live updates when rapidly prototyping is indispensable.

kryptiskt2• 10 years ago

Unit tests doesn't help when exploring the behavior of the app. Working in a live environment is wonderful for debugging.

junke• 10 years ago

I did not use them, but look at mocl[1] and Lispworks[2] for Mobile.

[1] https://wukix.com/mocl

[2] http://www.lispworks.com/products/lw4mr.html

deepaksurti7• 10 years 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!!!

jarcane• 10 years ago

There is work on-going to get ClojureSCript working with React Native. The tooling is a pain-point right now, but it's at least at proof-of-concept stage.

http://cljsrn.org/ is generally up-to-date with the state of the art in CLJS+RN.

jackdaniel2• 10 years ago

Embeddable Common-Lisp has now official Android support. It is also known to build for iPhone. It allows connecting via swank to the running application:

https://common-lisp.net/project/ecl

https://gitlab.common-lisp.net/ecl/ecl-android

Disclaimer: I'm the maintainer.

Edit: add main project website, clarify iPhone support status.

deepaksurti7• 10 years ago

This is awesome. Is there an ecl-ios repo? I could not find it on gitlab.common-lisp.net. Sorry if it is there, as I only had a quick glance on the repo.

dtd834• 10 years ago

Check out our LNhealth repository (from the LambdaNative team). https://github.com/part-cw/LNhealth

The LNhealth app is similar to your desired workflow. It runs scripts written in Scheme that define the pages in the app. When developing for Android I can just push a change to the script (using the Android Debug Bridge - adb) and do not need to recompile the app itself. It makes for a much faster development cycle.

t1amat• 10 years ago

ClojureScript has a great story for hot reload with React Native via Leiningen + Figwheel[1] or Boot[2].

[1] https://github.com/decker405/figwheel-react-native [2]: https://github.com/mjmeintjes/boot-react-native

c-l-p• 10 years ago

You can add a TCP based REPL to any LambdaNative app by inclusion of a single module. This allows you to connect through emacs and run/alter code on the live system, potentially directly on the mobile device (although it would make more sense to do this sort of iterative development on a build for the localhost). The setup is described here:

https://github.com/part-cw/lambdanative/wiki/Using-Emacs

manishsharan• 10 years 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• 10 years 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• 10 years ago

Typo in the home page: 'electical'

DigitalJack• 10 years ago

I believe those are optional gonads.

dtd834• 10 years ago

Thanks for catching that. It has now been fixed.

LambdaNative

Related Stories