Hacker News Reader

Comment by agarren | Hacker News Reader

Can you elaborate a little on your dev environment? Emacs/Geiser?

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.

Did you leverage the repl much in your 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.

No and yes. Mostly no.

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.

Thank you, that was interesting to read about how Chicken Scheme was used in production.

For others like me who are curious, here's what Wisp looks like:

Wisp (SRFI-119) Simpler, indentation-sensitive Scheme - https://srfi.schemers.org/srfi-119/srfi-119.html

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.

Honestly, you'd be surprised how far you can get with simply cut and paste and readline history in a terminal window.

In the past, I've got quite far with two simple functions:

(define (e) (system "vi test.scm")) (define (l) (load "test.scm"))

and just rinse and repeat using those.

Don't let tooling get in your way.

Reply on news.ycombinator.com