High level programming language

 

The pygame library is for sure a high level programming language. It would be interesting to know the reason why this is the case. The working thesis is, that it has to do with amount of commands which are provided.

The exact number can be determined with the official API description.[1] The amount of all commands in the pygame 2.0 library is 754 which is a lot. Every command has parameters and is described in the API. Creating such a library and writing the documentation takes a lot of time. In addition it is important to know that most python applications will need more than a single library. They include other libraries which have the same and more complexity.

From a user's perspective a complex large library is easier to use than a simple one. A game library which has fewer than 20 commands is much harder to use, because the user is asked to create many commands from scratch. In contrast, the pygame library provides many useful tools out of the box. There is a single command to initialize the graphics screen, another commands draws a line, and a third command create a timed loop with 60fps.

Let us compare pygame with low level programming like Assembly and very important with Forth. The assembly language has a low amount of commands. Forth has reduced the instruction set further. Most forth implementation have no additional libraries but the amount of commands is reduced to fewer than 50. The user is asked to write with only 50 commands useful programs. Technically this is possible, but it is a demanding task.

We can only guess how many commands are provided by a python environment. Perhaps the amount of all commands is 10k or even more. What we can say for sure is, that all the libraries combined have a huge documentation with thousands of high level commands. This ecosystem makes it easy to create high level applications like games and GUI applications in a few lines of code.

Other high level languages like Java and C# are working with the same paradigm. The amount of commands in the typical Java library is endless. Some programmers have written these APIs in the past. They have done so because it simplifies the programming. Today's scripting languages are the most high level languages available The disadvantage is, that such an ecosystem can't be created easily. It is possible for a single programmer to write a Forth environment but writing a python ecosystem which includes some important libraries is impossible for a single programmer.

In some older tutorials from 1980s it was assumed that Forth is a low level and a high level language at the same time. This assumption is wrong. Forth is a low level language and nothing else. In Forth there is no large library available and also a standard amount of commands is missing. The typical forth interpreter provides very few commands. This is an obvious sign, that it is located on the low level layer. The factor language which is forth dialect, is working with a different objector. Factor has similar to Python a large library with predefined commands which makes it easy to write applications. But, Factor is not a typical Forth implementation because it is not minimalist. The question is not about sequence of commands which are stack based but the more serous question is about the size of the library with predefined commands.

[1] https://devdocs.io/pygame/

Pros and cons of debian linux

 

Debian is a well known but seldom used Linux distributions. Especially newbies in the Open Source community are preferring alternative Linux distributions like Fedora, Arch Linux, Ubuntu and Suse. To understand the mismatch better why Debian on the one side is great but is seldom used it makes sense to analyze the distribution from a beginner's perspective.

Suppose a computer user has logged into a preinstalled Debian in a computer room at the university or has installed the system in a virtual environment on his home PC. After entering the command “uname -a” the user will notice that not the recent kernel version from kernel.org was installed but only a longterm kernel. The same picture is there after testing out the python3 interpreter. It will shown in the interactive mode that the installed python version is around 1.5 years old and was compiled with the previous GCC Compiler. Even if the user won't need the current software version the impression is, that the system is outdated. In the next step the user will try to playback perhaps a video in the H.265 format which is running fine in Windows and MacOS but in Linux there are some codecs missing.

In summary, the user will come to the conclusion that the distribution is working with outdated software and in addition is not very powerful. So the chance is high that the newbie will deinstall the system and prefer a different operating system. Which is maybe a Linux system but in a different distribution.

It is hard or even impossible to explain to the user why most of software is outdated and at the same time it is the most recent version available. Even if the explanation contains a detail description about the advantage of stable release management and the hint that that the software is working bugfree, the newbie won't agree to the Debian advocacy.

But let us try to take the challenge more serious and explain in a single version why Debian is using outdated software. Suppose, the software installed on the harddrive is never older than 1 week. The logicial consequence is, that the system maintainer has to run a complete reinstall of the software every week. That means, every sunday evening the local adminstrator has to run the update script which will download around 3 GB of new and fresh sourcecode from the internet, is processing all the updates for around 3k packages and then a short function test is made. The overall procedure will take even with a quadcore cpu and a fst internet connection many hours and requires manual intervention. Nobody likes to do so. And that is the reason why Debian is updated only every 2 years in such a way.

