1. Simplicity and minimalism in software development 2. Introduction 3. Examples of projects Webshop written in Python/ Django. Various internal systems, for example administrative system to handle financial contributions to individuals and organisations 4. Involvement in the Picolisp community 5. Picolisp? Lisp invented by John McCarthy in the late 1950s. Picolisp was invented by Alexander Burger and has been in production since 1988. Implements a Lisp language using a simple virtual machine. Simple in terms of few concepts to keep track of, not simple in terms of power or usability. Picolisp runs on 32- and 64-bit Linux/ BSD systems and on Android. Intel and ARM CPU architectures are supported 6. Discerning features of Picolisp Picolisp is characterised by simplicity and expressiveness. Practically speaking, this means there are few concepts to keep in your head while still allowing you to express program functionality with high precision. This is a lisp interpreter, no compiler is involved. The code you write is the code that runs. It's form is not altered by any compiler. It is a complete programming system, with very few external dependencies. Picolisp is an efficient programming environment, both in terms of machine resources and programmer effort. 7. Writing Picolisp applications As a programming environment, Picolisp comes with an HTML based gui. Applications are accessed using a web browser. The GUI libraries produce HTML, which of course can be styled using CSS. But the applications work just as well in text based browsers, without support for CSS or javascript. An HTTP server is also included, allowing you to run several applications on a single machine. Applications can be started when accessed and goes to sleep when no users are logged in, after a configurable amount of time. Picolisp also includes a database. This is a first class component of the language. The database stores lisp objects in a binary format on disk. All the above are written in Picolisp and there is no need to leave lisp when you define your database etc. You are no longer forced to context switch only because you are working in different layers of the application. Like many other Lisp implementations, Picolisp includes a REPL. What on earth is a REPL? REPL is an abbreviation of "Read Eval Print Loop", and that is a way of interacting with your application, with your Lisp system. Using a REPL results in an efficient way of writing programs, an efficient development style where a running application can be changed on the fly. The resulting applications are usually very small. Code size in kilobytes is normal here, more on that later 8. A real life example As an example from real life I am going to demonstrate two Picolisp applications I have written. Both are in production use. The first one is a program used to keep track of information about donations given in a testament. Somewhat morbid perhaps. ;) This system started life many years ago as a Lotus Notes application. When we started moving away from Notes, I wrote a new version and moved all the data there. This version was written using Python, Django and PostgreSQL, all running on Linux servers. Standard technology, really. The Python version ran along happily for quite some time, without any glitches. One day I got a request to make some extensions and change some things in the system. At that time, I was a volunteer and had my day job outside of the organisation. I had also become involved in Picolisp. I gave the matter some thought and realised I could very well extend the existing program to match the requirements. But where is the fun in that? :) Instead, I decided to re-write the program using Picolisp, since I had a feeling this would result in more functionality produced in a shorter time. And I was right! So, this is a kind of "skunk works" project from me. But since I was a volunteer, the organisation did not have to pay anything for this, and the old version was in place as a backup, should my ideas have proven to be wrong. Some statistics about the program. Remember I mentioned how applications written in Picolisp usually end up being very small? This is no exception. The old version, in Python, was 3.4 Mb of code, spread out over 6 directories and 68 different files. The Picolisp version only needed 92 Kilobytes, across 14 files. It still provides more functionality than the old one. Since database and HTTP server is included in the Picolisp system, the server running the application no longer needs Nginx, Uwsgi and PostgreSQL. A lot of complexity goes away, just like that. Teda now runs on a Linux VPS with 5 Gb of disk space and 256 Mb RAM, but still has a lot of room to spare. Currently, the VPS uses around 970 Mb of the available disk space. Most of this belongs to the operating system. The machine has never used more than around 70 Mb RAM. Naturally, this translates to lower running costs, since a small VPS is less expensive than a large one. Another aspect is that administration is a lot simpler, since the above mentioned components, Nginx, Postgres etc, are not present any longer. There are fewer moving parts, so to speak When it comes to the amount of data, this is a fairly small system, so far. The database contains 1009 different objects, for example data about people who have included the organisation in their will, payments done, solicitors involved etc. The entire database occupies 1.1 Mb of disk space. As you can probably imagine, this simplifies backup routines immensely. We run two backups, each night. One copies the entire database, all 1.1 Mb ;). The other one dumps the data content in CSV format and simply e-mails a compressed archive of the data. This archive is 42 Kb in size. Example application number two is a unified platform including the functionality present from the testament database. This program is larger, but also contains more functions. For example, there is a section used to handle signatures collected on the main web site, another function where staff can report problems in the office and a third section where you can hand in travel requests. This program looks completely different. Since this is a GUI based on HTML, it can be redesigned and re-styled in the same way as other web pages. The platform handles authentication and permissions in a unified way, which means that the users log in to a single web application and get access to the various parts depending on their role within the organisation. When it comes to size, we have grown a bit and now uses 312 Kb. But I think that is acceptable, since this is basically 4 applications under one roof. However, this is still under development, and hopefully I can shrink things a bit along the way. As a matter of fact, I recently made some optimisations to the database layout, and the data now occupies 920 Kilobytes of disk space, instead of 1.1 Mb. So, we are below the Megabyte level even when it comes to the data handled, not just the the program code. 9. Benefits of minimalism In my experience, minimalism in software development provides benefits on many different levels. Apart from the obvious benefits of small applications that can be run with small servers, it also makes it much easier to get started working on a new application. You no longer need to setup a complicated development environment, local databases etc. It is simply a matter of thinking about the problem you are trying to solve, start writing some code and let the code tell you things about the problem, in a way. As the users interact with the program, they are bound to discover new things. This inevitably leads to changes in requirements. Some things that were deemed critical at the start may turn out not to be used at all, and other things surface that were never thought of earlier. Parts of the program must be changed to accomodate the new demands, sometimes the whole program needs to be re-written. Re-writing a Kilobyte sized program is not that much of a problem, and not much of an obstacle to get started compared to having to re-write hundreds of megabytes of code. When I say minimalism, I also mean minimalism in terms of external dependencies. Fewer external dependencies let you own a much larger part of the program, and things are not left in the hands of others. Third party libraries change, sometimes they go away or stop being maintained. 10.Benefits of simplicity Minimalism and simplicity go hand in hand. Picolisp has been created with simplicity in mind and it is one of the few examples where it is possible to understand the entire system, to always know what is going on. When using such a programming environment, less energy is spent on the tool, Instead, you can concentrate on the problem in question. To put it another way, the tool does not get in the way of the task. With this system, you can run the same setup both in a production and development environment. There is no need to worry about handling any differences between them, no problems caused by running different versions. My laptop runs the same Linux version (Debian) with the same Picolisp version as the production server. If a program works here, I can be fairly certain it will work on the server as well. Since Picolisp is such a complete environment, providing persistence and server functionality that is left to other, external, components in many other systems, you stay within the same language all along. There is no context switching any more. Your train of thought is not broken by suddenly having to think in some other language. Last but not least, I believe a simple systems manages to create more fine grained and precise abstractions. The parts are focused on doing one thing. This enables us to build, to mold, a solution that fits the problem. Not the other way around. 11.Minimalism and simplicity - Why bother? It is 2018 now! Yes, why bother? It is 2018 and our computers have virtually unlimited amounts of RAM and disk space. Cloud services can handle the server part and all this server setup can simply be handled by somebody else, somewhere. There are IDE's to take care of projects with large amounts of source code, providing things such as auto-completion of function and method names, generating much of the code needed. So, why not use some of those tools instead? True. Today, computers can handle programs of almost unlimited size. But what about you? What about us? Even with the help of tools such as cloud services and IDE's, we still have to keep the concepts of the programs in our minds. We still have to understand how the different parts fit together, work together. And we have to come up with ideas to turn into software, long before any code is written and any program is deployed. Another important point is that simple systems, simple tools, that may even seem simplistic at first glance, usually fosters creativity in a way not done by large solutions and tools. It is easier to create a solution molded to the problem, lika a hand in a glove, when using a simple programming system. Large systems may provide the functionality needed out of the box, but it often not the precise funtionality you need. You end up getting something that is almost right, but not quite right. You end up using a subset of the provided functionality but still incorporate a lot of code not needed. A counterpoint now. Writing a database system, server, etc. does not sound very simple. It would have been much simpler to use some other, existing solution, for this. Why go through all the work of doing this yourself? How does that benefit anyone? This is a good point, a good question worth talking about. In my view, the time and effort doing this is very well spent. Persistence and server functionality will be necessary in more or less every single Picolisp project that is to be created. So, when these parts are written, they will be very, very useful. Since these are such vital parts, it is also very important to fully understand how they work, to know the ins- and- outs of how they work. I know of no better way to achieve this that to write things yourself. The end result is a complete system where all the parts fit together very well. The effort spent initially pays off immensely, every day, and gives you a simpler, cohesive, environment. It is not just the system that evolves when doing things yourself. You do too, and this is vital. This is similar to running, to train for a marathon. You and only you must do all the running, every single mile. No one else can do that for you. But it is also you, and no one else who benefits from doing so. You get better, not anyone else. The knowledge gained this way does not go away, instead it allows you to move forward and create better things. Of course, it is very satisfying to work this way too. Happy programmers are better programmers, and Picolisp has made me smile more while writing code that any other language I have come across ( maybe this last point says more about me than the language in question ;) ) 12.Some elephants in the room Criticism of syntax, from Perl creator Larry Wall. I like Larry Wall, but I have never gotten used to Perl syntax. It obviously works well for a lot of people, but Lisp syntax does too. These things are often a matter of personal taste. Lisp felt strange to me as well at first. I was used to Python and Java. But Lisp grew on me quickly and it does not feel strange any longer. On the contrary, Lisp has a very consistent and simple syntax. It is built up of lists, using parenthesis as delimiters. That is the basic idea. Depending on "unknown" technologies. There are risks in depending on any technology. For example, today, various javascript frameworks are very popular in web development. This is considered standard technology and not many would question a decision to use it. However, javascript frameworks seem to pop up and disappear almost overnight. Frameworks that are widely used today somehow get left behind and are replaced by new ones very quickly. Developers often follow this pace and you risk getting stuck with older technologies that developers no longer want to use, despite having selected a popular, common version when you started out. Angular is an example of this. Finally, everything that is considered common, household, technologies today started as an unknown, new, technology. At first, Python, Java, C, Linux etc. were all examples of "unknown technology X". It takes time to learn new technologies. Yes, that is true. If you are in a hurry, you should probably solve the immediate problems using what is familiar. But when the fires have been put out, consider what it would be like to use something else. This is a great starting point to learn something new. Apply it to a familiar setting. How come this is not used more? Good question, and one that is not restricted to programming. Bieber sells more records than Beethoven. Quality and popularity do not always go hand in hand, but can be at opposites ends of the spectrum. The question is not so much what others do and use, but what you want to use, how you want to work. That is something we can decide for ourselves, from our own experience, regardless of what is considered popular at any given moment Closing remarks I would like to finish this talk with a reflection on software and computers. In my view, computers are machines capable of changing form and function with the help of the programs we write. We must find the form and function of the task at hand and then create a program that fits this shape as closely as possible. A simple and minimalistic, but complete, language and programming environment is able to produce a program that fits the task at hand better than a large and complicated environment. It is like filling a glas with sand. The sand forms itself according to the surrounding shape and leaves only very small gaps. The large, well- known, languages and frameworks in use today resemble filling the same glass with Lego bricks instead. The pieces leave large gaps and are unable to fill the surrounding shape precisely.