LambdaNative
lambdanative.org
lambdanative.org
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.
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.
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...
Trying to do anything in Java and things go wrong? Google, click on the first StackOverflow result and you have the blueprint for a solution. The same can not be said about Racket, at least not with the same breadth of problems.
What does it mean when a language becomes less and less useful without its specification being progressively changed, with the commensurate documentation changes? What does it mean that a language has tons of questions on Stack Overflow?
It would seem that an ideal language is one whose specification is static so that old and new resources, libraries, and documentation remain perpetually useful. However, such a specificationally-static language can only be itself perpetually useful if it is properly flexible to the needs of the programmer. I hear that at least some Lisps are quite flexible, though I unfortunately don't have a good way to fathom/define what constitutes flexibility.
https://news.ycombinator.com/item?id=11174946
Meanwhile, languages like Ocaml, Haskell, and Python pick up the ball by trying to include plenty of power but in constrained and standardized ways that benefit from communities. Results are paying off. There's a few LISP's that do the same thing with better results than prior LISP's. Hopefully, those will keep getting uptake as I think powerful and constrained languages each have something to offer. Best to develop both in parallel, esp as one can implement the other. ;)
That it's used by script kiddies, passionless code monkeys and management types (tm) (I wouldn't really know about the latter). The clueless copy pasta code is what hurt PHP's reputation, I hear (but again, I wouldn't know much about it except for the comments I read).
> 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.
There's too many job adverts for jobs that any programmer could do in any language, but they WANT a Java/c#/etc guy.
The same managers then wonder why their teams are reluctant to work with technology that isn't "hot"....
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).
Honestly, learning the syntax of a language takes under a week. Learning the culture and APIs can take years.
I've been having to do Objective C for the last year and a half. I don't like it, but it's my lot. I understand the language, but I can't say I understand all the tools and APIs, still.
Talking from personal experience I've rarely ever been more than slightly familiar with the language /required/ for a job and I've always made this clear however I've also explained that this isn't really a problem and I've never been rejected from a position because I weren't familiar with their arbitrarily chosen technology stack.
Quickly acquiring new knowledge needed for the job is the most defining quality for engineers/developers.
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.
That's me sticking to utter basics ignoring things like REPL interactive development.
> 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
Not so, since it is likely the case that the requirements and system's function will change, the primary objective is the efficient production of first working version. Personal productivity, satisfaction and good team dynamics probably trump most technical consideration beyond broad strokes (writing for web in assembly is probably a bad idea, but django vs. rails vs. go microservies is probably moot).
Furthermore, one must consider the corollary to the initial presumption: most new projects either aren't successful or aren't long lived. So while if you have strong evidence that a system will be successful and long lived further investment in technical deliberation in making the choice of platform, toolset and architecture would be warranted - it is much more likely no such evidence exists. And therefore the initial investment is the only one likely to be made, so longer term confederations matter not (again beyond some basics and near universal best practices).
The original language was usually absolutely right for the conditions that existed when the original software was written, otherwise it wouldn't have become successful. Those conditions often include severe resource constraints; small teams; small numbers of un-demanding customers; and extreme uncertainty about exactly what the product will do. When the product becomes successful, the certainty about what it will do goes up, available resources go up, team sizes get bigger, and customers get more demanding. The world changes around you as well: new languages are invented, new frameworks come out, customers request different integrations. All of these impose different constraints on the software architecture.
(Incidentally, I suspect that failure to recognize the time-dependence and context-dependence of decision making is behind most career missteps. That old grizzled programmer who insists on using COBOL and DB2 on record-oriented flat files? He's following best practices, he's just following best practices from the 1960s. Similarly, many workers who assumed companies would honor their pension agreements and no-layoff culture were in for a rude shock when executives made decisions based on what is necessary now and fucked over the people who worked hard for them then.)
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.
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.
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.
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?
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.
>> 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.
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.)
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.
I just now prototype any mobile app using LW CAPI and then port it to the actual platform!!!
Thanks for pointing my mistake.
So now you connect the iOS device, change code in slime, recompile and you can see live updates on the device. Is that what you mean by using slime to develop mobile apps using LW mobile?
During the beta days, one would generate a static lib, that would then get copied to Xcode project. I would assume all this is taken care of now automatically with incremental development possible.
Can you point to any documentation for Lispworks mobile with these details? Sorry I could not find any on their website.
http://cljsrn.org/ is generally up-to-date with the state of the art in CLJS+RN.
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.
[1] https://github.com/search?utf8=%E2%9C%93&q=ecl+iphone&type=R...
[2] https://chriskohlhepp.wordpress.com/embeddable-common-lisp-o...
BTW, ECL has also (untested, but integrated) ports for NaCL and pNaCL, which should run cross-platform.
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.
[1]: https://github.com/decker405/figwheel-react-native [2]: https://github.com/mjmeintjes/boot-react-native
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.
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.
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