The illusion of Open Science

 The dominant theory about the upraising of Open Science puts the society or governmental decision into the role of decision maker and the goal is to convince more scientists that Open Science is a great idea. So it is some sort of ideology and political movement to open up research and make the publications free to read to the world. The main reason why this plot is repeated is because it give to the stakeholders the illusion that they have everything under control. Which means, that a certain scientists can decide by himself or the political decision makers can give Open Access a higher priority or not.

A closer look onto the problem of Open Access will show, that it is not the result of a decision making process but the reason is located in technological development. The first open access server in the world was the arxiv repository. The simple reason why the project is up and running is because:

- the costs for a webserver a low in the internet age

- the existence of desktop computers and the LaTeX textprocessor is common for scientists

- if Arxiv hosts many thousands paper it is pretty easy to write more of the same content

These technical conditions have resulted into a successful prepreint server. Bascially spoken, the simple reason why Open Access was started is because the manuscripts are in the digital format available so it is easier to upload the document to a webserver.

Like all technological innovation like the car, the computer or the telephone the process was not managed and there was no higher instance who has to decided to introduce it, but if new techhology was working fine, it was adapted as quickly as possible.

It is interesting to observe the Open Access was started around the same time like the desktop computer. The first electronic scientific journals on CD-ROM were available at the same time the CD-ROM was invented, and desktop computer were there to create such content. This sounds a bit trivial but between the invention of desktop publishing and electronic publishing there is a causal relationship available.

To understand the Open Access movement we have to identify technology which supports the creation of academic papers. Potential key components are full text search engines, desktop publishing software, bibliographic databases, document formats like the Postscript and DVI standard, Unix workstations and a larger amount of people who have access to these thing. The resulting open access movement is some sort of logical consequence.

The situation has much in common with the interaction between a human and other tools, for example a hammer. If somebody has bought a hammer, he will search for situations in which he can use it. And if somebody has installed the LaTeX package on his workstaion, he will write a simple hello world academic paper next.

Is C the optimal language for programming the C64?

 The good news is, that the problem of identifying the ideal programming language can be reduced to only two: Assembly vs. C. It is pretty easy to show, that C code will run slower and needs more RAM than the manual created assembly code. A typical example would be a prime number generator.

The more interesting question is, how much exactly C code will run slower. Somewhere in the internet it was written that without using cc65 optimization techniques the C code will run 5 times slower. On the first look this speaks for replacing C code with assembly. But a closer look will show, that slowdown by the factor 5 is not very much. Suppose there is an algorithm which needs 60 seconds. If the same algorithm was rewritten in Assembly it will need only 12 seconds. In both cases, the algorithm won't run in realtime but the user has to wait in front of the machine.

The main concern with assembly language is, that the sourcecode isn't readable. Even if the programmer is using lots of comments, the code will look messy. This is perhaps one of the reasons, why C has replaced former assembly coding.

Suppose the hardware is a bit faster than the original 6502, suppose some optimizatinon techniqfues in the compiler were activated, then the chance is high, that the C code will be only 2 times slower than the assembly language counter part. This slow down is acceptable because the code is way much easier to read.

Let us make the situation more practical. A naive prime number generator works with two nested loops. Such an algorithm will run in assembly around 5 times faster then the C counterpart. But, a more advanced sieve algorithm will run much faster, no matter in which programming language it was implemented. That means, the sieve prime number generator written in C will outperform the nested loop algorithm written in Assembly language easily.

The problem with coding assembly language is, that it is difficult to write longer and more complex algorithm. Implementing a sieve algorithm in Assembly is an advanced project. That means, even an experience programmer will need many hours in doing so.

It is a known fact that during the 1980s the c language was not very popular for the Commodore 64. All of the demos were written in pure assembly code. This fact is known, because the sourcecode of the demos is available and it is normal 6502 assembly code. But what if the demo competation has the contraints, that the code has to be written in C?

since a while the C64 community has discovered the cc65 cross compiler again. They are trying to use this environment to write games from scratch. The resulting games are look not impressive as the Assembly demos, but they are easier to read and it takes less effort to code them.

