Very true.

Get backups

Which the client might be responsible for because the contractor might not be allowed to retain the IP

You often will not be, explicitly by contract. Honestly in this case it’s easier to keep things clean.

If you do some work for someone one and decide to keep the source you wrote, so you can review it later in the privacy of your own thoughts, the only way you can get "caught" is if you release it some way that's recognizable.

I wouldn't want to hire anyone that thought like this, as it demonstrates a lack of morality and willingness to adhere to not just an informal agreement, but a legal contract that could expose me to liability or IP theft.

If that's what you want to do, why would you ever sign a contract saying you won't do it?

If the work is interesting and well-compensated, sure, I would sign that contract.

I will also keep the source I write and, if I feel like it, take a look at it years later and no one will know except me. BFD!

Then don’t lose your repo xD

Something something hindsight 20/20 etc etc ;-)

It has been ages since I worked with Common Lisp, so I wonder: Would it be possible / make sense to have version control into the lisp image?

This is basically how Smalltalks work. In addition to the application, an image will generally include a development environment and all the sources to your application. I think Lisp machine Lisps were a lot closer to this too.

If you dig the old Xerox docs, some of them refer to Lisp as inspiration.

Also the Mesa / Cedar had a similar approach, but based on dynamic libraries, which Niklaus Wirth took great advantage on how Oberon and derived systems worked.

Incidentally, due to Rob Pikes admiration for Oberon, not only had Inferno the ACME editor from Plan 9, already influenced by how Oberon worked, the whole Limbo experience on Inferno is quite similar as well.

Unfortunately we still lack this kind of full stack OS/REPL experience on modern systems.

I worked on a system implemented in Smalltalk for a few years, and the truly integrated development process possible in a ST is a high I've been chasing ever since. And this was in a setting that had so many things going against it: I started working on it in 2016, and the last update of the runtime environment was from '99. We had a custom HTTP client, and home-brew bindings to OpenSSL that I cooked up with some mad science Python that parsed C headers to generate Smalltalk code. I even had to fix a bug where Winsock fds rolled over if you opened more than 8k sockets, because the runtime FFI bindings assumed a 16 bit wide return value (I assume the code dates back to the Win 3.11 days).

By all rights, it should have been _awful_. But in reality we were able to iterate quickly and actually make stuff, because the technical foundations of the system were rock solid, the team was good, and because the truly integrated Smalltalk development enviroment enables a super-tight development cycle. A joke I have with a former colleague from those days is how all modern languages are still fundamentally no different from the punch card days: You take your sources off to the batch processing center, and the results come out at the other end, while Smalltalk is future techonology from the 80s.

Yeah we get glimpses of it across JVM, .NET, PowerShell, Fish and so on, but hardly as it used to be.

We do have Pharo, Allegro and such, but their spotlight opportunity is gone.

> We do have Pharo, Allegro and such, but their spotlight opportunity is gone.

Do you think the paradigm is a dead end?

In the world of commercial software, sadly yes, compare the idea of Dynabooks with the tablets that we actually got.

Possible: yes. Lisp image can hold arbitrary data, including source code, versions, etc. Specifically, arbitrary data can be attached to symbols.

Make sense: no, unless you have very special requirements. It would be very different from common practice. Images are still much more fragile than files outside, they are not designed to last across implementation releases.

(Note: some implementations might hold full code of every function in memory, that's not unreasonable.)

That has been done in the past and was never widely supported. But the landscape is now slightly different. One approach might be to use ASDF (the most popular systems management tool), which then would need to be upgraded to use versions (and ideally have it integrated into a repository mechanism -> Git or similar... Also what are versions in a decentralized world?). ASDF operations then would need to be able deal with version numbers.

A Lisp image would then know/track which versions of what code it has loaded/compiled/... Version information would be stored with the other source files.

> That has been done in the past

Could you share some examples of how the old systems did this?

Can't say what and Interlisp did, but the MIT Lisp Machine and here the commercial variant Genera.

Files are versioned. The Lisp machine file system has versions (same for DEC VMS and a few other file systems). Nowadays the file version is attached to the name&type. Thus editing a file and saving it creates a new file with the same name&type and an updated version number. I can edit/load/compile/open/... files by specifying its version number. If there is no version number specified, the newest file version is used.

A site shared a namespace server with system registry and several file servers.

Code, documentation, etc. is defined as a system, similar to what ASDF does. A system has major and minor version numbers and other attributes (like being experimental or being released). Each time one does a full compile on a system, its major version gets updated and it tracks which file versions it used for that compilation. Whenever one creates a patch (a change of the sources) to a system, the minor version gets updated. After 12 full compiles and 30 patches to the latest version we have system FOOBAR 12.30. This data is recorded in the system directory, thus outside of an image (called a World in Genera) in the file system.

Now I can use that system FOOBAR in another Lisp and "Load System FOOBAR :version Newest" -> This will load system FOOBAR 12.30 into its runtime. Then new patches may appear in the system. I can then in a Lisp say "Load Patches FOOBAR" and it will look into the system directory for new patches to the current loaded major version and load those patches one by one. This changes the running Lisp. It then knows that it has loaded, say, FOOBAR 12.45, what files it has loaded and in which files the respective code (functions, ...) are located.

If I want to ship a system to the customer or someone else, I might tag it as released and create a distribution (with sources, documentation or not). The distribution is a file (also possibly a tape, a bunch of floppy disks, a CDROM, or similar). A distribution can contain one or more systems and its files (in several versions). On another Lisp I can later restore the distribution or parts of it. The restored systems then can be loaded for a specific version. For example I can load a released system version and then load patches for it.

A saved image knows which versions of what systems it includes. It also knows which functions sources are where. It may also have corresponding documentation versions loaded.

Later a source versioning system (called VC) was added, but I haven't used that.

It's not a lisp, but Unison (https://www.unison-lang.org/) integrates editor, version control, runtime with content addressed functions

It's pretty cool, and also an obviously terrible idea as you leave behind all standard tooling