Can you comment on the relation been a live programming environment (no separate "staged" compilation. There is always a dev environment, the REPL, in a deployment), and dynamic types?
The typing available in CL, is it like Python type hints in that they don't affect the meaning of a program whatsoever?
lisper 2 hours ago [-]
Type declarations in ANSI CL are promises you make to the compiler in order to allow it to generate faster code. The compiler can also use this information to generate compile-time warnings and errors, but it is not required to. This makes CL's native compile-time type system good for making your code fast, not so much for making it reliable. But it's straightforward to layer a proper modern type checker on top of CL, and in fact this has been done. It's called Coalton:
IMHO this is the Right Answer: types when you want/need them, dynamism when you don't. It seems like a no-brainer to me. I've never understood why so many people think it has to be one or the other. It seems to me like arguing over whether the window on the bike shed should be on the left or the right. If there is disagreement over this, just put in two windows!
I think the "reliability" you mentioned is "type safety". And I think the dynamicism I sometimes miss in a language with static types is, in a bizarre way, the lack of runtime type errors. If you load a configuration file, necessarily at runtime, but the configuration file has the wrong format, an error should occur. What kind of error? In essence, a type error...
Reusing the type checking machinery at runtime is a benefit to some. At the same time, the possibility of type errors (type unsafety) is a threat to the reliability of programs.
I have trouble wrapping my head around it, but I ultimately want the bikeshed with both windows.
rtpg 2 hours ago [-]
you mention compiling down Lisp code. Did that come with many restrictions in the end result for how you were coding systems? Or would you basically write lisp "as-is" and get decent results?
lisper 2 hours ago [-]
I'm not sure what you mean by "compiling down Lisp code." Can you elaborate? That phrase doesn't appear in either article.
7thaccount 3 hours ago [-]
Are you still writing lisp at JPL or NASA, or as a hobbyist?
lisper 2 hours ago [-]
I left JPL in 2004, never to return :-) I'm mostly retired now but I have a part-time consulting gig that uses CL for developing a bespoke custom chip design tool.
jk4930 52 minutes ago [-]
Would you send another Lisp program to space, just for the joy of it?
neuroelectron 4 hours ago [-]
While I was at Amazon, just before AWS, the entire internal network was monitored by a Lisp agent. I'm not sure if that is still true but it was kind of secret, and the internal wiki (only a few sentences) that documented its existence was removed with no deletion record.
Right before my position was outsourced to an entire remote overseas team, we had rolled out AAA* which conceivably cut out any unauthorized automated agents from the loop.
I also worked on a team at Amazon that did (still does to this day, as far as I know) lisp development. A system that was responsible for automated customer support workflows. And it had a visual programming environment for solutions architects. I worked on the Java backend of that.
adityaathalye 4 days ago [-]
Tells one of my all-time favourite stories.
> 1994-1999 - Remote Agent
> Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem. The story of the Remote Agent bug is an interesting one in and of itself.
tonyarkles 8 hours ago [-]
Not quite the same scale but one of my personal favourite stories involved hardware buried under a highway. The Ethernet stopped working, but the PoE was still ok. We had the foresight to install a serial line to the console on the equipment too. This meant that I could power cycle the hardware at will (through the managed PoE switch) and talk to the boot loader (U-boot) over serial. While not exactly a REPL in the conventional sense, it had enough functionality to be able to talk directly to the MAC and PHY to determine what was going on.
Sadly we couldn’t convince it to work, even at 10 Mbit. My suspicion is salt water ingress into the vault. What we did manage to do, though… There were just enough tools installed on it that I could cross-compile zmodem at home, convert it to a hex file, upload the hex file by essentially just running cat > on the target, convert it back into a binary using… Perl I think? Or xxd? And then doing the daily data offload over zmodem every night instead of over TCP as was originally planned. It was a crazy weekend…
jazzyjackson 6 hours ago [-]
Neat. I’m curious about long run serial as someone who’s only done arduino stuff at 5V, what does industrial serial talking over a miles long connection look like? Higher voltage? Repeaters?
kragen 3 hours ago [-]
Often, though evidently not in this case, people use RS422, which is differential, so you can get megabits per second or kilometers, though not both. Shared-bus RS422 is RS485, like LocalTalk or DMX512. The voltages are actually lower than the ±12V normally used by RS232. Converting back and forth between RS232 and RS422 is easy and cheap. https://www.ti.com/lit/an/slla070d/slla070d.pdf is a TI appnote with an overview.
tonyarkles 3 hours ago [-]
Ahhhh it was standard RS232 which uses -12V and +12V instead of the 0-5V signalling that TTL serial uses. Otherwise very similar and easy to convert with eg a MAX232.
anthk 6 hours ago [-]
Uboot compared to Forth it's very odd to use.
eschneider 2 hours ago [-]
You can load things into memory and run them with u-boot, so somewhat similar. :)
> during a task’s release of a lock, but before its actual release, the task may get interrupted by the daemon if the property gets broken. This means that the task terminates without releasing the lock. The error is particularly nasty in the sense that all code, except the lock releasing itself, had been protected against this situation: in case of an interrupt the lock releasing would be executed.
> The modeling effort, i.e. obtaining a PROMELA model from the LISP program, took about 12 man weeks during 6 calendar weeks, while the verification effort took about one week. ... The translation phase was non-trivial and time consuming due to the relative expressive power of LISP when compared with PROMELA.
> Java PathFinder (JPF) is a translator from a non-trivial subset of Java to PROMELA.
> The translator is written in 6000 lines of LISP, and was developed over a period of 8 months. JPF has been applied to a number of case studies, amongst them a 1500 line game server, a NASA file transfer protocol for satellites, and a NASA data transmission protocol for the space shuttle ground control.
It's an interview I did with Ron Garrett about the history of Lisp at the JPL.
hatmatrix 6 hours ago [-]
> At the time it was more or less taken for granted that AI work was done in Lisp. C++ barely existed. Perl was brand new. Java was years away. Spacecraft were mostly programmed in assembler, or, if you were really being radical, Ada.
Given the choices, Lisp made a lot of sense when they started. After 2001-2004, there were other options - not to say they were necessarily better, but a mainstream language that enables a large number of people working together (interchangeably) has its value. Lisp is indeed "one-of-a-kind, highly dynamic applications that must be developed on extremely tight budgets and schedules" - but has a reputation for fostering lone geniuses and bad for large teams working together and maintaining legacy codebases.
Easier than SICP for Scheme and Intro to Symbolic Computation for Common Lisp.
jmclnx 8 hours ago [-]
> The demise of Lisp at JPL is a tragedy. The language is particularly well suited for the kind of software development that is often done here
That is a shame, but this can be said about many languages of time past. Do schools even teach lisp these days ?
IMO, another casualty of our WEB only environment :(
Lyngbakr 8 hours ago [-]
> Do schools even teach lisp these days ?
IIRC, grads that I interviewed from
the University of Waterloo tended to have experience in Racket.
anthk 4 days ago [-]
Forth would be a good choice too. No GC, use 'forget'.
lisper 5 hours ago [-]
We used Forth back in the day as well, running on 6811 microcontrollers. Forth was also used on the Galileo Magnetometer, and we used Lisp to develop a patch for it in flight.
https://blog.rongarret.info/2023/01/lisping-at-jpl-revisited...
And, as always, AMA.
The typing available in CL, is it like Python type hints in that they don't affect the meaning of a program whatsoever?
https://coalton-lang.github.io/
IMHO this is the Right Answer: types when you want/need them, dynamism when you don't. It seems like a no-brainer to me. I've never understood why so many people think it has to be one or the other. It seems to me like arguing over whether the window on the bike shed should be on the left or the right. If there is disagreement over this, just put in two windows!
What it comes down to is a reconciliation between these two views: https://ncatlab.org/nlab/show/intrinsic+and+extrinsic+views+...
I think the "reliability" you mentioned is "type safety". And I think the dynamicism I sometimes miss in a language with static types is, in a bizarre way, the lack of runtime type errors. If you load a configuration file, necessarily at runtime, but the configuration file has the wrong format, an error should occur. What kind of error? In essence, a type error...
Reusing the type checking machinery at runtime is a benefit to some. At the same time, the possibility of type errors (type unsafety) is a threat to the reliability of programs.
I have trouble wrapping my head around it, but I ultimately want the bikeshed with both windows.
Right before my position was outsourced to an entire remote overseas team, we had rolled out AAA* which conceivably cut out any unauthorized automated agents from the loop.
* https://www.geeksforgeeks.org/what-is-aaa-authentication-aut...
> 1994-1999 - Remote Agent
> Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem. The story of the Remote Agent bug is an interesting one in and of itself.
Sadly we couldn’t convince it to work, even at 10 Mbit. My suspicion is salt water ingress into the vault. What we did manage to do, though… There were just enough tools installed on it that I could cross-compile zmodem at home, convert it to a hex file, upload the hex file by essentially just running cat > on the target, convert it back into a binary using… Perl I think? Or xxd? And then doing the daily data offload over zmodem every night instead of over TCP as was originally planned. It was a crazy weekend…
Here's some interesting quotes:
> during a task’s release of a lock, but before its actual release, the task may get interrupted by the daemon if the property gets broken. This means that the task terminates without releasing the lock. The error is particularly nasty in the sense that all code, except the lock releasing itself, had been protected against this situation: in case of an interrupt the lock releasing would be executed.
> The modeling effort, i.e. obtaining a PROMELA model from the LISP program, took about 12 man weeks during 6 calendar weeks, while the verification effort took about one week. ... The translation phase was non-trivial and time consuming due to the relative expressive power of LISP when compared with PROMELA.
> Java PathFinder (JPF) is a translator from a non-trivial subset of Java to PROMELA.
> The translator is written in 6000 lines of LISP, and was developed over a period of 8 months. JPF has been applied to a number of case studies, amongst them a 1500 line game server, a NASA file transfer protocol for satellites, and a NASA data transmission protocol for the space shuttle ground control.
https://corecursive.com/lisp-in-space-with-ron-garret/
It's an interview I did with Ron Garrett about the history of Lisp at the JPL.
Given the choices, Lisp made a lot of sense when they started. After 2001-2004, there were other options - not to say they were necessarily better, but a mainstream language that enables a large number of people working together (interchangeably) has its value. Lisp is indeed "one-of-a-kind, highly dynamic applications that must be developed on extremely tight budgets and schedules" - but has a reputation for fostering lone geniuses and bad for large teams working together and maintaining legacy codebases.
(I write this as a big fan of Lisp.)
http://t3x.org/zsp/index.html
Easier than SICP for Scheme and Intro to Symbolic Computation for Common Lisp.
That is a shame, but this can be said about many languages of time past. Do schools even teach lisp these days ?
IMO, another casualty of our WEB only environment :(
https://github.com/rongarret/gll-mag-patch/
As with Lisp, you can bootstrap themselves with very few primitives.
One of them whole numbers as lists. I saw no floats, but there are fractional numbers.
If you want to know what is truly Lisp about:Easy mode:
http://t3x.org/zsp/index.html
You are Alonzo Church reincarnated:
http://t3x.org/clc/code.html
In my country an Engineer with a Bachelor would implement a Forth in KB's in days by just reading the specs or books related to building one.
A Microlisp maybe in weeks.