A list of some games written in cc65 are available at https://wiki.cc65.org/doku.php?id=cc65:cc65-apps The quality of these games is low. They are looking like the early c64 games from the 1984 year.

An interesting side question which remains unanswered in this blog post is, if Forth can outperform the C language on the C-64. the problem with Forth is, that most existing Forth systems are only interpreters, they are not converting the code into assembly instructions so the resulting program will run slow. What is known from the MS-DOS PC is, that compiled Forth code can reach the same speed like compiled c code.[1] That means, compiled forth code will run slower than hand coded assembly code.

[1] Almy, Thomas. "Compiling Forth for performance." Journal of Forth Application and Research 4.3 (1986): 379-388.

Comparing Google scholar with Microsoft academic

 

Google Scholar was the first attempt in building a search engine for academic papers. It is mostly known for it's powerful capabilities to search inside the documents and in contrast to websites of dedicated publishers it can search in the content of all the information available. After typing in some keywords, Google scholar returns a list of useful documents, similar to the normal google web search. And very important, it provides the formatted bibtex information as well so the found knowledge piece can be cited easily.

Most users have no need to try out a potential alternative. Microsoft Academic was developed later but it is used seldom. A closer look will show, that Microsoft Academic can't replace google but it can provide useful additional information. The strength is, that that Microsoft Academic has more in common with a classical bibliographic database. All the information is labeled with tags like “operating system” or “programming language”. In addition, the user can restrict the result list to papers, conference proceedings or books. The most interesting feature of Microsoft academic is, to change the sorting order. For every paper or book the amount of raw citation is shown. This allows to answer a question like “which books for a certain topic are popular?”, or “how many papers in a subject remain uncited?”.

Let us make a simple experiment. We are restricting the year from 1990 to 2000, select the domain “programming language” and show only books ordered by the raw citation count. The result page is some sort of recommended reading list. If somebody has no experience he can read the most referenced books and its for sure, that he will like them all:

1. Edmund M. Clarke: Model Checking

2. James Rumbaugh: Object-Oriented Modeling and Design

3. Martin Fowler: Refactoring: Improving the Design of Existing Code

4. Ed Anderson: Lapack Users' Guide

In contrast to a human guided recommendation list, these four books were determined by statistical information of the citation count. They are an objective list of books who are relevant for a discipline. A good library will provide these books, because they are requested frequently.

Let us imagine the situation from a broader perspective. Suppose there is a university library which has room for only 2000 books but not more. Which books should the library buy? The answer is, that they need to buy the most requested books, because the chance is high, that the student will find what they need.

Thanks to the Microsoft academic search engine, the concrete list of books can be created easily. All what the librarian has to do is to write down, the most cited books in each subject. In the example, 500 different subjects are there and each slot is filled with the most 4 important books. The result is a small but beautiful classical printed library which will be liked by its students very much.

The most referenced books for programming languages was mentioned before. Does it make sense to reduce all the books to only 4? Yes it is possible, because the requirement is, that the imaginary library doesn't have more space. Each single subject can only be filled with a restricted amount of books and not more. If “programming language” is supported with 20 books, the other categories available will be ignored. The hard to answer question is, which four books are important enough to become a role model for a single domain?

The entire domain of programming language has around 300k publications which are papers, conference proceedings, books, and postscript files in different repositories. The reason is, that a lot of people has contributed to the subject in the past. If a library likes to store all the information, it has to become a huge building.

Coach based artificial intelligence

 

The problem why Artificial INtelligence is difficult to realize is not located within the machine itself. Because software engineers are experts in writing software. The sourcecode compiles into binary code and if the compiler doesn't find a mistake, everything is working fine. The more demanding problem is, if a software is working fine on the first look but at the same time it is doing not what is expected. That means, the program compiles great into binary code but the robot isn't able to solve a task.

