
LambdaNative – Cross-platform mobile apps in Scheme - landakram
http://www.lambdanative.org
======
winter_blue
It's a bit inaccurate of them to present the results of a 17-year old paper
(published in 2000), as empirical evidence that development time in Scheme is
shorter. These days there are plethora of language choices on the JVM, and if
I were devloping a multi-platform app today, I would personally choose Kotlin
along with the Intel Multi-OS Engine:[https://software.intel.com/en-us/multi-
os-engine](https://software.intel.com/en-us/multi-os-engine)

Part of my motivation to prefer Kotlin over Clojure (the most popular LISP on
the JVM langauge?) is that I am a huge proponent of static typing. Large
programs written in statically typed languages are orders of magnitute _more
readable_ , more maintainable, easier to understand, and far less error-prone,
than programs written in dynamically typed languages.

The recent surge in popularity of dynamically typed languages like JavaScript,
Python, Ruby, etc, had been a source of horror and frustration to me. It feels
like a huge segment industry is throwing away decades of advancement made in
programming language research, and instead of moving to languages with more
advanced type systems, they're abandoning sound typing altogether (shudder).

~~~
wooby
> more readable ...to you.

It's possible I suck at what I do, but somehow I've enjoyed building,
shipping, and maintaining services and applications in dynamic languages.

I used a lot of Clojure, and it was basically smooth sailing, even on teams.

Along the way I used various statically typed languages, such as C# and a tiny
bit of SML (to be able to read Okasaki), and enjoyed them too. Just not as
much.

Anyway, I can't refute your experience programming, or the way that you feel.
With more experience, perhaps some day I will agree with you. But right now,
for whatever it's worth, I don't.

Dynamic (functional) languages all the way.

~~~
winter_blue
You haven't grounded your assertions on any logical arguments. I've worked on
large code bases, both in statically typed languags, and dynamically typed
ones, and the latter was _a far worse experience_ than the former.

Even just in terms of reading and understanding what was going, there was no
way to know the structure of objects passed to various function. A function
would take an object foo, which had some arbitary strucutre and set of fields
that were not defined or specified anywhere. Pure hell for readablity (i.e.
understanding someone else's code). The absence of type system enforced
structure on objects, means these objects could contain anything. Grr.

Everytime I get in production, a run-time JavaScript TypeError that would
never happened had it been written in a statically typed language, I want to
grab people like you by the collar (proponents of dynamically typed _crap_ ),
and punch you in the face and give you a bloody nose.

I think you have to be slightly fucked up mentally to not appreciate the
beauty, the power, the clarity, and the safety that high-quality type systems
bring, in languages like Agda, Haskell, Elm, Swift, Kotlin, etc.

Dynamically typed languages are a bane.

This is not to deny that some statically typed languages have a poor type
systems. Early Java had a disappointingly weak and primitive type system (e.g.
no generics). Scala's type system is so complex that it's worse off for it.
Etc.

But solid type systems are a huge advantage. I wish more people invested time
researching and building more advanced and better type systems. We'd all be
better off for it.

~~~
nikofeyn
> You haven't grounded your assertions on any logical arguments.

neither did you. in fact, you italicized probably the least objective portion,
that of staically typed languages being more readable. and that's likely to be
the opposite case for most people. the draw for most dymaically typed
languages is that they are often quite readable.

sometimes people prefer different stuff, and that's all the commenter was
saying. i myself like both.

~~~
winter_blue
That's ridiculous. I most intentionally italicizes it -- precisely because
readability and comprehensabitltiy is the biggest benefit of static typing.

When I was younger (a teenager), I valued static typing for the safety it
brought. After working at a few companies, I now value it more for readability
& comprehensability, than anything else.

------
gerbilscheme
Gambit is a fantastic scheme system. The performance you get from it exceeds
even SBCL in my limited use cases. Additionally, Gerbil Scheme
([http://cons.io](http://cons.io)), built on Gambit, has expanded syntax like
racket's #lang features for dsls. Several packages have also been create for
it for most of the things I need.

~~~
eggy
I used to play around with Gambit, but never saw Gerbil before. Thanks for the
link. When do you use it over Gambit?

------
alekq
A recent example of cross-platform app/game made with LambdaNative:
[https://www.reddit.com/r/scheme/comments/6hng3q/i_developed_...](https://www.reddit.com/r/scheme/comments/6hng3q/i_developed_a_medium_sized_cross_platform/)

------
kronos29296
This project blew me away. I always thought Scheme was just interpreters and
toy programs. Hope this succeeds in making scheme popular. Scheme and Lisps in
general way too underrated.

~~~
1337p337
Stock Scheme does not have much in the way of interfaces to the outside world
(long story) but there are several Scheme variants where people are doing
larger projects. Racket is sort of a Scheme variant, and it seems to be the
most popular, but Chicken and Guile are also pretty popular (as far as Scheme
variants go) for real-world use cases.

~~~
_delirium
Gambit is another one that has some real-world usage (it's what LambdaNative
uses).

~~~
1337p337
Yep, that's why I left it off the list.

I've actually written some LambdaNative. Unfortunately, we ended up going with
Cordova, but you can guess which one was more fun to write.

------
_delirium
Previous discussion, from about a year and a half ago:
[https://news.ycombinator.com/item?id=11192542](https://news.ycombinator.com/item?id=11192542)

And a paper (2013) giving some details and explaining their motivations:
[http://ecem.ece.ubc.ca/%7Ecpetersen/lambdanative_icfp13.pdf](http://ecem.ece.ubc.ca/%7Ecpetersen/lambdanative_icfp13.pdf)

~~~
dmix
The phone apps look like they are from 2013. That explains a lot.

Thanks for the links.

------
gliechtenstein
This looks awesome! I believe being able to express an entire app logic as
data can be super powerful.

BTW shameless plug: If you're interested in this type of ideas, please also
check out Jasonette (an open source project I'm working on) Just like this
project uses "list" to describe an app, Jasonette uses JSON to describe an
app. [https://www.jasonette.com](https://www.jasonette.com)

------
desireco42
I love it! This is awesome idea, now that I see it, I wonder why wouldn't
Google just use it, if Apple will not, this makes total sense for mobile apps.
Pair it with high performance native api, it can be winning ticket.

------
githubber123
I'd like to see someone code golf that calculator in javascript.

------
baldfat
LOVE this project. My serious question is why wasn't this done in Racket as
opposed to Scheme? Seems this would fit in Dr Racket wonderfully.

~~~
Johnny_Brahms
Because racket isn't as easy to get running on smartphones as something that
just compiles to C.

With gambitc you are already there.

~~~
peatmoss
I know that, with Racket's move to the Chez Scheme interpreter, bits of core
Racket C code are getting rewritten in Racket
([https://groups.google.com/forum/#!msg/racket-
dev/2BV3ElyfF8Y...](https://groups.google.com/forum/#!msg/racket-
dev/2BV3ElyfF8Y/4RSd3XbECAAJ)). I wonder if that might enable Racket to
ultimately be able to run on other Schemes' infrastructure.

~~~
codygman
> with Racket's move to the Chez Scheme interpreter,

Is there a wiki or an issue to track progress of this?

~~~
Johnny_Brahms
[https://github.com/racket/racket7](https://github.com/racket/racket7)