It is not possible to deliver an to date Linux distribution which doesn't need to be updated. It is a contradiction and only one objective can be realized. Either somebody can simply work with the system or the user has to manual update the system every week which includes the chance of a reboot failure.

The advantage of Debian over other Linux distribution is especially visible in larger computer rooms which have 30 and more workstations and it obvious for a server system. In both cases the admin of the computer is not motivated to run every week an entire update which includes to download gigabyte of .iso files from the internet and install the packages over the older versions. Such a complicated update should be run only once a year if nobody is using the machines.

Forth as a low level programming language

 

The world outside of the Forth community divides programming languages into low level and high level languages. Assembly language represents low level environments because it is executed on bare metal while C is a well known example for a high level language because it is possible to write programs without knowing the underlying hardware. Even if Forth has some elements of high level languages it is an example for low level programming.

There are some reasons for the claim available that Forth belongs to the CPU First one is, that Forth was never standardized. It is not possible to run the same Forth source code on different machines. A jonesforth interpreter works different from Colorforth, and VFXforth has different keywords than gforth. The second cause why Forth belongs to bare metal programming is, that the most efficient Forth interpreter are realized in hardware. It was demonstrated in the past that Forth can be executed direct on a FPGA chip or on a custom cpu These cpu are realized with low amount of transistors. And the amount of possible Forth commands is low (fewer than 100).

The combination of low amount of Forth commands, the ability to run Forth direct on hardware and the missing standardization are typical sign to classify Forth as a low level bare metal language. To verify the thesis let us analyze some high level programming language.

The python programming language provides a huge amount of commands. If the user includes external libraries like pygame and Qt he gets access to 10000 and more different commands which are known as the api. These commands are realized in huge amount of codelines and are documented in long reference manuals. In addition the API is standardized. That means the user can execute the same program on different hardware and software environment. The assumption is that such a working mode is preferred by the user. That means, it is an advantage if python provides 10k different API calls because it simplifies the programming.

In contrast, Forth doesn't provide these features. Most Forth interpreters are provide to provide only a minimal set of commands. There is some sort challenge how to write a forth interpreter which needs less lines of code and which provide less commands.

Or let me explain it the other way around. It doesn't make sense to name a programming language a high level one, if it provides fewer than 100 commands. High level languages have always a standardized high amount of commands. This allows the programmer to formulate the source code in a more abstract way. While assembly like languages provide very few commands. It is possible to give an overview over an assembly language in a little paper which has 10 pages. In most cases, the commands are used to store values in registers, fetch values and add values.

Are robots tools?

 

Short answer: no they don't. The long answer is, that the interaction between robots and humans works with social roles. For example, if the robot was put into the role of a teacher and the human is in the role of a student, then the robot defines the rules but not the other way around. So the question is, why should humans accept that robots are judging about their performance? Because it makes a lot of fun to play such games.

If the robot is in the role of teacher, the human plays a serious game. The robot is some sort of game engine which judges about the situation. Similar to a games in general this interaction makes sense for humans.

The open question is, if robots can be used for something different than playing the teacher or the quiz master. Unfortunately, they can't. This would be equal to put the robot into the role of tool and use it for further tasks for example to increase the productivity. This interaction is not how robots are working. They are too expensive and to complicated to understand to use them in this way.

The main difference between a CNC machine and a cobot is, that the CNC machine can be used easily as a tool. The CNC machine fulfills a task and it is doing so very efficient. In contrast, cobots never fulfill tasks but they are creating spaces in which humans can learn something. A common interaction with a robot is that the human has to solve a programming challenge. For example, the task is that the robot has to follow a line on the ground or grasp an object. It is important to know that not the robot is doing this task, but the challenge is that the human has to program something. And if he can't, he has to search for additional information.