Fixing such problems is much harder and if it is not done another failed robot project is the result. Before it is possible to realize more advanced software the bottleneck in existing systems has to be described. It has to do with man machine interaction. Man doesn't know who to comand the machine, and the machine isn't able to obey to the human. It is a bit unusual but Artificial Intleligence can be realized only with better man machine interaction.

IN a teleoperated situation, there is a machine, a human operator and a robot. Realizing these system is possible. The joystick command of the human are converted into machine actions. Such systems are possible for a robot crane but they have failed for more demanding tasks like controlling a train or a care. The reason is, that these systems need very complicated input signals. For example the cockpit of a car provides not a single joystick but the human operator has move the car at the same time left and right and has to decide which speed is needed and in some older cars, the human operator has to control the gear as well.

It is complicated or even impossible to control such a system with remote control. So the question is how to design a human to machine interface which fits to more complex domains. A possible attempt in doing so is a coach based interaction paradigm, which is equal to a hiearchical system. There is coach on the right seat of the car, a driver on the left side, and a cockpit which receives the commands of the driver.

Such a system consists of an advanced command hierarchy. The coach provides the high level goal for example “move ahead”, the driver converts this command into low level steering commands and the cockpit translates the actions of the driver into motor commands. Let us imagine who to automate the pipeline a bit. The idea is to replace only the human driver with a software but let the coach in the car. That means, the human operator plays a certain role. He provides high level goals for the AI Software. The AI software converts these goals into low level steering actions.

Such a system can be realized but it remains an advanced software project. Parsing the command itself is the easiest part of the system. There are many voice recognition software available which are able to convert a spoken command into textual information. The human coach produces a .wav file and this gets converted into the string “move forward”. The more demanding task is the follow up step. How to convert the command string into low level steering commands?

One option would be a lookup table which is realized with a case statement. That means, each statement is converted into predefined action sequence similar to a macro. IN the example, move forward would be converted into “car.speed(20)”. The problem is, that such a direct mapping can't handle different situation. The command “move forward” can be used in many situations but it will generate different low level actions. The more elaborated translation attempt would be to interpret a command as a goal. It is up to the solver to fulfill the goal.

For example, the command “Move forward” can be translated into:

1. remain in the current lane

2. hold a speed of 20 mph.

3. if the current steering angle or the current speed is different, then adjust them

Limits of automation

 

Telerobotis is a well known technique in which human operators are asked to control a robot. A typical example is a crane. Teleoperation is equal to let a human play the game. He has to provide input signals which affects the robot's behavior.

Most robotics engineers are ignoring teleoperation because their goal is to go beyond this capabilities. Robots in the core sense is about replacing teleoperated machines with fully autonomous ones. Let us try first to describe the situation technically.

Suppose there is a video game which is played by a human. The idea is to replace the human with an AI Software. If the software is able to play the game then the human operator was replaced by a machine. But is this assumption correct? Chess engines which are able to play the game are available since the 1980s and they weren't able to replace human chess players. The reason is, that human are playing chess different from a computer. The only thing what is widespread used in the reality are teleoperated chess games which are played over the internet. But on the other side a human is needed to provide the signals.

This sounds surprisingly because from a technical point of view it is possible to replace the humans with a chess engine. But his is not wanted by the chess community. This example questions if it is possible in general to replace human operators with software.

Many programs were written to control robot arms and robot cranes with software. None of them is used in reality. The only piece of software which is relevant is software which supports teleoperation mode, especially algorithm for determine the inverse kinematics of a robot arm. Software which goes beyond this capabilities is available but it is not used in the reality.

The interesting situation is, that more advanced robot projects have the same interaction pattern. Creating a biped robot is possible since some years. But again, these robots are mostly used in teleoepration mode because otherwise it doesn't make much sense.

From a history of automation there are two possible insights available. Simple mechanical machines can be used autonomously but more complex robots are used always in teleoperation mode. The reason has to do with economic goals.

From a technical perspective it is possible to run a robot arm in a fully autonomous mode. The gripper picks up a ball and places it at the goal position. So it makes sense to explain to the audience that this robot doesn't need a human operator. But, if the machine is used for economic purposes, for example in a factory it will be run be a human operator and never in the autonomous mode. In the past it was argued, that the software is not highly enough developed. But the underlying problem has to do with man machine interaction .

