4 ms·
I find the Lisp variants to be lovely right up until I want to package and ship an actual application to a normal human being. Then they are quite clumsy. I fin
by ectospheno 8y ago
I find the Lisp variants to be lovely right up until I want to package and ship an actual application to a normal human being. Then they are quite clumsy. I find the same to be true of a number of other more recently popular high level languages. I've always assumed it was because graduate students never got to the point where they ship anything.
- lgessler 8y agoI haven't tried doing this in other Lisps, but it's really easy if you're using Clojure's most popular build tool, Leiningen. For JVM Clojure you can produce a single .jar ("uberjar") that you can run as you'd expect, and for ClojureScript, Google's Closure Compiler is used to output a single minified and tree-shaken JS file.
- Oreb 8y agoThe parent poster was talking about shipping "an actual application to a normal human being". A .jar file is a non-starter, as normal human beings these days don't have Java installed and have no desire to install it. Don't get me wrong: I love Clojure, and it's currently the language that pays my bills. But I'd never consider using it to build an app for end users (except possibly a ClojureScript React Native app for mobile devices).
- vindarel 8y agoHow so ? In CL you can build an executable. (https://lispcookbook.github.io/cl-cookbook/scripting.html#building-a-self-contained-executable https://lispcookbook.github.io/cl-cookbook/scripting.html#bu...) It's large-ish (because it ships an interpreter, a debugger that we can access from outside, etc), but it has a near-zero startup time, and it works for web apps with their embedded web server.
- claudiawerner 8y agoFor ages I couldn't figure out how exactly I would be able to use Quicklisp libraries to create something, and then create an executable from the source code. I think I ended up giving up, after only finding a couple of blogs that were using ancient versions of everything involved. I remember even having trouble loading some of the packages. Overall my experience with writing CL for myself was fun and interesting, but my experience writing it to be used by other people was anything but. There seemed to be too much rubbish to confuse me, as opposed to something either like C (header files + corresponding source) or Python (a directory with an __init__.py is something you can import). The module system has also turned me away from Scheme; the point where different Schemes all implement say R6RS but they have different module systems, or even different ways of converting an integer to a string, varying support for SRFIs (the regex SRFI is nearly four years old and the only Scheme to implement that is Chibi) and the completely variable module system, where nothing at all is consistent, none of the modules work in another Scheme, even if you were to extract the code. You want something from Chicken to use in Guile? Too bad, you have to manually do all the work yourself, despite the fact that both modules are supposedly written in standard Scheme. The module situation eventually pushed me to write my own Lisp, but I realised that unless I were to go ahead and implement all the things I wanted, everything I would miss, I'd be in just the same place, reminded of that xkcd comic in which "there are now 15 competing standards". So I gave up on doing just that, and now I'm literally writing a Lisp compiler and then operating system with a friend, because for me it's a lot less frustrating to say "that doesn't work on my operating system" than it is to say "that doesn't work in this guy's Scheme". It wasn't supposed to make sense.
- armitron 8y ago> For ages I couldn't figure out how exactly I would be able to use Quicklisp libraries to create something, and then create an executable from the source code. If you use SBCL, which is by far the best CL implementation, it's in the manual under "Generating Executables" [1]. It directs you to this [2] which is basically a single function that you call: Function: save-lisp-and-die [sb-ext] core-file-name &key toplevel executable save-runtime-options purify root- structures environment-name compression Save a "core image", i.e. enough information to restart a Lisp process later in the same state, in the file of the specified name. Only global state is preserved: the stack is unwound in the process. <more, detailed, documentation snipped> What is hard about this? It's literally 10 seconds of work. I am not picking on you, since others run into similar issues, that are completely and utterly trivial, which makes me wonder if they have been conditioned not to bother looking things up in a manual anymore and want things to simply fall in line with their expectations. I am also a Smalltalk user and I frequently observe the same behavior in that domain. New users run into trivial problems that take less than a minute to solve (for the absolute beginner) and give up immediately. I'm almost convinced that there is some sort of psychological effect that comes into play when the task at hand is very dissimilar to what one is used to. Image-based languages like Common Lisp and Smalltalk offer tremendous productivity gains but they're also totally unlike anything else out there in many ways. So they require upfront effort, before one truly "gets it", that includes someone willing to suspend their preconceptions and look at things with 'zen mind, beginners mind'. I think it's fair to say that most programmers today are incapable of doing that. Maybe they're just wired for immediate rewards and/or the overall dumbing down of the domain is also making them dumber. Cybernetic feedback loops are like that .. [1] http://www.sbcl.org/manual/#Generating-Executables http://www.sbcl.org/manual/#Generating-Executables [2] http://www.sbcl.org/manual/#Function-sb_002dext_003asave_002dlisp_002dand_002ddie http://www.sbcl.org/manual/#Function-sb_002dext_003asave_002...