
LambdaNative - macco
http://www.lambdanative.org
======
lqdc13
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.

~~~
nostrademons
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
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.

~~~
arethuza
I don't think it's recruiters - hiring managers want someone who can "hit the
ground running" so look for an _exact_ match between the technology involved
in their current project and the experience of an applicant.

The same managers then wonder why their teams are reluctant to work with
technology that isn't "hot"....

~~~
solipsism
Can't really blame them when it's part of our culture to start looking for a
new job once we've been there a year, why would they want to invest
significant amounts of resources into you?

Then again, maybe you can blame them, as at least part of the reason for this
part of our culture is that it's the best way to get high enough promotions to
get up to our deserved salary (as defined subjectively by the engineer).

------
iLoch
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?

~~~
i_feel_great
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
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.

------
jrapdx3
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
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.

------
manishsharan
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
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.)

------
deepaksurti
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
No idea but coding against unit tests, rather than testing every change on a
running app, should help avoid that frustration.

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

------
xyzzy123
Reading the calc app reminded me of tcl/tk

~~~
lmm
TCL is a very elegant language that combines many lisplike properties with a
healthy dose of pragmatism. But somehow it never gets any respect.

~~~
qwertyuiop924
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.

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

------
known
Is it a code generator?

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

------
bikamonki
Typo in the home page: 'electical'

~~~
dtd83
Thanks for catching that. It has now been fixed.

------
nyc_cyn
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
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

