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.
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.
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.
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.
I don't think you "don't care" about the language - you just want a language that gets out of your way and allows you to express your solutions easily. That IS a language preference.
Yet, the poster works with a high-level language that readily offers common constructs that are needed without memory management, etc details. Integration is also easier than with C. So, there's concrete evidence that prototyping in Python will be faster given equal effort due to (a) enabling advantages and (b) less work for common stuff.
That's me sticking to utter basics ignoring things like REPL interactive development.
You're at least 50x more productive at prototyping Python than in C. I am too. I know some veteran C++ programmers who are far more productive at prototyping in C++ than in Python, though. And even for myself (who is a huge fan of dynamic programming languages), there are some tasks - eg. MapReduces - where I'll prototype in C++ rather than Python because the integration with the framework and faster performance outweighs any gain from language constructs.
95% of jobs are for maintaining an existing code base. So they just want the person who will jump in and start working on it with minimal bullshit.
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.
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"....
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).
I think people sometimes takes recruiters words too literally, wanting proficient in a language is a good way to scare of people afraid of leaving their box (I've met plenty of developers reluctant to try new languages and technologies).
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.
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.
The inevitability at this time seems to be that the desired function of large, successful systems will evolve over time. This is the root cause of larger system rewrites being so common and (at this time) largely inevitable. But that is also the appeal of strong subsystems that last and can evolve. Language runtimes, libraries, infrastructure components like databases. The can largely persist, but their suitability to various systems will shift as the system themselves change. One must consider that many approaches, even if better for the long-run would have near term costs in terms of additional effort, or training, operational support or even hardware needs.
> 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).
When a successful software system is rewritten in another language, that doesn't mean the original decision was "proven wrong". It means that conditions have changed.
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.)
"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.
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.
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.
> 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.
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.
Sure, the language has progressed, but the libraries, resources, documentation, ... haven't to the same degree as with more popular languages.
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.
Perhaps lisps do not benefit from progression in libraries; creation of new resources; and don't need to change often enough to warrant new documentation.
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.
Not true: LISP would've benefited greatly from at least one core usage and set of libraries that were easy-to-use with lots of uptake. Call it the Python effect. How it's been used and expanded is quite amazing. LISP could've done more but wasn't restrained enough by community. The reasons for this are social, not technical. Probably best explained here:
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. ;)
> What does it mean that a language has tons of questions on Stack Overflow?
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).
I find with the right choice of libraries, and using CLion IDE I'm as efficient in C++ as I was in Java. The introduction of c++11, along with modern refactoring IDEs for C++ has been a godsend.
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...
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!
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.
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.
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.
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?
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.
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.
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.
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.
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.)
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.
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:
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.
I don't own any ios device and support for it isn't merged in the repository yet. There are a few git repositories (a bit dated though), regarding building ECL with iPhone[1], and there is a project by Kris Kohlhepp[2] – I've wrote to him recently with the question about patches. If anyone has iOS and will submit a proper PR with some notes about building I'll gladly accept it :-)
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!!!
Not actually true. I have a simple puzzle game running in iOS with mocl. Lisp does the Model+Controller part and the View is in ObjectiveC. Once the game is running I can change states like level-up/down, etc. and the changes are reflected in real-time. I cannot change functions like in a true CL environment on the desktop, but I can definetly change global things to see if e.g. my flow works...
Vow, I did not know that. I had tested with beta ios runtimes, then it was not possible.
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.
You still deliver the mobile runtime as a static library, but the compiled library contains the entire LispWorks runtime minus the native code compiler (which is a constraint of the lack of executable memory on iOS). The runtime contains a byte-compiler however, so the runtime is still available intact in fairly complete form. You just need to make sure that CLOS and everything you care about for interactive development is kept during delivery (see the Delivery guide for details). How you deal with the lack of compile-file is up to you, (you can easily just treat it as a no-op, or a loader) but I personally installed my own function which remotely invokes the cross compiler to compile new ARM64 FASL and then save the results in a local directory on the iOS device. It will treat the code like any interpreted code, but it works great for development.
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.
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:
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.
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.
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.
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.
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
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.