The three most important programming languages

There are three major computer languages out there, which everybody should aware of it: Python, C++ and Forth. Python is a typical entry language. The syntax is very easy to learn, it is possible to use Python for simple scripting but also for object-oriented tasks and often pseudocode is formulated in Python. The disadvantage of Python is, that it can’t used in real software. Absolutely no real software in daily use was programmed in Python. Even for simple amateur games or a simple prime number algorithm, Python is far too slow. Here comes C++ into the game. C++ is the most dominant real programming language. That means it can be used for programming everything. But, for using C++ the programmers must know what Object oriented programming is. That means, he must know how to use Python otherwise he will get lost in C++ universum. The advantage of C++ is, that the language is very fast. It is the fast programming langauage ever invented is the dominant language in game programming.

And here comes Forth into it. Forth is according to the Stackoverflow community the most weird language ever. But it is more powerful than Python and C++. Forth is some kind of better C++. Like C++ it is possible to write anything in Forth, but apart from it, Forth is also an assembly like language. That means it is possible to not only write computerprograms but invent the whole computer hardware from scratch and write your own operating system. I’m in doubt, if Forth will ever conquer the mainstream. The learning curve from C++ to Forth is very huge. People who are experts in Forth are very rare. But it is without any doubt the queen of all programming languages.

Advertisements

Again: git branches vs directories

The problem of using directories over branches is questioned by https://stackoverflow.com/questions/5101270/git-store-branches-in-separate-local-directories The user there also wants to store content in a directory and not in the branch. So what exactly is the difference? At first it is important to know, that people how explaining how git works are not automatically programmers who are using it in reality. Instead their motivation is driven by religious belief in a better software. Let us describe the situation a bit more objective. The first thing is, that a git user doesn’t need branches. The reason is that the command mkdir from the operating system is well suited for creating a folder. That means if a user has a new idea and want to try something out he is using mkdir inside his git repository.

Branches are only important if git users want to work together. For example, if I clone a github repository, that is equal to create a copy of the full git repository including all directory. So I create a branch of it.

Mekes the proposed git workflow sense?

Explaining git is mostly done with explaining branches. The idea is, that separate projects are developed in parallel and at the end merged together to a single file. Will this work in reality? Let us make a short example. There is a RRT solver, which first contains of a simple 2D maze (branch 2dmaze) and a more complex box2D engine (branch box2dgame). In both cases, the RRT algorithm is used for random-sampling the engine. In the case of the maze against a simple game engine, in the case of Box2d against a full blown rigid body game-engine. Developing each branches separate from another is a good idea. But how to merge it at the end? The sourcecode looks very different, and even sophisticated git command line options are not explaining how to combine both projects at the end. The problem is, that obviously merging a project is something different from using git merges.

Let us be more explicit. git branches are a waste of time. The better idea is to commit only in the master branch and create directory folder for each project. That means, branching is not possible, instead the way to go is to create another folder “rrt-merge” and in this a new project is created from scratch which is hopefully able to combine the knowledge of the previous two one. The git branches are perhaps the most overrated feature. In every tutorial it is explained in depth but in reality it is useful for nothing. The reason has to do with a misconception what git is. Some people are arguing that it is a distributed project management tool, for letting different programmers work together and in parallel. No, that is not the right description. Git is in reality a time based backup tool, like the zip fileformat but has a history. That means it is possible to use git for snapshoting the project folder including all subfolders on a daily basis. It is also possible to go back in time and search fulltext. But using git for merging branches together, or realizing distributed programming with many people is not possible. It is wishful thinking to state, that these features are integrated into the git-binary-file.

The problem is, that combining two project folders into a more general has nothing to do with running a diff program against the textfiles, but it is a knowledge intensive task. In the above example it has to do with the question, how the UML chart look like which is able to integrate a smaller maze-game with a complicated Box2d engine. The resulting sourcecode looks different from the versions before, it can’t be programmed on the fly.

Moving git to the next level

