3 ms·

Good points. I remember hearing similar thoughts on systems built with Forth: They performed their job, even when other languages were incapable of producing

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? Thanks again.

shakna 9y ago
> 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.

3 ms·

Good points. I remember hearing similar thoughts on systems built with Forth: They performed their job, even when other languages were incapable of producing

by jsgrahamus52 9y ago

shakna 9y ago
> 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.