What if voice commands don't work?

 

On the first look, voice command seems like a reliable man machine interaction technoogy. The human operator speaks a command like “stop” and the robot is executing the command. This allows a soft transition from teleoperated devices towards fully autonomous one. A possible application would be voice operated train.

The main purpose, why voice commanded robots are interesting is because they are within reach of today's technology. The engineers are able to build such systems and they can be deployed for real applications. In the example, with a voice controlled train, the robo-train would understand 20 simple commands and the human operator remains in the loop all the time. THis allows to equip the system with software without bypassing the existing human operator.

If voice commanded robot are a great idea, it is a here to stay, right? Not exactly. The problem with voice commanded robots is, that they are similar to all sorts of robot an AI Technology. Such technology isn't available yet but it has to be invented. The promise is, that after the train is recognizing voice commands, the human operator can reduce it's workload. But how realistic is such a promise?

The main problem with AI technology no matter which sort of them is, that it has a tendency to work not as robot but as artificial life. It is pretty easy to design systems which are not in control of a human operator, and a voice interface is not an exception. The pessimistic prediction is, that a voice controlled trains won't work. After installing the software and explain to the train driver how the system is working it won't fulfill the needs. And even the engineers who have programmed the device doesn't know the reason why.

But let us go a step backward to understand the situation in detail. The idea is, that a voice controlled train reduces the workload for the human driver. Instead of steering the train with a joystick, the human operator has to talk like “move slowly forward”, “hold speed” and so on. Instead of pushing the joystick manual for 10 seconds forward, he speaks a single command in to the micromphone which produces the same effect. The situation is introduced in the literature as a coach system. The human operator plays the role of a coach. He provides only the general goal and the system figures out the detail. Very similar to explaining how to control a train to the newbie.

In such a case, an experience train operator will talk the same way. He will say, “move slowly forward” and the newbie operator has to execute the task The problem with a robot who interacts in such a way is, that he provides an additional complexity not available before. That means, the robot won't simplify the situation but it will make the things difficult to grasp.

Perhaps it make sense to investigate who a coach to newbie interaction works in the classical setup. The experienced trains operator gives a command, for example, he can say “start the engine”. It is up to the newbie train operator to fulfill the request. He has to press a button for starting the engine itself and he has to make sure that the warning light goes off. In response the newbie can answer the request with “engine was started”.

The interesting fact is, that such an interaction has nothing to do with the train itself, but it reflects the communication between two humans who are operating on the engine. Both operators are forming a hierarchy. The experience train operator decides, that the engine has to be started at a certain moment. And the subordinate has to figure out how to do so.

The interaction between an experienced operator and a newbie is the best practice method for teaching a complicated subject to a newbie. Even if somebody has no experiences with train control he is able to play the role of a newbie who has to execute the commands of the operator. The reason why this social role works well is because a human is motivated to play the role o a subordinate. In contrast a voice controlled software won't do so. There is no need for the software to execute the commands from the human operator and at the end the human has to follow the instructions of the robot.

Whats the problem with self-driving cars?

 

Some attempt were made in the past by Waymo and Tesla to push autonomous driving forward. In an interview a journalist has asked at which moment in the future these cars will become available for the public. The engineers itself doesn't know. There is a general prediction available that after 2025 autonomous cars will be available but it is unlikely that this will become the reality. In theory it is possible that in 2025 the starting point is delayed to 2035 and so on.

This sounds surprising because from a technical perspective all the problems are solved or can be solved with minor improvements. Today's software connects a car with a cloud based infrastructure, a 3d lidar scan creates a precise map of the environment, the SLAM self localization algorithm knows where the car is, and advanced path planning generates the route for the car. So, where is the bottleneck, why are autonomous cars not available?

The problem is, that autonomous cars are without any doubt an AI technology. AI means, that it wasn't available in the past but everything was invented from scratch. The interesting situation is, that Artificial Intelligence has failed to control more simpler domains, which are autonomous trains and autonomous subways. And the engineers want to automate highly complex cars which are driving next to human controlled vehicles.

