That's how I handled it. Scheme's syntax is simple enough to teach in 10 minutes, and the syntax is close enough to Python it doesn't take much to get people up and running.
I've used Scheme in production a few times now. A group of decent programmers (with experience in Python or Lua or Ruby) under one senior programmer with Scheme experience is usually more than enough.
Web developers, probably not so much. Frameworks tend to be more important.
However, "Built a transaction system in FORTRAN, C, and Scheme that is currently running at ~100 billion transactions a second at a major bank" is weighty despite the languages used.
Similarly, "Built a conveyor belt controller on an Xtensa with Scheme, deployed at 40 million sites" isn't going to matter that Scheme was used.
Good points. I remember hearing similar thoughts on systems built with Forth: They performed their job, even when other languages were incapable of producing such systems, and they often were built with a fraction of the time and resources required by other languages.
Fortran, C and Scheme: Sounds like an old system. Is it still running?
The conveyor belt controller sounds like an embedded project. Why Scheme?
> Fortran, C and Scheme: Sounds like an old system. Is it still running?
Still running. Last I heard, as I was only part of the team responsible for rebuild and first six months of deployment, (I trained a team of six whilst we built it, now they maintain it), the system is responsible for about 1/3 of Australia's transactions.
Partial rebuild of an old system, but I wouldn't choose anything else if I was doing it again.
FORTRAN absolutely floors anything else for number processing, except very well written assembly.
C was just a nice wrapper to join FORTRAN and Scheme together.
The Scheme in use was highly extended, with some givens like GC disabled, using a custom allocator, had the ability to take ctypes as datatypes, which allowed as to wrap FORTRAN data and pass it up and down without particularly caring what language was inspecting it.
> The conveyor belt controller sounds like an embedded project. Why Scheme?
The conveyor system was management giving me a chance to prove a language other than C would work.
So I used a Scheme that compiles to C, runs baremetal, and is as predictive as C, runtime wise. GC was not entirely disabled, as refcounting worked close enough to runtime speed for our measures. (A u14s pause exactly every 38s, from my notes).
However, the time to deploy using Scheme, was half the usual projections.
Sure! I've now run as a team leader on six midsize-to-enormous projects that involved Scheme in their stack.
I've used:
1. Chicken Scheme for development, Gambit-C for release.
2. Custom baremetal Scheme based around the design of PreScheme and Microscheme. Implemented using Gambit-C and some of it's unique features. They had 8,16, and 32bit variants for half a dozen chip makers. (100% proprietary, and any real details covered by an NDA).
3. Racket for development, Chez Scheme for release.
Racket isn't quite Scheme, but it's IDE makes development so much friendlier, that I'll jump at the chance to use it. However, an amazing compiler is needed for release, at least to meet the standards I tend to need to aim for.
It amazes me that different compilers can be used for dev vs release, especially Racket. That would be like using clang in development and gcc in production! I'm assuming you used the R6RS language in Racket for compatibility?
> That would be like using clang in development and gcc in production!
... I've done that too.
It's not a blind 'compile & release', but some compilers optimise better, others are faster. Wildly differing behavior is very, very rare in my experience.
Tradeoff being you have a more limited language subset, and may need to adopt only one compiler in the future.
> I'm assuming you used the R6RS language in Racket for compatibility?
Sometimes, more often r5rs, as that's what Gambit-C aims for.