A good question to determine if an object is tool or the quiz master is to analyze who is fulfilling the task. A tool works by itself and the answer of the tool profits from it. This definition is correct for a hammer, cars and even the assembly line. In contrast, a teacher is an instance which is requesting work. For example a computer science teacher asks the students to write an essay or they should program an algorithm.

What robots can do perfectly is to fit in the role of a teacher. Nearly all the existing robots on the market are asking the humans to program something, to learn something about robots and show what they have learned. An endless amount of robot competitions and robot games are demonstrating this interaction.

What robots can't do is to act as a tool. This sounds a bit paradox, because the term robot is translated with worker or tool. But there is a mismatch what is described in the fictional literature and what is available in the real word. In the real world it is hard to own a robot in a sense, that the machine is doing something useful. A closer look into robotics projects like the micromouse challenge, the robocup challenge and even self driving cars will show that in all these cases the robot is useless.

The robot productivity paradox

 

There is some sort of mystery available in the history of industrial automation. It has to do with the contradiction between technological advancement and marketing this technology to the public. First thing to know is, that robotics can be realized with today's technology. It is possible to build kitchen robots, delivery robots and even humanoid robots. The engineers have mastered the problem of biped walking, object grasping and pathplanning. At the same time they haven't build anything and this contradiction should be explained in detail.

To explore the difference between technological capabilities and the ability to sell robots on the market further we have to focus only on commercial robots. That are robots which are sold by customers to customers. There are a lot of example available from the last 50 years in which commercial robots were presented. The interesting situation is, that not a single robot was a success. The prediction is, that because of hard to understand facts it won't be able in the future to sell more advanced robots.

Perhaps it makes sense to imagine how a newly started robot whould looks from a technical and from a marketing perspective. First thing to do is to build and program a robot. A typical entry level example would be a delivery robot. The robot is able to pick up objects and deliever them to a location somewhere in the city. Writing the software which controls the robot autonomously is not very complicated. It is some sort of advanced path planning algorithm which is used to control ingame AI in a racing simulator. It is possible to show that the robot's program is working correctly. This is equal to recognize, that the technological development process was succeeded.

Now let us take a look into the marketing perspective. The question is how to advertise such a robot so that customers will pay real money for the device. And here is the bottleneck located. Because humans have no need for a delivery robot. And if the companies who has developed the robot will explain in detail how it works and what to do with the machine, the customers gets irritated even more.

From an outside perspective, a common argument to explain the mismatch is the assumption that the mainstream customer doesn't understands robotics or he is not interesting in technology at all.But this is not true, the customers are understanding the details very well and they are want to make advanced automation a success. Nevertheless they won't buy a robot, especially if the machine is able to do real life tasks.

Let us go into the details. Robots are mostly advertised as a productivity machine. The idea is, that a robot can do the task of a human worker but much faster and cheaper. The sad reality is that they are struggling exactly in this context. Not because of the robot itself, but because of the description of the robot.

Now let us imagine the same robot is marketed with a different objective. This time, the robot is sold to university and the promis is, that the robot will produce large amount of costs, and it will require 10 computer science and 100 phd holders to understand the system. This time the robot can be sold easily to the customer. Again, it is the same delivery robot which is working with the same hardware and software. The only difference is, that this time the marketing claim is different what the purpose of this robot is.

There is a demand for overpriced useless robots which will reduce the productivity. These robots can be sold to space agencies like the NASA or to a research center at the university. it will need millions of US$ to buy such a robot and it will require hundred of manyears to program these machines and write papers about it. The interesting situation is, that such an interaction works very well because the advertised product and the delivered technology is the same.

The only problem is available is robots are sold as cost saving productivity devices which is able to replace human workers. Such a promise can't be fulfilled by today's robots. No matter if it is a biped robot, a self driving car or a household robot. None of these device can operate in this mode. Robots are always research projects which are producing cost and have a demand for highly qualified researchers. A technical university is the best source which can deliver money and highly experienced computer science students.

