As I read the article I started to wonder how much was actually cynical since a language without all the features described at first feel ridiculous. However if you look at every one of the language features discussed in isolation there is a good argument for not using each one of the features so why not do without all of them?
No side effects?
I don't intend to go into detail on all the features already discussed in the article but I want to add another feature to the list. But first let's look at one of the features in the article; mutation. Initally it made sense and when I started thinking about additional features I could live without I considered classical side effects like printing text on the screen or saving data to a file system. One of the examples in the article claim repainting the screen is a mutation of the sate of an object. Hey that is one of the classical side effects! A lot of languages that claim to be immutable still have methods to deal with things like repainting the screen or interacting with the file system. Could we really be without those methods since a program with no classical side effects is kind of useless.I think the answer to that is that while your program needs to do things that historically are considered side effects, the functions causing this do not need to operate on mutable objects. For example the new screen state could be returned as a new object. So anyway my idea of adding no side effects to the ultimate programming language was already covered.
No heap memory allocation?
But I didn't give up. Instead I considered heap memory allocation. A lot of performance related bugs I encounter are related to object allocation and later garbage collection of said objects. I once worked on a system in C where we never allocated any memory on the heap dynamically. All memory was either allocated during startup or on the stack. Hence we could prove there were no memory leaks. If I could remove all use of heap memory no garbage collection would be needed since the life time of all objects would be based on the stack. That would definitely remove a lot of memory, performance and resource related bugs.Some of you might argue that without heap memory allocation isn't actually reducing the number of possible programs towards the number of valid programs but still these bugs are so terrible to deal with that removing them completely would be a win-win for all.
No locks and threads?
As I was writing the previous section I realized that the system in C I referenced above also was single threaded. It did several things concurrently but it was single threaded. A lot of bugs comes when people write multi-threaded applications. For performance reasons you obviously still want your program to run on multiple cores in parallel but I think a language that hide this fact would reduce bugs a lot. And if the thread concept is hidden from the developer, related control structures as locks should also be hidden.I have actually worked in a few frameworks built on top of other languages where concurrency was hidden from you and it is surprisingly easy to build effective parallel programs without deadlocks in these frameworks. It is however also very easy to create bottle necks unless you work with immutable objects...
It is not that simple. Consider C# value types as a good example. The only reason they were added to the language is performance. I would love to get rid of it, but it does really boost the performance.
ReplyDeleteFeatures you listed in your post are all very nice to get rid of, but we do not know how to do it *right* yet.
Therefore, if we are dreaming then 80% of the features in the modern programing languages are eligible. Just think of places where they go for performance. If it was not for the performance we probably would write applications differently altogether!