Instead of asking at which moment autonomous cars will become available we have to ask why it is so complicated to automate cargo trains and the subway. From a technical point of view, a train has no steering wheel but it can only accelerate and brake. The workload for the human operator is much lower and it is easier to create software which can handle the task by it's own. The reason why these software isn't used in reality is because train automation is to complicated for today's AI as well. Or to be more precisely, every task in the world which is important can't be handled by AI algorithms.

Let us analyze some existing press reports about train automation. There are some success stories available about robotics project. The shared similarity is, that all of these attempt are explaining how the future will look like. Not a single example for a working prototype is available. What all the railway companies are doing is that they are figuring out how to realize such future trains. But no one has found a reliable solution which can deployed in the reality.

To understand the situation we have to explain the difference between AI based automation and non AI automation. Non AI automation means to build highly complex machines but let a human operator control the system. AI based automation is the other way around. These systems were designed without a human in mind. Let us give some example. Non AI technology is a minor improvement of existing machines. For example the train gets a better chair for the pilot. Or the monitor gets a higher resolution. Everything else remains the same and no experiments are needed. This sort of technology has a high chance to become reality within the next 10 years.

In contrast, AI based technology is trying to reinvent something from scratch. Instead of improving something by 0.1% the idea is to revolutionize the domain, reduce the costs to a minimum and show what state of the art technology is about.

Autonomous trains

It was claimed that autonomous cars and trains are not possible within the near future. To understand the reason why we have to investigate some press releases about current projects. Autonomous trains are introduced to the audience as a demand. It is explained, that the requirement in the future will become higher and there is need for robotic trains. This statement is correct. Indeed the demand for such technology is there. In another press statement it was written that in the year 2019 an autonomous train was demonstrated on a 48 mile test track. Some detail information about the technology was given too. In another article, autonomous trains are compared with automatic elevators and it was made clear that some challenges need to be addressed before the technology is available.

Does this look like something which is available today? Or which can be realized within the next 10 years? No, it is a vision for future transport systems and nothing else. It is a technology which can improve the life and reduce the costs but nobody knows how to realize such things.

Perhaps another example would help to understand what the situation with robotics is. In the year 2011 the japanese powerplant in Fukushima was hit by a tsunami. At this time, no robots were available to fix the problem. This was a surprise for the public, because in the TV many prototypes were shown in the year before. From the year 2011 until 2020, robotics engineers have taken the issue more seriously and have developed new robots, which can be used for practical applications. Really? No they didn't. The current status is the same like 10 years ago. No robots at all are available. Even remote controlled robots are not reliable.

Why are robots not available?

How can it be, that on the one hand advanced biped robots are developed by engineers and autonomous cars are demonstrated on a real road, but at the same time, the technology is not available for deployment? The paradox can be understood by explaining what is shown exactly in a video or in a paper about a biped robot. Suppose a new robotics video was released in which a robot is able to climb stairs and play football. For the audience, this demonstration looks very impressive and the engineers are proud of the newly written software. The shortfall is, that the demonstrated technology isn't a robot but it is artificial life. Artificial Life looks very impressive to humans but at the same time it is completely useless.

A useful robot is able to replace a human worker. This is the meaning of the word robot. In contrast, Artificial Life doesn't replaces something but it is adding something not available before. Creating artificial life is from a technical perspective an easy to solve problem. The early braitenberg vehicles, a computer game with AI characters and today's biped robots can be understood as artificial life. These machines are doing something, and they need energy for the task. The problem is that humans can't utilized this behavior for their own purpose.

What humans are doing instead is to invent the task which fits to the robot. Let me explain the situation in case of an autonomous car. The starting point is to build the car including the sensor and the software. An engineering team assembles the onboard computer, the lidar and the gps navigation system into a self-driving car. In the next step the car is released to a track on the normal road. The assumption is, if the cars drives on a normal road during a rush hour and no human intervention is needed the engineering team was successful.