It is possible to verify this theory by a short look into the reality. The amount of robots which are utilized to reduce labor costs or automate the workflow in a factory is exactly zero. Not a single company nor a household owns such robots. At the same time, robots have become a widely accepted technoogy within research universities. Nearly 100% of the universities have at least one biped in the laboratory and for educational purposes. The prediction is, that this trend is stable. That means in 20 years from now, the amount of robots on the road and at home remains at the same level which is 0.0 while at the same time, the amount of robots especially highly expensive one in universities will grow further.

To understand this paradox we have to ask some basic question. What is the reason why a computer science laboratory at the university has a need for starting a robot project? Because it helps to explore new algorithm, teach the students how to program robots and perhaps it helps the university to promote itself as a technology friendly institution. That means, a modern biped robot in a university classroom fits very well together. On the other hand, the same robot model won't fit to the needs of households or companies. Both stakeholder have a demand for productivity increasing machines and they want to save the costs. Also they have no interests in programming the device but they want to buy something which works out of the box. This is not the case for a robot especially not for a recent robot which is working with neural networks.

It seems that from an abstract point, a robot is a machine which is consuming a lot of money and lot of intellectual capital and at the same time it doesn't increase the productivity and it doesn't help to reduce the costs.

There is no explicit rule available that a self driving car can only be controlled by computer science students. It is possible that non technicans buy such a car to have fun with it and reduce the amount of accidents. But in the reality, such a use case is not there. That means, self driving cars are only available for computer science students but never for non technicans. The reason is, that there is no sense to use a self driving car for something important. Such a machine works only in the university context.

Perhaps it makes sense to describe the term working in detail. A working robot isn't defined by it's hardware nor its software but it has to do with social roles. A robot makes a lot of sense in an academic paper, A roughly estimation comes to the conclusion that there are at least 100k papers written in the past 50 years about all sort of robots. And these papers were created always in an academic context. So it seems, that the combination of a robot plus a university context makes a lot of sense. At the same there is not a single case available in which robots were used in a non academic context for example in a house hold or by a company to increase the productivity. So it seems, that such interaction doesn't make sense.

In simpler words it is possible to say, that robots are everywhere except outside the university campus. On the university robots are used in a simulator, for testing out real hardware, for building self driving cars, implement qlearning algorithm and even for programming vision systems for drones. It is possible to select randomly a technical university somewhere in the world, and the chance is high that this university has not a single and not 10 different robots but more than a dozens of them which are used frequently in projects and documented in papers.

On the other hand, the amount of robots outside of university projects is little and even zero. It seems, that the technological progress in the last 20 years doesn't help to introduce robots in the real world but has increased the productivity paradox. There are no companies available which are selling robots and there are no households available which have a demand for these machines. 100% of the house hold kitchens and all the public roads are working fine without any robots. And the chance is high that this situation will remain the same for the next 20 years. With the robot itself every thing is working fine. The only problem is the marketing effort to sell robots for practical applications. Robots are useless as self driving car, as delivery drones, they have no advantage for self driving ships or as security devices in a shopping mall. Robots are useless in a restaurant and they no advantage in a kitchen. Robots have failed at the assembly line fore example in the automotive industry and robots are a poor choice in a hospital. Basically spoken, robots are useless in every context except for educational purposes. The only sense making application for a robot is if the device is sold to a university.

The funny thing is, that most computer science students are empathizing that they have developed practical robots which have greatly improved over the years. What these science students are never telling to the world is, that the robots won't leave the university lab. All the biped, grasping and flying robots can't be utilized for practical applications. And if someone is trying to do so the project will fail.

Let us try to understand the paradox from a positive perspective. Instead of asking what robots can't do let us focus on successful robot project. A simple game might help to understand the reality. The works in a way, that we are imagine a city or country randomly and then ask google if the university in this location has at least one robot project. First trial is the city “london”. After entering the search term “university london robot”, not one and not ten hits are shown but hundreds of them. all the colleges, university and technical courses in London have robot projects. They have biped robots, UAV drones and pick&place robots. The students can learn how to program these robots in java, in C and even Prolog. Next trial is to imagine the city of Los angeles. The situation is nearly the same. Lots of technical university are explaining what robots are and how to program them. The user can decide to read the website, the paper or even watch videos from one of the universities. That means, in los angeles, there are robots everywhere.

