This certainly looks interesting, but it might help generate interest if the landing page addressed two questions: what is the application size overhead (how large is a hello world app) and what is the app startup overhead.
I used to make standalone apps from SBCL Common Lisp, and they were not too large (even though SBCL has no tree shaker unused code remover).
I did a benchmark of executable image sizes and startup times for the popular open-source implementations[1] it depends on cl-launch since asdf:program-op was still experimental at the time.
A few points I discovered:
SBCL and CCL are neck-on-neck for startup time; very slightly longer than a hello-world in python, but much faster than any python script that has to do any significant importing.
SBCL has by far the largest image size overhead ~80MB for "hello world". It has an option to compress the image with zlib, but that is a big impact on image startup time. I did a proof of concept of an lz4hc image compressor, and it made for acceptable startup times while taking the overhead down to under 30MB. Someone else turned this into a real patch, and it is waiting to be merged.
CCL's image size is about 1/2 that of sbcl.
ECL has, by far, the smallest image size, even including the DLL (3.2MB for a lisp runtime is tiny!). However, it has a startup time that is two orders of magnitude higher than sbcl/ccl
clisp was ind the middle of things; executable image was about double that of ecl, it's startup performance is better.
Thanks for the info on CCL's image size - that makes CCL worth switching to for bundling applications, but your SBCL patch sounds even better. That said, it has been a number of years since I sold a Lisp application - but still good to know!
I agree final app size would be a further selling point for me too. I am glad to see Lisp, CL, in the headlines other than clojure. I guess the ubiquity of JS has lead to the possibility Ceramic offers due to Electron.
Slightly, OT, but I am reading 'The Handbook of Neuroevolution Through Erlang', and I am waiting to learn enough Erlang to jump over to using LFE (Lisp flavored Erlang) mid-book. @mark_l_watson, I started with your 'Common Lisp Modules:..' book, and now I am hooked on AI, NN and Lisp. Thanks!
I am glad to see Lisp, CL, in the headlines other than clojure.
We've had a string of really cool lisp projects this year, web frameworks, implementations, web servers, libraries, etc. Couple that with Edi Weitz's upcoming book, it's as exiting to be a lisper now as ever. Hack gloriously and eat your parenthesis for breakfast my lispy friends :)
Thanks! Richard Stallman asked me several years ago about releasing my old Lisp book under a FSF documentation license, but I can't find my old manuscript files. Maybe I will ask my wife to re-type it all.
Thanks for the $3 Amazon reference. I only have one copy of my (very) old book, and just ordered a used copy so I have a spare. I was surprised to see that Springer Verlag still sells it new - I thought that it was out of print a long time ago.
The hello world app (bundle) is like 250 megabytes. Half of that is the Electron release, the rest is the Lisp image, whose size you can cut significantly using core compression (this isn't enabled, I'm looking into doing it through Buildapp without it crashing if it's not available).
The only JavaScript is in the Electron process, and it's fixed, ie you don't have to touch it. You interact with it through CLOS methods on window objects.
Other than that any JavaScript is optional, you write it yourself (using whatever source language, e.g. ParenScript) and ship it with your app as a resource.
Yikes. One would think that could be pared down by a significant amount: Node is only ~40mb installed, and the various webkit browsers aren't much bigger than that.
See my other comment about implementations' core image sizes. SBCL is the worst offender for runtime space overhead[1], and it's CLOS implementation is heavily biased towards the "space" side of the time/space tradeoff, and a brief look at the implementation of this shows a lot of CLOS usage. I would expect that delivering with a different implementation would show a significant reduction in size.
Barring that, most GUI executables are fairly insensitive to startup time, so SBCL core compression would the lisp image down by a factor of 4:1.
Lastly, you can always just not worry about it:
du -s /Applications/*.app | sh ~/avg.sh
Total: 28529040; Count: 126; Mean: 226420; Median: 56752; Min: 8; Max: 6132408
1: Note that SBCL generates the best code of any Free lisp implementation, and makes it the easiest to tune your code for better performance. As disk space is cheap, it's what I use for most of my applications.
Let me address this and the comments asking 'why' below:
There are GUI libraries for Common Lisp. CommonQt+qtools is essentially the gold standard, and everyone seeking to make a GUI application should use it.
I like the web, it lets me design applications with a precision native GUI tools don't have. And you can make an app that runs on the localhost and you can access through the browser: I do this for some applications I've written.
The problem is distribution: most users won't really know what's going on when they run an executable and it opens a terminal window and a browser window to some weird URL called 'localhost:41000'.
Also https://github.com/robert-strandh/McCLIM looks maintained but if it's anything like what it was a couple of years when I last looked at it, it could use some contributors :)
There are also at least 3 GTK+ bindings that I've seen around.
http://cliki.net/GUI lists 31 GUI libraries. We have enough for every day of the month :)
I can't see it ever happening. I first started learning Lisp in 2006. Some of the most common messages on Lisp forums were things like "what GUI library should I use?", "why is there no standard GUI?", "this library works but it's incomplete and looks abandoned," along with calls for the Common Lisp community to standardize around one GUI library.
If the situation hasn't gotten better since then, well... what are people waiting for?
You are more than welcome to work on it and submit it to HN. However, please refrain from being gratuitously negative in this forum; someone just spent a lot of time and effort into making something, and your comment - which took less than a minute to write - is purely negative and adds nothing to the discussion.
It is entirely legitimate to point out that somebody the submission is going in the wrong direction, yes they spend a bunch of time on it, but that is sunk cost and better they not waste any more.
GP was to the point, but not mean and added something to the discussion (even if you disagree with it). You, however, were rude.
Heh weird. 15 years ago my job was porting apps the other way. Turning lisp desktop apps into lisp web apps with cl-http.
Of course that was hard. Turning a web app into a desktop app is just a matter of embedding a browser. The other way around requires work.
This is a really cool/interesting way of packaging an entire app. I never even thought to have a CL backend in a separate process that you could communicate with via HTTP. I've done the same thing (browser, embedded lisp) using nanomsg, but this seems a lot more straightforward.
Good work =]! I also really need to look more into Electron. I've only used node-webkit (before it was NW.js).
If a given language you enjoy can run a web server, you could potentially take advantage of Electron. This of course includes Go, D, C#, Java, Clojure and plenty of other languages everyone loves. Not telling everyone to do this for every type of application though, but it is definitely not impossible to approach making a desktop application with web technologies.
Is there any reason that this wouldn't be able to work with another language? If the interface is an HTTP port, it seems like this isn't necessarily tied to Common Lisp.
Yes, you could rebuild the project in any language if you wanted.
Ceramic opens an HTTP server (in lisp), starts electron (using a shell command), communicates to the electron process via streaming, then electron sends back HTTP requests to the lisp process.
However this is tied to Common Lisp because the containing project itself is built in Common Lisp and can't be switched out without completely rebuilding in another language.
How much work it is to extend Electron to create the same thing but for a different language i.e. "Turn Haskell/Python web applications into native desktop apps"?
I agree. Using Electron on all of these desktop application "frameworks" keeps seeming like throwing a supertanker at a job when someone asked for a tugboat. I feel like this will only continue to bloat so many applications further, and will make writing (and refactoring) GUI applications more difficult.
You'll be sad to known a ton of OS X and Windows applications these days are just running in web views. Heck, even a lot of iOS apps are partially/mostly UIWebViews.
Slack's desktop app is a web view. The iOS app is native.
I think the wells fargo banking app on the phone is not native. The At&t one doesn't feel like it. Usually there's something different about the controls and interactions that make it not feel native. Sometimes there's a dead giveaway like being able to double tap and accidentally zoom in just like in mobile Safari.
Yep! A common pattern is for the navigation to be written in the native language to take advantage of faster/smoother animations and all dynamic content is inside of web views.
Spotify on Linux: clicking on things often feels slightly janky and laggy. How fitting!
And the spacebar will 80% of the time page down rather than pause the music, something which sounds minor but which makes the user experience 50% more annoying for me. Do most people even use spacebar to page down in normal webpages!?
The colloquial definition of a native desktop application is an application that runs from a binary on your system. So yes, most people DO think of these as native applications.
A native app is one you download and execute on your computer. In reality it doesn't matter much what gui toolkit you write it in, there is nearly always going to be some xml and styling involved - GTK is native on Ubuntu (I hope you will grant me that), but programs written in it typically uses glade files to design the gui and load and bind event handlers at runtime. Glade is XML.
.net uses the native win32 gui toolkit - but you typically build it WPF, which is XML, styled with XML.
On mac? plists - which is you guess it XML (I have no idea what, if anything, you style a mac app with).
So basically the three biggest platforms use XML to bind their guis with - and there isn't much difference between XML and HTML. Granted when you design XML for guis it tends to be nicer than if you wrangle HTML into that role but this is a programmer, not a user, issue.
That's a nonsense argument. There's a world of difference between using the platform's native framework and controls (which may be instantiated from an XML file) versus a single WebView which contains the entire app.
Saying "HTML is nearly XML, therefore HTML is native" is akin to saying "Vietnamese is written using the Latin alphabet, hence it's basically the same as English".
The "native" part of native app doesn't mean machine code. It means that it is native to, i.e. feels like it naturally came from, the host operating system. It uses its APIs, conventions, UI components, event queues, etc.
as JayVanguard already pointed out native means another thing. but putting that aside.
You are confusing what HTML and XML are if you think they are similar. XML is a way to encode data, validate it conforms to a schema, query it, etc. HTML is more than the surface syntax. It includes an schema and semantics (the DOM, the CSS OM, the boxing model, etc). Using XML as a declarative layer on top of their UI, as android does, does not make it similar to writing HTML because of the completely different semantics associated with it.
Android takes all the xml layouts and compile them and expose them through the R(esource) class.
I see more than one person on this thread who thinks native means "runs native machine code" and more than one person who thinks it means "looks like it was built with the native GUI library" so the term is ambiguous. Before iOS app store, I think it was more common to mean the former, so it may be related to that.
The browser is native code, the app is compiled to native machine code. There are no virtual machines involved, except the JS VM on the browser (and this doesn't need JS).
Right, when people say native, they talk about connecting directly with the OS-specific UI fundamentals. An application is "native" not by virtue of its execution environment, but by virtue of the UI primitives. That's why people talk about "native look and feel".
I used to make standalone apps from SBCL Common Lisp, and they were not too large (even though SBCL has no tree shaker unused code remover).