No they don't. What the engineers have done in reality is to redefine the public road into an experimental track. Not the AI controlled works fine, but the other cars are robust against interruption.

Kitchen robot

Robots are not helping the humans but they force them into a certain social role. In case of a kitchen robot this problem should be explained briefly. Suppose, a kitchen robot was built which can make a sandwhich with two dexterous arms. Building such robot is possible with today's hardware and software and some online videos are showing how such a robot will look like.

Focussing only on the robot itself is only the first step. The more interesting problem is, how to deploy this technology into the reality. There are two cases available. First idea is, that a normal kitchen gets improved by the robotic helper. And the second idea is, that the robot gets deployed into its own kitchen and humans are invited to join the room.

The second case is shown in the reality. The robocup@home challenge has demonstrated these robots. In all the videos, a newly created kitchen was shown and the human participants are acting with a certain rule set. They get a clear instruction how to interact with the sandwich making robot. At first, the human has to smile. Then he has to press the start button, then he waits some minutes until the robot is done, and then the human has to take the sandwich and eat it. He has to stand in a certain angle to the camera so that the robot and the human is shown at the same time.

The interesting situation is, that the robot can't be deplayed into a real kitchen. Because in this case, the human operator has to guideline who to interact with the robot. It doesn't make much sense to press the start button if no camera is filming the scene. Even the engineers who have created the kitchen robot have no working robot in their own kitchen. If they want to eat a sandwich they will order it from a company.

Artificial demonstrations

Perhaps it makes sense to analyze in detail how robots are deployed into artificial use cases. The robocup@home challenge was mentioned already. It is one of the most famous robotics shows in the world. In a larger building many robots are shown at the same time. There is a soccer playground, a kitchen and a maze with obstacles. All these domains are created from scratch. That means, the kitchen isn't used as a real kitchen, but it is a kitchen to deploy robots.

In such a non human kitchen, the robot laws are established. The engineers who have programmed the robots want to show a certain behavior. They are creating around the robot a scenario which contains of different tasks. What will happen, if no audience and no camera are available during a demonstration? The robot kitchen is useless. It works only if somebody will see what is going on.

This is perhaps the most major difference to a real kitchen. In most kitchens, no cameras are deployed which are filming the scene, but a kitchen is the room in which the meal is prepared. The interesting situation is, that the gap between an artificial kitchen and a real one can't be bridged.

All the advanced robots shown in television and described in academic papers are working fine in artificial situations. Around a certain robot, a scenario was created which has to be solved by the robot. A biped robot needs as an environment a staircase. An autonomous car needs a road, and a pick&place robot needs an object. The funny thing is that the robots can handle these domains very well. As the result a human observers things, that the engineers have solved a certain problem with advanced algorithms. The problem is that an artificial playground a real world applications are working with different rules.

Basically spoken, if a sandwich making robot is creating a sandwich in it's own kitchen the task is useless. Except the engineers, nobody cares about the result and nobody would buy such a robot for it's own purpose.

What is a robot kitchen?

A robot kitchen is an artificial playground to demonstrate AI technology. It contains of a refrigerator, a table and some food and helps to evaluate the capabilities of a robot. A certain robot can grasp the apple from the table or he fails with the task. A robot kitchen is some sort of a game. It is not part of normal life but was created from scratch to evaluate the consequences.

Robot kitchens are used frequently by robotics engineers. All the papers in which advanced household robots are mentioned are shown in robot kitchens. The assumption is, that a robot kitchen is a great testbed which helps to bridge the gap between reality and imagined future. If a task was demonstrated in the robot kitchen, the robot is ready for deployment – this is at least the claim.

What exactly is the meaning of deployment? The idea is that a robot is sold to the public, replaces human workers and is doing a task by it's own. The reason why robot kitchens were built is because to support this goal. The paradox situation is, that at the same time an artificial environment prevents that a certain robots gets released to the public. To understand this situation we have to take a look into the history.