On the other hand, it is very hard to find robots not connected to a university. For example in a hospital or in a logistics company. It seems, that in the same city the robotics technology is well researched at the university but the same technology is never deployed to the business world. This is not a coincidence or the result of single decision making process but it is some sort of unwritten rule which is valid for the last 50 years. The rule basically says that robots are great at the university but are doesn't produce sense for the world outside the ivory tower.

Sure, many attempts were made to deploy robots in real world companies or private households. but mostly the project was terminated after a while and it was always a failure. The reason is, that universities and normal companies have a different use case. A normal companies is interested in increasing their productivity, lower their internal complexity and increasing their profit. But a robot can't fulfill these requirement. What robots are doing is to produce costs, increase the complexity and they have a demand for computer programmers. So it seems, that robots aren't producing something but they have a demand for money and knowledge.

Educational robots

In the first path of this essay it was explained why robots are a poor choice for automating the retail industry or to drive on public roads. What was missing is a positive description in which domain a robot is useful. Some examples for educational robots are:

- the lynxmotion robot arm

- arduino mobile robots

- Legomindstorms NXT line following robot

- nao humanoid robot

- Willow garage PR2 kitchen robot

- robocup robots

- self driving car robots on a floor

- pick&place robot demonstrator to teach the PDDL language

- Duckiebots kit (self driving car on a floor)

- and so on

These robots are sold for a different price range which is starting at 200 US$ and has its upper limit at 10k US$. For example the NAO robot or the PR2 are very expensive one which is used in a university context. The interesting situation is, that all these robots can be recommended. They are used frequently in the past and lots of papers were written about ongoing projects. So it seems, that the mentioned robots are fulfilling the needs of students and teachers as well.

In addition it is possible to recommend some robot simulators which are not working with real hardware but are computer programs on a desktop PC. A typical example would be a pong game which is enhanced by an artificial intelligence.

The surprising fact is, that even the robots are highly successful they can't leave the university context. They are research only robots. Sure it is possible to demonstrate practical applications for example a self driving car or a pick&place robot, but these demonstrations are not useful for a company or in a houosehold context.

Let me give an example. Suppose a user is buying the PR2 robot with the idea to use the device in the kitchen at home. Such a usecase won't work. What the user can do is to create an academic robot project at home and write a paper about it. And this interaction is the reality for all the mentioned robots. It is simply not possible to modify a research robot so that it will fulfill a real life task.

Or let me explain it more precise. Al the mentioned robots like PR2, lynxmotion arm or the Nao model are a poor choice if the goal is to automate something or reduce the costs in a factory. The robots were not build for this purpose. The working thesis is, that no robot in the world can be used for this purpose. Even if the robot is constructed very robust and will need high amount of voltage it is useless in a factory or at home.

The insight is not completely new. In the 1908s some robot projects were started in the industrial context. The idea was to automate the production of a car factory or to increase the productivity in a hospital by introducing robots. All these projects have failed. And the chance is high that with modern technology and with more effort the project will fail again.

On the other hand it is surprisingly easy to initiate an educational robot project. For example to build a simple line following robot. Even if the robot has smaller bugs, it is possible to write a paper about it and it is for sure a real educational project. In a short sentence it makes sense to reduce the amount of robot projects in factories and increase the amount of robots in universities. Such a priority will make sense for all the participants.

A good example for a successful educational robot is perhaps the micromouse challenge. Micromouse is one of the oldest projects. It is repeated every year not by a single universities but by many of them worldwide. The amount of publications about the subject is very high so it seems, that the competition is a success.

Perhaps it makes sense to give a precise outlook into the future. Some new robot projects were started by companies all over the world. There were projects started about building harvesting robots in agriculture, self driving cars on public roads, pick&place for logistics applications and of course drone robots for delivering packages faster in the city. All these projects have failed already, or they will fail in the future. The reason is, that in all the cases the goal is to use a robot to automate something, reduce the costs and increase the productivity. It was explained already, that these goals can be fulfilled. it is correct that some engineers are promising that robots can be used for this applications but this is not correct.

