This blog post looks into which methods and technologies that can potentially lead to the replacement of coders in the future, some are of futuristic nature but some are more “low-hanging” wrt automation of (parts of) coding.
The background for this blog post is that researchers Jay Jay Billings, Alexander J. McCaskey, Geoffroy Vallee, and Greg Watson at Oak Ridge Laboratory wrote a paper: Will humans even write code in 2040 and what would that mean for extreme heterogeneity in computing?
Also related to this is (Tesla AI director) Andrej Karpathy’s article: Software 2.0 where he looks back at how AI (primarily Deep Learning) has replaced custom methods for e.g. image and speech recognition, machine translation (++) and generalizes how Deep Learning can further replace a lot of other software in years to come (note: examplified by Google’s recent paper The Case for Learned Index Structures)
1. FACT: Programming environments (IDEs) have barely changed the last 30 years
One of primary purposes of programming is to provide efficient automation, however programming itself is still a highly manual and labour intensive process – except for refactoring the difference between modern IDEs compared to e.g. Turbo Pascal in 1989 is surprisingly small? (Turbo Pascal came out more than 30 years ago and improved gradually towards 1989)
|Turbo Pascal 5.5 in 1989||Eclipse in 2017|
2. FACT: For (close to) all FUNCTIONS written there exists one or several TESTS for it
For any method already written (or to be written) in any (of the most popular) languages currently used in programming there already exists a test for it – in the same language or in a similar language (e.g. a C# test for a Java function). The obvious (big) data source for this is all private and public repositories in Github (100M pull requests merged so far in 2017)
So why are most developers still writing unit tests instead of having an IDE/service find and translate the appropriate tests to the functions they write? (e.g. something along the lines of IntelliTest)
3. FACT: as 2 – For (close to) all TESTS there exists a (set of ) FUNCTIONs they test
Assuming e.g. with Test Driven Development (TDD) – where you are roughly writing the (test of the new) API first – and then alternating between creating in the code to (just enough) fulfill the API.
This seems like it has 2 potential ways of being increasingly automated – on the function writing part.
- Search for a set of function that matches a set of tests – instead of writing the functions just write the tests
- Automatically generate the code (fragments) to fulfill the test, this can potentially be done in many ways, e.g.
- Brute force with a lot of computers (e.g. a few thousand CPUs in the cloud should be more than capable of quickly generating and selecting the best of maybe up to 30-50 increments needed per test writing iteration, this resource could be shared by a large set of programmers). See also the science of brute force.
- Using sophisticated AI methods with GPUs – e.g. Program Synthesis with Deep Learning and earlier AI methods such as variants of John Koza’s Genetic Programming.
- Quantum Computer – e.g. Logic Synthesis with Quantum Computing (see also Quantum Development Kit)
4. FACT: (Many?) Data Structures can now be replaced by AI (e.g. Bloom Filters & B-Trees)
Google – with Tim Kraska, Alex Beutel, Ed H. Chi, Jeffrey Dean, Neoklis Polyzotis published an interesting paper: The Case for Learned Index Structures where they showed that traditional and popular data structures such as B-Tree, Hash Index and Bloom Filter can be with advantage be replaced by AI Trained Index Structures. This is from my perspective pretty groundbreaking research and will be interesting to see what the use cases can be towards program synthesis (e.g for other categories of data structures and also logic operating on data structures). Key result figures from their paper:
5. FACT: Formal Methods are starting to work and can be used to support automation of code
Amazon has used formal methods since 2011 for Amazon Web Services, e.g. to ensure the quality of AWS S3 – see Use of Formal Methods at Amazon for an overview. Facebook is using formal methods for mobile application quality assurance, see Moving Fast with Software Verification. Formal methods has also been used to validate various blockchain technologies (potentially Bitcoin), see e.g. A Temporal Blockchain: A Formal Analysis, Blockchain Protocol Analysis and Security Engineering 2017, Validation of Decentralised Smart Contracts Through Game Theory and Formal Methods
A few years back I participated in a research project – Envisage (Engineering Virtualized Services) – where formal methods were used to prove that the TimSort algorithm was buggy in a lot of languages (See Hacker News story below). Formal methods can potentially be used together with code generating methods to ensure that what is generated is correct.
Have presented various technologies that might play a role in automating coding forwards. A potential interesting direction on the generative side for coding is to use sequence to sequence deep learning in combination with GAN for synthesis, see e.g. Text2Action: Generative Adversarial Synthesis from Language to Action – for program synthesis this looks like a