LambdaNative – Cross-platform mobile apps in Scheme
lambdanative.orgIt'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
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).
> 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.
I've coded in both (Common Lisp and Haskell, as two examples) and enjoyed both. Static languages tend to force you to think carefully about what you're doing before you test your code; dynamic languages let you get away with being careless. Dynamism is fine for prototyping but terrible in large software projects if you have mediocre programmers. That said, I've had mostly good experiences with dynamic languages -- probably because I've worked with mostly excellent software engineers who didn't need the language to force them to be thoughtful.
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.
> 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.
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.
While you persist on your belief system, a big, award-winning code controlled the NASA Deep Space One out in space for several days. Done 100% in a dynamic language.
A really big and complex program, is right now doing airline planning for over 800 companies, taking into account 4000 airports. To get an idea of the complexity look at this pdf:
http://www.demarcken.org/carl/papers/ITA-software-travel-com...
Both examples are software programmed in a dynamically typed language, Common Lisp.
And in that highly dynamic language, should any bug appear in production, it can be patched without stopping the system and of course without having to recompile the whole code. This bears repeating:
The system can be patched without stopping it and of course without having to recompile the whole code. That is, patched at runtime by correcting the offending function and re-attaching the new version of that function to the running system.
Try doing that with your favorite statically-typed language.
Your arguments are just common beliefs of the typical developer who is lacking more experience in the field of developing real-world systems. You are just regurgitating common myths, and in the process, calling "fucked up mentally" people probably wiser (more experienced and learned) than you.
And BTW,
If you think all dynamic languages are equal to javascript, which is not only dynamically typed but also weakly typed, then you need to try more dynamic languages. For example strongly typed dynamic languages.
I wish i had $1 everytime a developer mixes up "dynamic typing" with "weak typing"
I know very well what the difference between weak vs dynamic typing is.
Weak typing allows automatic implicit conversion between types.
While I'm not a big fan of it, but I don't mind weak typing as much as I have a problem with dynamic typing. A statically typed language can be weakly typed.
Modern C++ for instance, can automatically convert from an object of types A to B, if the you provide a single-argument constructor for B that takes something of type A as an argument. It's sometimes neat as it leads to more succinct/cleaner code.
You talk about NASA using Common Lisp to update the program while it's running. But this feature has nothing to do with dynamic typing, and could be implemented/supported by a statically typed language. In fact the JVM had/has a feature that allows live updating methods/classes while the program is running.
Common LISP is a cool lanaguge with a lot of cool features. For instance, many LISPs' macro system are very cool, and we could implemented far cleaner / safer / more hygienic versions of them in dynamically typed languages with.
The only benefit of dynamically typed languages is that it makes the work of a prototype interpreter implementor far easier.
> some arbitary strucutre and set of fields that were not defined or specified anywhere
This is not a necessary feature of dynamic languages; some have proper object systems with class declarations.
Dynamic languages can contain crap design decisions, like using functions to simulate objects and classes, and that will reflect badly on the programs.
But do any of these languages have functionality that enforces that only fields/methods that are defined are accessed? Do they enforce any apsect, of what might be called the (data) scheme?
I'm downvoting you because your post is venomous and insulting. I'm also disagreeing with you.
Most of your argument is emotional and anecdotal, and what remains is only a compelling argument for code quality, not static/dynamic.
I, too, have worked in large code bases in both static and dynamic languages, and generally, I found the latter was a far better experience than the former - but code quality trumped any static/dynamic effect.
Even in just terms of reading and understanding what was going on, it was generally far more challenging to understand the point of code blocks due to boilerplate to deal with typing; indirection through wrapper classes in particular. A function might take an object foo, which would typically be on some level on an inheritance tree, and you'd have to trace up and down both the tree and the call stack in order to understand, and discard more than half the characters to get to the logical meat. Pure hell on development - the absence of REPL consoles means you really can't explore what's actually going on at a point in the code, you have to infer it. Grr.
Every time I get in production [in static languages], I run into some issue processing data that would never happen had it been written in a dynamically typed language.
I don't want to grab people like you and punch them, I want to either find a way to chill you the fuck out so we can have an actual discussion, or fire you so the rest of the team doesn't have to deal with religious fervor.
I think you have to be lacking mentally to not appreciate the beauty, power, clarity and flexibility that high-quality dynamically typed systems bring, in languages like Ruby, Javascript, Python, Lisp, etc.
People limited to one paradigm - static/dynamic, OO/functional - are a bane.
This is not to deny that some dynamic code bases are poor, but that's true of everything.
But solid dynamic systems are a huge advantage.
I don't actually wish more people spend time researching and building more advanced and better dynamic systems, because the ones we've got are plenty kick-ass as it is. We're already better off for it.
--
In actuality, in my experience, the strengths and weaknesses of static/dynamic are entirely based on how well or poorly "typed" the data you're dealing with is - over the lifetime of the project - although at small scale it really doesn't matter.
This is why dynamic languages took over the web - not only do you have very flexible information in systems you've already built (see "myths programmers believe about names, gender, time, etc" for a good example), but your development speed is such that the type of information changes ~1/mo anyway. Static languages are great for when have a well-defined problem that's not really going to change on you, and you need a solution that's fast and/or extremely safe.
The problems really only happen when you shut down the conversation with insults and vitriol.
Agree with you. Too many myths!
> You haven't grounded your assertions on any logical arguments.
The author asserted nothing but their own person experience. No logic argument is needed to support the claim "I feel X." Assuming a truthful author, the claim is self-supporting.
I agree with most of what you said and I understand frustration but even if intended to be humorous I think you should not say to someone that you want to beat them up over it.
I fully agree with you!! I'm going to a new job in scala in a few weeks, what would you wish me? :)
". 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."
That's your belief, not a fact.
> 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,
It is exactly the opposite. Mainstream programming languages are recently catching up with features that are more advanced but weren't popular before, like functional programming, metaprogramming and dynamic programming.
> prefer Kotlin over Clojure is that I am a huge proponent of static typing
If you're into static typing on the JVM, then Kotlin is the best choice because it's got the best-of-breed types. If you're into dynamic typing on the JVM, then Clojure is the best choice because it's got the best-of-breed macros.
What I can't fathom is why anyone would choose a language that's dynamically typed but without any macros, or only tacked on static typing later on as an afterthought. Apache Groovy comes to mind for the JVM as a language which did both.
Edit: Macros are great for simple elimination of repetitive code in bulk tests, but Groovy's Spock hacks into the statement labels and operator overloading in a clumsy attempt at an alternative. And Groovy's backers only added some static typing in version 2.0 because they were afraid of someone else's addon (Groovy++) taking away their control.
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), 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.
I used to play around with Gambit, but never saw Gerbil before. Thanks for the link. When do you use it over Gambit?
A recent example of cross-platform app/game made with LambdaNative: https://www.reddit.com/r/scheme/comments/6hng3q/i_developed_...
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.
Each scheme is actually much better than people realize at what it's targeted for.
Recently I have to give huge props to Guile + Andy Wingo for guile-fibers. It's proper concurrency, using delimited continuations in scheme. Just frickin' fantastic!
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.
Gambit is another one that has some real-world usage (it's what LambdaNative uses).
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.
Previous discussion, from about a year and a half ago: 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
The phone apps look like they are from 2013. That explains a lot.
Thanks for the links.
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
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.
I'd like to see someone code golf that calculator in javascript.
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.
Because racket isn't as easy to get running on smartphones as something that just compiles to C.
With gambitc you are already there.
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...). I wonder if that might enable Racket to ultimately be able to run on other Schemes' infrastructure.
> with Racket's move to the Chez Scheme interpreter,
Is there a wiki or an issue to track progress of this?
I don't know. I'm only familiar with it because of the Google Group posting and associated Hacker News story from a while back.