The term educational robot was used many times. But what is it exactly? An educational robot is a very expensive device which costs 500 US$ and more. It is doing nothing but the machine will need electricity and somebody who can program it. And if the user is doing so, he can learn what Artificial Intelligence is about. Similar to a toy, an educational robot has no value and it can't improve something but it is the opposite. It is used always in an educational context for example to teach programming and control theory. A typical project which can be realized with an educational robot is, that the students are forming a group and have to program a software for the robot. Such a project will need 6 months and then it gets presented in a paper and a talk.

The interesting situation is most or even all these projects and robots are successful. That means, if the students have fulfilled a project in the last semester they want to repeat it with a slightly different challenge.

Some reasons why the Commodore 64 has felt out of fashion

 

In the 1980s the Commodore 64 was the most sold home computer. It wasn't sold 1 million times or 5 million times but more than 15 million machines were produced by the Commodore company. The C64 was an affordable computer, and many games were created first for this machine. It has revolutionized a decade and even today, the C64 stands for the personal computer in general.

To get a better understanding why the machine has felt out of fashion we have to describe the context in which the C64 was published. The development was driven by technically possibilities. At the beginning of the 1980, the microchip was available namely Intel based CPUs and of course the 6510 CPU from MOS technology. Also it was the first time, that low cost DRAM chips were produced in mass amount, so it was from an engineering perspective logical consequence to combine these ingredients into a single product. The C64 was a basically a combination of 64 kb RAM, a cheap 8bit CPU and external devices like printerss and floppy drives.

After the hardware was available it was from a programming perspective also a logical idea to create for this machine lots of applications and of course games. It was a self reinforcing circle. The huge amount of sold C64 made the computer interesting for games publishing houses and the huge of games, made the product interesting for more consumers to buy the hardware.

Even if the situation was amazing there were some cons available. First problem with the 6510 CPU is, that it has only a low amount of registers. This makes it hard to program the CPU with high level programming languages especially C. The only programming language which runs fast on the 8bit CPU is Assembly language and Forth. The problem with Assembly language is, that it is hard to write longer programs which exceed 50 kb and more. Larger applications which are written in the C language have a size of 500 kb and more. The C64 CPU and the small amount of RAM prevents such software can be executed.

Another problem with the device was, that it was controlled by a single company. Commodore has invented build the CPU, the specification, the ROM chips and it was impossible for third person companies to built their own C64 clone.

And perhaps this explain why the IBM PC has become a success. First thing was, that third party companies were allowed to create the hardware and secondly, the CPU wasn't fixed but different sort of CPU with many registers were used in these machines. This combination allows C programmers to create more complex applications which has resulted intodays bloatware software which can be created easily from scratch.

Hardware oriented programming

For today's programmers it is some sort of mystery how exactly software was created for the Commodore 64. First problem was that the amount of RAM was low, and secondly the programmers in the 1980s were thinking differently from today's software engineers. The perspective of the 1980s can be summarized with a CPU oriented approach. The idea was, that it is hard to built and maintain the hardware of a computer. The most important part is the CPU, the RAM chip and the cycles which are scheduled on the main board. That means in each second the C64 was running with 1 million cycles and during each cycle the next assembly instruction is executed.

The only possible cause of errors – at least in the understanding of the 1980s engineers – was that something with the hardware is wrong. For example, that one of the transistors in the CPU has a malfunction or that something with the electric current on the mainboard is wrong. The consequence is that the engineer has to open the machine, and search for the error with a measurement instrument. In contrast, software was seen as not important or in the worst case, the software was seen as an error. For example bad written program will slow down the cpu or will waste the RAM of the computer.

The main purpose of the 1980s programmers on the Commodore 64 was to write efficient software in a sense that it will occupy only little amount of RAM and use a small amount of assembly instructions. The interesting situation is, that this hardware oriented habit isn't the only one which is available but from today's perspective it is something which has slowed down the development.

