I wrote this "manifesto" a few years ago and thought I'd share it as, on the evolution forums we don't talk much about the other part of the equation, tooling. While there will always be a role for compilers for resource intensive coding e.g. AI and the edit compile test treadmill, as code reuse increases using packages and those packages bring in other packages the developer experience for working a program of modest dimensions continues to degrade and I believe translated languages may be the future in the long run. There is hope however, using the approach outlined below you can have the best of both. The rigour of a strongly typed language and the agility of scripting. On with the manifesto...
When I started programming, a programmer's lot had been long established. You wrote a program in a text editor, you compiled it and ran it to see if it met your requirements. At around the same time however, something far more compelling was in its genesis at Xerox PARC which we seem to have completely lost sight of. Xerox had made a fortune on photocopying technology and had started a small research group to study what the office of the future might look like. I never had the privilege of using a Smalltalk system which was the product of this research but as I understand it, it was a completely integrated development environment where the lines between the programmer's representation of their program (its source code) and the program that ran were completely blurred. It's rather difficult to describe but, you can think of it in "modern" terms as a type of playground along the lines described in Bret Victor's influential video of 2012 where you edited your program and ran it, all in the same virtual machine except taken to its logical extreme. You could browse and modify components of the system and such as a window's chrome and even the language itself and apply changes immediately as the "program" you ran was just byte-code data in the virtual machine you could update at any time. This distinct paradigm came to be called "Conversational Programming" allowing a developer to rapidly iterate and try new ideas and its success can be attested to by what they were able to achieve in a very short period of time at PARC: Bitmapped displays, popularising OOP, ethernet, windowing systems, the laser printer.
By the time I had my first real exposure to some of these ideas such as messaging and, yes, the [weird syntax], it was through Objective-C, but somehow we were back on the edit-compile-run treadmill and so it has been ever since. These strictures of source and object files and executables have become so entrenched, the concept that a program can be malleable at run time is rarely even considered. Languages that are translated can take a different approach. There is less of this distinction between a static "program" the computer understands and "data" we can operate on. It's all just data and can be modified at will. The power of this flexibility has lead to a surge in the fortunes of these languages as they are lightweight and "agile" in the broadest sense of the word although this alone does not provide true interactivity.
"Conversational Programming" has two components. The first, one could term the "Live Coding" part by which I don't mean demonstrating your prowess in front of a tech conference but the dynamic updating of components of a program's code without restarting it. The second component, one could term the "Hot Reloading" part is a more subtle requirement. Once the program has been updated, how does one ensure the artefacts of running the program (its output, its visual appearance on the display) are updated by knowing which sections of the program to rerun? The second problem is not an easy one to solve but newer declarative technologies such as SwiftUI and Combine may move us closer to a satisfactory solution to this.
"Conversational Programming" also requires a commitment on the part of the programmer. It is a novel challenge to be able to reason about a program that is mutating while you are running it and it's been my experience that many programmers are unable or unwilling to take this additional cognitive load on. It is however something you get better at with time and the longer you do it and the bigger the app the potential rewards in terms of saved time start to add up. One is able to avoid distracting, repeated time consuming builds then having to restart your app and navigate back to where you were working to test your change.
Even in the security conscious world where compiled code needs to be "signed" before it has access to the CPU surprisingly, the components are available to free ourselves of this artificial distinction between "code" and "data" and get back to where we nearly were in the mid 1970s. The compilation unit can be as small as a single source file and it can be recompiled and dynamically loaded into a process if a way can be found for it's new "implementations" to take the place of the old. This was an explicit capability of Objective-C's dynamic runtime (Swizzling!) I felt was never really capitalised on as much as it could have been. But what of "statically linked" languages such as Swift? Where there's a will there's a way...
A year ago I'd never heard of "interposing" but it is a method of indirection used by Apple's dynamic linker to "late bind" references to symbols in system libraries explained at length in this article. What was also a surprise was learning that when you link a program you have the option of making all symbol references indirect in this way and therefore "interposable". This re-opens the possibility of what is essentially dynamic binding and the substitution of function implementations at run time and we're in business; A programming environment where we have the type safety and rigour of a compiled language combined with the dynamism of an interpreted language.
The specifics of rummaging around in symbol tables to find the function pointers to "interpose" and using a small piece of code "fishhook" to perform the interposes are not of interest here. What is of interest is that we have the technology to turn a Source code editor such as Xcode into a "program editor" where saving a file takes immediate effect which gives us the prospect we can find our way back to a truly integrated IDE. A proof of concept for this idea can be found in the InjectionIII open source project. While it runs alongside Xcode rather than being being completely integrated it realises much of the potential of "Conversational Programming". If you're interested in more technical detail, it is laid out in the short book Swift Secrets. Perhaps one day Apple will pick it up and turn it into an accessible mainstream technology to renovate their toolchain. This will help compilers see off the threat these upstart interpreted languages pose to their future.