We built a server backend using Chicken in six months, it held up under significant load, and as normal the database connection was where we had to put most of the engineering effort.
We used a few macros to remove overhead in a few places where you'd use generic functions, and that saved us a little performance.
All in all - I'd happily use it in production again. I like it when the tech stack is boring and does what is expected of it.
I was using Sublime Text, a couple others were using Atom. The only one with a CLI editor used vim.
Just about everything out there will have decent Scheme support. It's a lisp, and it's a well-defined lisp. Scheme being well-specified makes everything simple. (Even the SRFIs are well specified.)
Our deploys were via Jenkins, but through Chicken's egg system it wasn't exactly a complicated process.
I hear a lot about “repl-driven” development with Clojure and CL, but anytime I get experimental with it I find myself neck-deep in editor configuration, or simply wrestling with emacs keybindings.
Because load was a primary concern, we mostly used a test-driven cycle where we'd spin up the server and then attempt to DOS it for every change. Not something you want happening much on your dev machine.
However, for the simpler tests, if the test system hit a failure, it would then drop into a REPL (not on the production server). So it was sort of like a nicer debugger.
The test system was developed in-house, but if I remember, it was something like a 100 lines of code. That's one of the things that Scheme guides you towards - if you don't have a wheel, it's generally five minutes to make one.
I wouldn't generally bother fighting with emacs or configuration for anything. If you're fighting your tools, you're not being productive. Fine to do if you're not being paid, not so fine in a workplace. Keep things simple, and you'll do better than if you try and be clever. Rainbow braces and documentation lookup will get you 99% of the way to where you want to be.
That being said, one of our devs wrote their code with Wisp (SRFI-119), and had a git pre-commit hook that automatically rewrote it back to normal Scheme, and another hook in their editor to turn it into Wisp code when they opened a file. Nobody noticed for over a month.
Scheme makes it easy to write the way that you want to, using the tools that you like.
My experience in taking to Schemers is that Schemers tend to think more in terms of a more normal “put code in a file and load the file” mindset. (Matthew Flatt of Racket fame is known for “the toplevel is hopeless” which has implications for the sorts of features necessary for truly interactive development.) CL, Clojure, Smalltalk are more on the REPL-driven development side of things.
Discovering this philosophical division was a bit surprising to me when I first started talking to Lispers outside of my CL bubble.
I'd distinguish between REPL driven and Image driven, the latter a subset of the former. I cherish the REPL, but Image based programming reminds me to much of bad old days in FORTH. That might be the approach to get a working solution by a single excellent programmer for problems of modest difficulty the soonest when no one cares how one got there and how to replicate that success and whether one can learn from missteps along the way, but for all else the file based approach with version control is IMHO the safer bet. There one still can use the REPL to experiment with ideas and test small steps.
That’s not the distinction I’m making: my CL workflow is to always start from a clean image that has been restored from source control (although, I think the ideal here is a system like Pharo that integrates VC into the image itself). What I mean is that Scheme users seem to have a workflow that’s more along the lines of what people do in Python, Ruby or JS, running the interpreter/compiler as a “batch” process whereas CL/Clojure/Smalltalk pursue a more interactive development experience.
Python devs use both styles depending on preferences and app type, IME. The notebook tooling is also great for sharing already set up REPL environments with state.
Sort of: when I wrote a lot of Python, I used REPLs pretty heavily and I’ve also used notebooks a bit. The issue is that Python isn’t designed in a principled fashion for interactive development: reloading imports and other objects doesn’t always work the way you’d expect.
Reloading cross depending modules with identical semantics (vs aappcold startup) is just as fraught in other languages I think. Upgrading existing instances of objects is a bit more automatic in some but then results in surprises and bugs if not anticipated in code.
I know what you mean. A few months back I started playing with GNU Guile and wanted some of that nice repl integration. It took me more hours than I would have liked, first because I wanted to use vim instead of Emacs, and second, because vim for parenthesis language programming is frowned upon and harder to find examples for. In the end I wrote my editor config in a gist to make it easier to discover https://gist.github.com/mhitza/a00d7900571e9f13bac2bbf4a203d...
When I get more free time I'm definitely eager to jump back to Guile programming. But on my first test drive, I definitely had good experience with the repl driven approach. No matter how barebones of a setup it is, it's better than my past Haskell repl experience, where it almost felt like a tool you need to use no matter what.
To begin with, but as half of the devs, myself included, were sight-impaired, the symbol-heavy syntax became a real drag and we transitioned away from it.
In the end, what we ended up with was our own library written around libevent, which could interface with awful's plugins. As a bonus, it was much, much faster than awful. It even beat out nginx in some situations.
I have a multiple-choice quizzing system written in Chicken that's been running at our uni for the past 15 years. It was meant to be a throw-away, to be used for a semester until the bugs in our learning-management system were fixed. But it still gets some use, and has clocked ~350,000 test submissions over the years. Not too shabby for a throw-away. It just runs, and I never think about it... until someone asks a Chicken Scheme question!
I used Chicken successfully in an embedded Linux system where C interop was a high priority. It's a great compiler and one of my go-to Schemes to this day, though obviously the library ecosystem is nowhere near as complete as e.g. Python's.
I found the documentation to be good. I remember looking at it and finding whatever I was looking for, thinking: "It's all here!" Even stuff, that I do not fully understand like CK-macros (http://wiki.call-cc.org/eggref/5/ck-macros).
There was one issue though, which stopped my hobby project: Support for UTF-8 in display seems to be broken: http://bugs.call-cc.org/ticket/1374 As I tried to build a vocabulary trainer, I had to switch to another Scheme.
We had to write a lot of our own stuff but it fits fairly neatly into the scheme-way of doing things: you can get a remarkable amount done with just a few simple lines of code.
I'd probably want to write about as much in any other language as a lot of what we built were domain level abstractions.
We had a very talented web designer and we also built a "Widgets and forms" toolkit. I gave a talk at FrOSCon quite early in the development and it was saved for posterity: https://media.ccc.de/v/c116_lisp_-_2013-08-25_11:15_-_buildi... The first few minutes of audio are broken but it sorts itself out.