Perhaps it makes sense to describe the opposite perspective towards the same problem. In a software oriented perspective, the computer hardware is perceived as something which is there and which has unlimited amount of resources. For example a computer has 3 million pixels on the screen, and 2 GB of RAM and now the question is how to program the computer so that it will do something useful. A typical challenge is to program an object oriented programming language, a graphical user interface or to create a large database applications. What the post-C64 programmers doesn't like to do is to understand the hardware. They simply doesn't care about the CPU nor the transistors in the CPU.

The interesting situation is, that both perspective are working the opposite. It is possible to focus either on the hardware or on the software but never fulfill both requirements together. In the 1980s the focus was only on the hardware because at this time computer hardware was the bottleneck. Software defined requirements for example a graphical user interface with lots of colors were ignored in this area. It was described as not needed and in the worst case, a GUI was seen as something which will slowdown the computer.

Programming the Atari 8bit home computer

 

The most dominant computer in the 1980s was the commodore 64. Until the year 1985 the sales for the IBM PC and the C64 were the same. But there was a smaller alternative available which was the Atari 600XL. The Atari 8bit computer was equipped with only 16kb of RAM and was sold for a lower price than the C64.

The question left open is how to program such a device. A look into magazines and books from the 1980s will show that two dominant programming languages were used: BASIC And the assembly language. For today's programmer it looks a bit unusual but in the 1980s most software was created in Assembly.

So what is Assembly language? It is a machine oriented programming style. The programmer has to know the details of a certain CPU, a certain memory layout and all the onboard chips. Assembly language is written from a hardware perspective. The underlying idea is, that the dominant problem of a computer is to built the machine with RAM, keyboard and CPU and then a short program demo is coded in the assembly language. For this reason assembly works great.

The reason why today's programmers have lost their interest in the assembly language is because they are not writing short demo programs in 1 kb anymore. What today's programmers are trying to archive is to create larger projects which have 100 kb and more in sourcecode. Such programs can't be written on 8bit homecomputers and especially they can't be created in assembly language. It would take years until a team of programmers has created such a program.

A seldom noticed side development for the Atari 8bit computer was the existing of so called C compilers like Deep blue c and tiny c. A program written in Deep blue c has much in common with a modern program written for Windows or linux. The idea of C is that the programmer is using a library of graphic routines and that a single command is very powerful. For example, the c language allows to open a file and write some characters into that file in under 10 lines of code. Such a feature would need much more lines of code in the assembly language.

The C language and the Pascal language have much in common. They are both academic programming language because they are using a high abstraction level. The underlying hardware gets ignored and the programming language itself stands in the focus. Instead of focusing on a certain CPU type, the programmer is asked to use for loops and existing programming libraries. Also he can use sub functions and variables.

Why Forth is better than Python

 

There is some sort of ongoing debate available which of the programming languages is more compact and which runs more efficient. Of course, the winner is Forth because this stack based language is the preferred choice of elite programmers. It needs only a small amount of RAM and can be executed an any computer including the Commodore 64.

To get a better understanding why exactly ANSI Forth is more than ready for creating large projects including video games, we have to compare the sourcecode for the game of Tetris. Both projects were created by different programmers in the past and perhaps they doesn't aware of each other.

• https://github.com/letoh/CommonForth/blob/master/TETRIS.4TH
• https://github.com/nickwritessomecode/tetris_in_115_lines/blob/main/main.py

The first one was written in a Forth dialect and compiles out of the box under Linux and Windows as well. It needs only 384 lines of code and the bricks patterns were encoded in a very elegant way. In addition, the source code was factored well in subroutines so that the overall program is easy to understand.

In contrast, the same game of Tetris which was implemented in the Python language needs around 134 lines of code. The code is hard to understand and most operating systems aren't able to run the code because it was written for a certain python version which includes unknown libraries likes tkinter. The programmer has created a mess of methods which are distributed over classes and stand alone routines and it is hard to maintain the code.

Everybody is encouraged to compare the Python and the Forth language by itself. So there is no need to follow my judgment.