A milestone in the history of the git-software-development tool is the Tech-talk of Microsoft about adopting git in their own company. “Git Is Taking Over Microsoft, Saeed Noursalehi – Git Merge 2016”, https://www.youtube.com/watch?v=rKgBV4yfK3g It is more than only randomness that at the same time, Microsoft adopted git, they also implemented the Linux subsystem into their Windows sourcecode, so that git acts as a Trojan horse for taking over the Redmond company by OpenSource software.

But i want to direct the focus on something inside the git-migration. Inside the above cited talk Microsoft explains what the concrete problems are. A team has around 500 software-repositories which are all managed with git, and a new developer in the company has to find out which repositories of them are important for a task. And indeed this is a problem from real-life and not only a Microsoft specific problem. The bad answer is, that git itself has no answer to it. Because git only provides git-related features like “git push” or “git commit”. From a technical point of view, the developer can use git for searching full text in all the 500 repositories, but this makes his job not easier.

The problem has to do with information knowledge. The knowledge is stored inside the source-code repositories and the problem is, that the single developer needs access to the knowledge. Solving the task with software is not possible, instead the better way is structuring the knowledge with classical papers. That means, the problem of Microsoft is a lack of documentation. The number of PDF papers in which the developers are explaining what their code is doing is too low. What Microsoft needs is an internal PDF-repository.

The good news is, that git can help to create such a storage. Git can not only be used for tracking c# files, it can also be used for commit changes to LaTeX files. The best-practice method is to document the sourcecode and the projects the engineers are working on in natural language, store the information in PDF format on a server and give the developers a fulltext-search engine for retrieving the information.

Some programmers believe, that access to the sourcecode is enough for others to understand and learn. In the case of Microsoft this is equal to give the developers read/write access to the Microsoft sourcecode. But at the end, it will not work. Suppose the single developers can search in 500 Microsoft internal repositories, will he ever find the needed sourcecode or a helpful comment? Perhaps not. The situation is the same, if someone is searching inside the github repository. At first, it is better than nothing, but the sourcecode alone is not providing knowledge about software programming. The better way of communicating to each other are PDF papers, written in English. They are describing how a software works, and figures are used to make the point clear. If a project or a company has problem with information management, in most cases the reason is a lack of pdf-papers which are describing the internal workflow. Or to be more specific: the costs of creating new pdf papers are to high. Reasons can be:

• culture in the company

• no read/write access to the pdf-repository

• lack of understanding who to write a paper

• no full text search engine available for retrieving existing information

The idea is to use the versioncontrol system git for reducing the costs of creating new papers. Writing a paper which documents the written sourcecode should be as normal as writing the code itself. And it makes even more sense to write a paper in teams. This helps to collection information which was distributed over many persons before. After the paper is written the information is stored in the pdf file and can be read by new developers.

Using git for managing LaTeX documents is not very common right now. In most cases, git is used only for programming projects. The main advantage is the same like using git in software projects: the activities of the users can be tracked. If someone is using git for writing his papers, the “.git” folder can be analyzed by statistics programs. That means, it is possible to say how many words someone has written in a week, and how many commits he has done to a LaTeX file. Writing a paper without git is technical possible, but then the writing process can’t be analyzed. Instead, the pdf-paper is one day ready and no one knows, in which timeperiod it was created.

Picture 1 shows the result of gitstats. The number of added lines is very high, because it was a Lyx project which was tracked.

In Picture 2 the statistics for each filetype is given. 80% of the edits were done inside the .lyx textfile and 20% inside the bibliography (.bib file). The interesting aspect of using git for tracking scientific writing is, that we get detailed statistics for every week. In theory, it is possible to say how much commits were done on a single day in a year for measuring the individual productivity of an author. I would guess this is the most interesting potential which is not used today very often.