In the 1970s the assumption was that industrial robots can be deployed directly to the industry. The engineers have identified a workplace, and created a robot for this job. Then the machine was powered with electricity in the hope to increase the automation level. After some attempts it was recognized fast, that the newly installed robot was doing a poor job. After a while the machine was switched off and it was labeled as a failed automation project.

The idea of the engineers to improve the situation was to invent a playground to extend the testing of a new robot in a realistic scenario. Such a playground can be a virtual simulation on the computer screen, or a robot competition like micromouse. Since the 1990s, such playgrounds are used frequently and they evolved over the years.

Creating new playgrounds and programming robots which are working well under artificial condition is an easy to solve task. What remains an open problem is how to transfer a robot from the playground into the reality.

Automation market worldwide

According to the latest stats, around 2.7 million robots are available in the world and each year 350000 new robots are shipped to the companies. On the first look, these numbers are looking very positive. It is a sign, that the robot revolution has started and it is growing.

A closer look into the details will show, that automation is never realized with robots but with automation technology. Automation technology means to install electrical servo motors, assembly lines and even an electric driven truck. There are many obvious problems with the mentioned 2.7 million robots worldwide.

First issue is, that a large amount of robots are nothing else but classical automation technology. For example, a CNC machine is not a robot. Second problem is, that lots of real robots for example robot arms are not used in production environment but they are sold as teaching robots. They are used outside the factory in a university lab.

A positive future

There is a reason available why robotics projects are not analyzed with objective measurements. Because the engineers are believing in a vision. They want to change something in the world, and see a robotics project as one way in doing so. The first place in which robots were mentioned was the science fiction literature. They were developed as tool to tell a new sort of stories. Then the same idea was established in the reality. A robot project gives an idea about a possible future world.

If robotics engineers would be honest to themself, they know in advance that their robots are useless. But if they are not creating such projects, who else is in charge? Somebody has to stand up and claim that robots are useful in the world of tomorrow.

Suppose it is possible to convince today's robotics engineers that their work is useless. All the autonomous cars, robo trains and kitchen robot projects would be stopped because of missing values. From a rational perspective this would be the optimal decision but is such a future a nice place to life?

Warum größere Projekte in Python keinen Sinn machen

2017-10-04 C++, import from other blog

Von den Sprachstandards her ist Python ausgezeichnet um größere Projekte darin zu realisieren. Die Python Virtual Machine ist hinreichend robust, die Python-internen Möglichkeiten zur objektorientierten Programmierung sind vorbildlich und das Modulkonzept erlaubt es Klassen zu Packages zu aggregieren. Technisch gesehen kann man mit Python durchaus Projekte mit 100k LoC oder sogar noch mehr realisieren. Es gibt nur ein Problem: wer möchte diese Programme verwenden? Endanwender machen üblicherweise einen großen Bogen um GUI Applikationen die in Python erstellt wurden, und Systemprogrammierer werden garantiert keine Libraries einbinden, die in Python geschrieben wurden. Dagegen spricht schon die geringe Performance. Python erinnert an das Schicksal was Turbo Pascal ereilt hat: es ist eine Lehrsprache in der Programmierausbildung, kann aber nicht für reale Projekte eingesetzt werden.

Die Sprache als solche ist vorbildlich: Python ist sehr elegant designt. Und es lässt sich darin auch produktiver Sourcecode schreiben, in dem Sinne dass man für einfache Aufgaben wie das Sortieren eines Arrays eben nicht erst tagelang in Foren um Rat fragen muss, sondern einfach den pythonic way of life verwendet. Nur, stellen wir uns mal vor wie das in der Realität konkret aussieht. Man schreibt sein elegantes Python Programm runter, es besteht aus 12000 Lines of Code, nutzt dafür selbstverständlich mehrere Klassen und dann? Rein theoretisch ist das Script jetzt überall ausführbar, aber wer will das auf seiner Maschine tatsächlich verwenden? Das Problem mit Python ist, dass es nur eine weitere Programmiersprache ist in einer ganz speziellen Nische (anfängerfreundlich und interpretiert) und das der damit erstellte Code garantiert nicht in größere Projekte wird einfließen. Genau genommen kann man Python Programmierer nur bemitleiden, weil ihre schönen Programme sonst keiner haben will. Java Programmierer werden ganz sicher keine Python Bibliothek in ihr Projekt einbinden, C Programmierer auch nicht. Mit etwas Glück kann man die Library im Pypi Repository unterbringen, aber das wars dann auch schon. Es ist keineswegs Zufall dass es keine großen namenhafte Python Projekte gibt, mit mehr als 10k LoC. Wie gesagt, rein technisch geht das ausgezeichnet, nur leider ist die Welt außerhalb von Python sehr viel kritischer in solchen Dingen.