The disadvantes of using git for sourcecode management and LaTeX projects has to do with the possible effects on the human workforce. Traditionally, only the blue-collar workers are tracked with a stopwatch to measure their productivity. In contrast, the white collar workers, in which programmers and scientific writers are part of, remaining untracked. The typical programmer today is not carefully measured and the same is true for the typical pdf-author. Both are working under special conditions which gives them the freedom not to be tracked. And this is the reason why git is so powerful. It can change the situation. With git, also the white collar workers (and especially the high-skilled phd students) can be tracked on hourly basis. If someone is committing every 10 minutes his progress into a git repository, the boss can analyze the statistics in detail and gets clear information about what the worker is doing all day long. This explains, why today git is not used very much in LaTeX projects, because most authors are trying to prevent such transparency.

git tutorial

Understanding git is not easy. In the following blogpost a reduced introduction is given into the subject. At first I want to describe the general idea. What git users are doing is constantly create a zip-archive of their project folder with the aim to save previous versions, get a detailed statistic and collaborate in teams. The easiest form of using git is without any branch. Here a small example workflow.

At first we need a newly created project folder. “mkdir project1”. In this folder we are copying existing textfiles and subdirectories “1.txt”, “images/”, “2.txt”. Now we are starting git “git init”. This creates the magic subfolder “.git” which is hidden but can be shown with “ls -lisa”. What the user has to do is, make normal changes in his project. That means to modify the “1.txt” file, and create new files. And every 30 minutes or so he enters:

git add --all && git commit -m "comment"

This will update the git repository and creates the logfile. “–all” means to track every file and subfolder. And this is done on the master branch. Other branches like “release” are not used. It is to complicated for an introduction tutorial. So what will the user get? As I mentioned before, he enters every 30 minute the git commit statement. The result is, that after a week or so, many git entries are visible. This is shown in the screenshot at the beginning. What the user now can do makes clear, why git is so widespread used. At first, the user can roll back to a previous version. The feature is similar to the Apple Timemachine backup, or a handmade zip archive, but it works for everysnapshot and without creating an archive. The command is simple “git checkout [revision]”. The user can switch back to the current project version with “git checkout master”. The second feature is, that he create detailed statistics with external tools like “gitstats”. This allows him to see how many lines of text were added in the last week and by which person. He get even a list, on which day the project was very active.

Suppose the project is done, who can the user publish his work without creating a release branch? The easiest way of doing so is to create a release directory “mkdir release” And in this folder he copies all the data which he wants to publish. Every change in the folder is also tracked.

Branching is sometimes wrong

The git community is proud of so called branches. Ok, let us make a small example. We are assuming that a branch is similar to a directory but way more powerful. In our master branch which is per default enabled in every git repository we are creating a release-branch. After changing to the branch, the complete project is there, but in a sandbox like environment. So we are deciding to clean up the mess, and let only one file in the project folderr, called main.txt. Because the other files are not needed for the release itself. Then we release the project, that means we are copying the file to an online webserver. But what then? We can switch back to our master branch, in which the normal project is stored. According to the documentation it is time for clean up the mess. So we are merging the master with the release branch. The problem is, that after the merge is successful all the information are lost. That means, our release branch overwrites the master branch and we have no files in the project folder. Taking back the action is not possible, and we have the negative feeling, that we didn’t understand the branch concept in git very well.

So my tip for the beginner is, to not use any branches. Instead the best practice method is to commit all the changes in the master branch and for release a project simple create a folder with “mkdir release”. This forces git to work as a simple backup utitility, which creates every day a snapshot of the project, but not engages to much which branches and other complicated stuff.

How to bring Aimbots forward

In classical Aimbot forums, the AutoIt language is used routinely for creating so called Aimbots. The reason is, that AutoIt is an interpretive language with an integrated pixelsearch feature, which makes it easy for accessing an external program. But there are also tutorials available which have C# as the programming language, and perhaps C# is better suited if the program gets complexer. At first we should define what exactly an Aimbot is.

It would call it a C++ program which is using pixelsearch as input and sends keystrokes as output for interacting with existing games. The important things about Aimbot is, that they are beginner friendly. In contrast to theoretical AI and also in contrast to classical robotics competions like Micromouse or Robocup, an Aimbot can be created really by amateurs. That are people who have apart from one week experience with programming no further technical skills. And the setting in which Aimbots are created usually is very relaxed which results in a creative atmosphere.

But let us go into problems. At first, it is difficult in the Linux operating system to realize a pixelsearch like function. It has something to do with the Wayland interface and foremost with the small number of people who are using Linux for gaming, so the problem of a missing pixelsearch feature is not escalating in support forums. In contrast under the MS-Windows ooperating system there are many more users who have the need for using a pixelsearch like function, either in AutoIt, in C# or in C++. But without a pixelsearch feature it is not possible to access the rawdata of an existing game. So the user is in the position to create his own game from scratch, which increases the difficulty without doubt. For example the Mario AI game was programmed first by the community only for the reason to program after it an Aimbot. But using a pixelsearch like interface will make the workflow more flexible because the user can decide by his own which game he wants to play with an AI. User1 likes Tetris, user2 prefers Sokoban, user3 a shot’em’up and so forth.

In my opinion a pixelsearch feature plus the keystroke sending is the minimal requirement for beeing part of the Aimbot community. After it, we can talk in detail if C#, C++ or Autoit is the better programming language. So the first thing to get Aimbot programming more popular is to realize a pixelsearch interface for Linux.

Increasing the productivity of programming languages

spelling

A look into computerhistory shows us, that today programming paradigma are not totally different from what was done 40 years before. But one thing has changed dramatically, it is called disintegration and means, that programming languages, operating systems, libraries and companies are working against each other. In the 1970s, the operating system was equal to the programming language. That means, Pascal was both, and IDE, bytecode and a language. Todays developers have invented for each purpose a special tool. That means, we have different programming languages like C++, Java, Lisp and on the other hand we have different operating system. So it is possible to combine a certain language with a certain OS and use a different library.

I want to give a short example. The new C++20 standard is currently under planning. C++20 is equal to major improvements in the language. The funny thing is, that most programmers are not aware of the changes, because they need no better C++. But that is not a problem which has effects to the development of C++20, because the language itself needs improvement. The new thing is, that every part is developed independently. That means, after implementing the C++20 standard, it will make problems with the operating system, libraries written before and programmers who use it. In the 1970s this would result into failure of the project, nowadays on subject in computing industry is driven forward even it will results into negative effects somewhere else.

The reason why the disintegration is possible is simply: better communication over the internet. If we are reading todays online forum, many users are talking about the effect, and this will guide them to bypassing the situation. What does that means? It means, that the community consists of units which are working against each other in a battlefield like environment. Or to say it more colloquial: the C++20 standard was only developed with the goal, to make the life for programmers harder.

But how exactly was such a integrative system possible? Why is the development spread out over many instances? The answer is, that “working together” brings no profit. In theory, it would be possible that the C++ community arranges the changes with other stakeholders, for example with companies like Microsoft, with operating system developers like Red Hat or even ask the programmers if they really need the new feature. But in reality, the C++20 standard is established without asking anybody for comment. It is a one-man-show which follows its own rules. In theory, it would be possible that somebody from outside criticize the development, because “Concepts” (which is part of C++20) is not needed by no-one. But this statement isn’t recognized. The C++ team will ignore it.

Working against each other

The usual assumption is, that teamwork is important because this multiply the strength, right? The problem with teamwork is, that at first a team is needed, which is an organisation with a shared identity by it’s member. What the common attitude of an operating system programmer, and the creator of a computer language? Right, there is no overlap, they have different goals in their mind. The first one is interested in an easy to use system kernel, while the second one is interested in a clean language definition. The better approach is, to let both teams working against each other. That means, the new invented programming language make system development impossible, while the new operating system is using the language in the wrong way. Instead of promoting to trust each other, the dominant feeling is paranoia, what the opposite group is doing next. The demand for communication increases and flame-wars will become normal. A flame-war is no longer a factual discussion form, but escalating the conflict on a personal level. That is the overall direction, what has changed since the 1970s. In old-school computing everything worked together on the same project, while todays programmers have unlearned cooperation.

The new talent is called gamification. That means, to see the developing of a project as an individual task to gaining points. And increasing the count is only possible, if somebody other loose them. If the C++ language team has done all fine, the Operating system division will hate them.