Ich bin mir nicht sicher, ob Guido van Rossum der Welt einen Gefallen getan hat, als er die Sprache erfunden hat. Auf den ersten Blick hat Python viele Vorteile. So richtet es sich nicht explizit an Informatiker sondern an Wissenschaftler aus den Bereichen Physik, Linguistik und Geschichtswissenschaften. Ferner ist als interpretierte Sprache mit kurzen Edit-Compile-Run Zyklen konzipiert wodurch man in kurzer Zeit viel Code schreiben kann. Genau genommen ist Python also in eine Lücke vorgestoßen wofür es davor noch keine Sprache gab. Aber kann es wirklich das Ziel sein, zu den gefühlten 500 Programmiersprachen immer weitere hinzuzufügen um darüber die Spaltung der Entwickler voranzutreiben? Reicht es noch nicht, wenn Java und C# Programmierer gegeneinander arbeiten? Braucht man neben PHP, go und Perl noch weitere Sprachen? Python hat sogar das seltene Kunststück fertiggebracht zu sich selber inkompitbel zu sein. Bekanntlich laufen Python3 Programme nicht mehr auf einem Python2 Interpreter. Und das Pypy Projekt ist zwar ein JIT Compiler kann aber nicht alle Bibliotheken aus cpython verarbeiten. Irgendwie ist Python eine ganz eigene Welt die im universitären Umfeld prächtig gedeiht und die dazu führt, dass Leute ihre Zeit verschwenden. Anders kann man es nicht ausdrücken, wenn man Ressourcen in den Aufbau von Python Sourcecode investiert.

BEISPIEL
An einem kleinen Beispiel möchte ich das Thema vertiefen. Früher habe ich schön mit pygame Spiele programmiert. Das geht wunderbar einfach, und mit erstaunlich wenig Sourcecode. Man fängt einfach oben an mit “import pygame”, aktiviert das Fenster, und schon kann man seine erste Box auf den Bildschirm zaubern. Jetzt wo ich nicht pygame nutze, sondern in C++ mit SFML das Spiel realisiere ist es deutlich aufwendiger. Man muss sich durch Manuals auf English wühlen, es gibt für alles mindestens 4 Möglichkeiten und mehr Sourcecode benötigt man auch. Für den Computer macht es keinen Unterschied. In beiden Fällen sieht man eine GUI in der etwas angezeigt wird, und beidesmal mit ruckelfreien 60fps. Der Unterschied liegt in der Community die hinter der Sprache steht. Projekt-1 wendet sich an die Python Community, also an Nicht-Informatiker, während Projekt-2 sich an C++ Programmierer richtet. Die Community unterscheiden sich im Anspruch an sich selbst. C++ Programmieren tönen lautstark dass sie die besten Programmierer der Welt seien und demzufolge haben sie auch den Ehrgeiz die besten Programme des Universums zu schreiben, während es in der Python Community sehr viel entspannter zugeht, in dem Sinne dass man sich gegenseitig versichert Anfänger zu sein und überhaupt sich eher mit mit inhaltlichen Dingen und weniger mit Programmieren beschäftigt. Damals in Python war meine Produktivität immerhin bei stolzen 10 Zeilen Code am Tag, jetzt mit C++ in SFML ist sie abgesunken auf 5 Zeilen täglich. Dadurch verdoppelt sich natürlich die Zeitdauer bis das Projekt fertig ist.