The SE.AI website https://ai.stackexchange.com/ is the dominant AI related online forum in the internet. It contains of 6k questions and is part of the larger Stack exchange network. Since a while major changes are taking place in the website. The situation in the past was, that the moderator played a minor role. He didn't posted many comments nor answers, but his objective was administrative nature. He was some kind of technical administrator but wasn't involved in running the website.
Since the year 2019 the situation has changed drastically. The new agenda in SE.AI is, that the moderator is the top rated user in the forum. That means, the current moderator has posted the most answers and has earned the most reputation points. That means, the moderator knows most about Artificial Intelligence and at the same time he is solving conflicts in the community.
Before we can judge about this development it make sense to describe this management style from an abstract point of view. It's equal to elect the best player in a soccer team as the team leader. The result is, that the team leader is the weak point in the overall system. Let us construct an example. Suppose a difficult question is asked in the forum. Only the moderator is able to provide the answer because he has the most experience of all the users. The other users in the community have a weaker position and they not enough skills about Artificial Intelligence. That means, the knowledge and power is distributed unequal.
This management style has some advantages but also disadvantages. The advantage is, that it will minimizes the conflicts in the team. The moderator is accepted because of two reasons, first his social role is strong, and secondly his knowledge is strong. The disadvantage is, that a moderator driven community is vulnerable to a takeover. If the single point of failure makes a mistake the entire group becomes in trouble. The second problem is, that the stress level for the moderator is higher. To defend his strong position he has to create the most postings and has to know everything. The danger is, that the moderator isn't able to do on the long term.
In the management theory there are two different principles discussed: top down moderation and bottom up moderation. Top down moderation is available in SE.AI. It's the classical form of group organization. The group has a strong internal cohesion but fails to adapt to the environment. The team is fixed, new members aren't welcome the moderator is not allowed to leave the group.
It's a bit difficult to predict the future development of SE.AI. One option is, that the moderator is able to handle the disadvantages of top down management style and remains in a active position for the next 10 years. The second option is, that the group isn't able to adapt to future needs. For example, that a request from the outside isn't answered correct. Basically spoken, SE.AI is doing an experiment to investigate if top down leadership works in reality.
April 01, 2020
March 24, 2020
Freezing an academic paper
With the upraising of the Open Access movement it was discussed heavily in the literature what an academic journal is and what not. The most widely accepted definition was created around the term predatory journal. The term was invented to make clear what the difference is between a serious peer reviewed journal and a joke-non peer reviewed journal.
The term predatory journal is widely accepted not because the definition is correct, but it was used in many thousands papers by OpenAccess experts. The term predatory journal is equal to a low cost journal. What predatory publishing has in common is, that the Article processing charge is lower. The typical predatory journal is published online-only, has a reduced fee of 100 US$ per paper and no peer review takes place. This definition was over a long time span an ideal definition to sort the existing journals into two groups. But it fails to explain what a peer review is.
A more elaborated definition divides academic journals into two groups: peer reviewed and non-peer reviewed. The problem is, that it's much harder to define the peer review process. Even Wikipedia has no clear understanding what peer review is about. The working hypothesis is, that peer review is realized with a stable branch in which a frozen upstream gets evaluated.
Freezing the upstream is something which is more complicated than a normal preprint server. A preprint server is location in which authors are submitting their journals. For example Arxiv is a preprint server, but Academia.edu and a github folder too. What all preprint server have in common is that no peer review takes place. Somebody uploads a document and the reader doesn't know if the document has high or a low quality.
A naive assumption is, that a preprint is transformed into a journal by peer reviewing the preprint. That means, somebody sends the manuscript to an expert and the expert gives a quality judgment. This understanding describes only the surface. What is missing is the reason why somebody should peer review a paper. A typical assumption from the past was, that peer review is equal to paid peer review. All the existing academic journals are working with money in the loop. So the assumption is, that a serious journal is equal to a high price journal.
The surprising information is, that this definition describes also not the complete picture. It's possible to combine high quality peer review with a non-commercial journal. The important underlaying process has to do with freezing the upstream. Freezing is a term used by Open Source advocates which are using the git version control system. A freeze is equal to create a branch. On the command line it's done with a simple “git branch stable” This creates a new branch, called stable, and in this branch a snapshot of the master branch is created. A freeze is equal to a point copy of the existing files.
Let me give an example. Suppose an author has uploaded a HTML document to a preprint server. The HTML document contains a 8 page long paper which consists of 20 bibliographic references at the end. Now, somebody else creates a copy of the document. He is freezing the upstream document. The result is, that both documents, original.html and copy.html can be edited independent from each other. The files are located in different folders. The ability to edit a document independently is producing a version conflict. To overcome the version conflict some sort of communication is required.
The communication actions to overcome a version conflict are equal to the peer review process of an academic journal. There are different options in doing so:
- dedicated peer review by external experts
- decision making by the journal editor
- negotiating on a mailing list
- overwrite the version by technical actions because user1 has admin rights, while user2 not
A dedicated peer review is only one option to solve a version conflict in a two branch project. The peer review process isn't at the beginning but it's an answer to a version conflict. The underlying reason is the out of sync behavior of two branches which holds the same file. Branch1 is maintained by the upstream in the preprint server, while branch2 is maintained by the journal in the downstream. Let us investigate what a potential alternative to an upstream freeze is.
Suppose the idea is not to create a stable branch but contribute to the original.html file in a different fashion. The workflow would work in the following way. At first, the author uploads the original.html file to a preprint server. Now a second user likes the article but he would like to add something. He sends an e-mail to the author with an additional paragraph. The original author accepts the modification and a new file is uploaded to the preprint server which is origina-improved.html.
That means, the modification in the file are taken place in a single branch. The original author plus user2 are communicating back and forth and if they have found a shared position, the file gets updated. Conflicts are not possible, because if the original author doesn't accept a modification the user has no option to modify the file.
The major difference between a single branch development model and a two branch model is, that in the two branch model a conflict is the possible. This conflict produces a certain communication style. Perhaps it make sense to provide an example. In the normal single branch model. the original author owns the file and the second user is a subordinate. In a two branch model the second user owns the stable branch and the original author is a subordinate. This kind of flipped social relationship is available for all peer reviewed journals. The original authors sends a manuscript to a peer reviewed serious journal only for the reason to become the subordinate of the journal editor. Not the author but the journal decides if the submission has a high quality. The advantage of this flipped role model is, that the reader of the journal has an advantage from it. The reader trust a journal if not the authors but the journal editor take the decisions.
The term predatory journal is widely accepted not because the definition is correct, but it was used in many thousands papers by OpenAccess experts. The term predatory journal is equal to a low cost journal. What predatory publishing has in common is, that the Article processing charge is lower. The typical predatory journal is published online-only, has a reduced fee of 100 US$ per paper and no peer review takes place. This definition was over a long time span an ideal definition to sort the existing journals into two groups. But it fails to explain what a peer review is.
A more elaborated definition divides academic journals into two groups: peer reviewed and non-peer reviewed. The problem is, that it's much harder to define the peer review process. Even Wikipedia has no clear understanding what peer review is about. The working hypothesis is, that peer review is realized with a stable branch in which a frozen upstream gets evaluated.
Freezing the upstream is something which is more complicated than a normal preprint server. A preprint server is location in which authors are submitting their journals. For example Arxiv is a preprint server, but Academia.edu and a github folder too. What all preprint server have in common is that no peer review takes place. Somebody uploads a document and the reader doesn't know if the document has high or a low quality.
A naive assumption is, that a preprint is transformed into a journal by peer reviewing the preprint. That means, somebody sends the manuscript to an expert and the expert gives a quality judgment. This understanding describes only the surface. What is missing is the reason why somebody should peer review a paper. A typical assumption from the past was, that peer review is equal to paid peer review. All the existing academic journals are working with money in the loop. So the assumption is, that a serious journal is equal to a high price journal.
The surprising information is, that this definition describes also not the complete picture. It's possible to combine high quality peer review with a non-commercial journal. The important underlaying process has to do with freezing the upstream. Freezing is a term used by Open Source advocates which are using the git version control system. A freeze is equal to create a branch. On the command line it's done with a simple “git branch stable” This creates a new branch, called stable, and in this branch a snapshot of the master branch is created. A freeze is equal to a point copy of the existing files.
Let me give an example. Suppose an author has uploaded a HTML document to a preprint server. The HTML document contains a 8 page long paper which consists of 20 bibliographic references at the end. Now, somebody else creates a copy of the document. He is freezing the upstream document. The result is, that both documents, original.html and copy.html can be edited independent from each other. The files are located in different folders. The ability to edit a document independently is producing a version conflict. To overcome the version conflict some sort of communication is required.
The communication actions to overcome a version conflict are equal to the peer review process of an academic journal. There are different options in doing so:
- dedicated peer review by external experts
- decision making by the journal editor
- negotiating on a mailing list
- overwrite the version by technical actions because user1 has admin rights, while user2 not
A dedicated peer review is only one option to solve a version conflict in a two branch project. The peer review process isn't at the beginning but it's an answer to a version conflict. The underlying reason is the out of sync behavior of two branches which holds the same file. Branch1 is maintained by the upstream in the preprint server, while branch2 is maintained by the journal in the downstream. Let us investigate what a potential alternative to an upstream freeze is.
Suppose the idea is not to create a stable branch but contribute to the original.html file in a different fashion. The workflow would work in the following way. At first, the author uploads the original.html file to a preprint server. Now a second user likes the article but he would like to add something. He sends an e-mail to the author with an additional paragraph. The original author accepts the modification and a new file is uploaded to the preprint server which is origina-improved.html.
That means, the modification in the file are taken place in a single branch. The original author plus user2 are communicating back and forth and if they have found a shared position, the file gets updated. Conflicts are not possible, because if the original author doesn't accept a modification the user has no option to modify the file.
The major difference between a single branch development model and a two branch model is, that in the two branch model a conflict is the possible. This conflict produces a certain communication style. Perhaps it make sense to provide an example. In the normal single branch model. the original author owns the file and the second user is a subordinate. In a two branch model the second user owns the stable branch and the original author is a subordinate. This kind of flipped social relationship is available for all peer reviewed journals. The original authors sends a manuscript to a peer reviewed serious journal only for the reason to become the subordinate of the journal editor. Not the author but the journal decides if the submission has a high quality. The advantage of this flipped role model is, that the reader of the journal has an advantage from it. The reader trust a journal if not the authors but the journal editor take the decisions.
March 23, 2020
Creating academic journals as a Linux distribution
The best role model for an academic journal is the Debian Linux distribution. Debian is working with two sections: upstream and downstream. A minimal academic journal will contain of a wiki page which contains of two sections for upstream and downstream.
The main feature is that the upstream and downstream section are running out of sync. In the downstream, the same papers are available like in the upstream section, but they have a different version. In the terms of the git version control system, the upstream section is a fork. The result is, that both sections can be edited independent from each other. This produces a lot of chaos and there is a need for an intermediate maintainer. His obligation is to sync the downstream with the upstream. And for doing so, some decisions have to made.
The result is a working journal editing pipeline. The overall system accepts incoming manuscripts in the upstream section which are provided by authors and it generates stable releases which are consumed by the audience. The idea is not completely new. The upstream section is sometimes called a preprint server, while the downstream section is equal to an overlay journal. What was missing in the past, is a clear minimalist description to build such a pipeline.
The most easy to realize system holds all the sections in a single wiki file. That means, the upstream and downstream section are not branches in a github project, but they are sections in a textfile. Then the changes of the textfile have to be tracked. How well the system is working depends only on the amount of edits. If more authors and maintainers are able to participate the journal will become more efficient.
Perhaps it make sense to describe each part. The upstream section is equal to a classical submission system. Authors are invited to upload their manuscript to a server. They can edit the document which is producing a new version. Every author can upload more than a single paper. This kind of preprint server makes sense for authors because it's a storage for their manuscript but the normal reader has no need to read through the documents. The upstream section is equal to the Arch Linux project. There is a machine generated trunk version which contains of the latest version of each document. But this trunk version has no value for the reader.
In the section “downstream” the existing content gets aggregated. The first decision to take is which of the papers are fitting to the academic journal. in the diagram the papers #1 and #2 are selected for the first issue of the journal. The issue #1 of the journal is a copy of a certain version from the upstream. It can be edited separately from the upstream version. This produces a conflict. Instead of providing a single trunk branch which holds all the papers, two branches are available which are running out of sync. This two branch model has a large impact:
- first it generates a role model for author, reader and journal maintainer They are located on different positions in the workflow
- secondly, it produces unsolved questions. The maintainer has to decide which papers are the right one and in which version they are accepted in the journal. The reader has the obligation to give feedback to the maintainer, and the author has to think about why a certain paper was rejected.
- third: the newly generated role model in combination with the unsolved questions results into a communication pipeline. A mailing list, a forum and an issue tracker is needed to coordinate all the stakeholders and requests.
Peer review made easy
Existing academic journals are equipped with a peer review. This is the main advantage over a normal preprint server. A preprint server is only an online storage for a document comparable to an individual blog, but a peer reviewed journal provides a trust layer on top of a paper which makes it more likely that a paper gets referenced by other.
So what is the secret behind the peer review process? Has it to do with sending a manuscript to experts? Yes and no. Peer review is the result of two branch development model, very similar what Linux distributions are doing. The Arch Linux distribution can be compared with a preprint server, it doesn't has a peer review. Only Debian consists of a stable and an unstable branch and the result is some sort of moderation. Perhaps it make sense to describe the overall workflow for a software project.
In the easiest case a single programmer creates a new project at github and uploads the self written sourcecode. By default a github project consists of a single branch, the master branch. Master is equal to the development aka trunk branch. If the software author has created a new version of the software he is sending the commit to this branch.
A more elaborated workflow contains of at least two branches: one development and one stable branch. By creating a stable branch a point snapshot is created from the development branch. After creating the branch, both branches will become out of sync. That means, the same file helloworld.py can be edited in the development and in the stable branch independent from each other. The result is a conflict. The conflict will be there if both branches should be merged. Because during the merge process the maintainer has to answer which of the versions is the right one.
Basically spoken, a second stable branch is created for the single purpose to create a conflict during the merge process. Every conflict has to be resolved. This can be realized with a mailing list or with a peer review. If only a single branch (the development branch) is available no conflict is there and no peer review is needed. The conflict can be explained with social roles. In the example with the two branch github model there are two conflicting roles: one programmer is responsible for the development branch and the other for the stable branch. The role conflict is producing a higher quality of the project. That's the reason why the Debian Linux distribution is recommended for productiion server, while Arch LInux isn't recommended for such a purpose. And exactly for the same reason, a peer reviewed paper gets referenced by other while non-peer reviewed paper won't.
Let us go back to the inner working of an academic journal. Suppose a journal contains of a development branch and a stable branch. The result is, that in the stable branch some decisions have to be taken. The major decision is, if a paper in the development branch should be published in the next issue. Solving this problem can be done in many ways. Either a random generator is asked, a formalized rule book is asked or in the best case, an external peer reviewer is asked for a quality judgment. That means, the maintainer of the stable branch of an academic journal makes his life easier, if he sends out an unpublished manuscript to external experts and asks them to review the content.
If the stable branch maintainer isn't doing so, he can't do a decision if the paper should be published. The consequence is, that the next issue can't be go online. The same situation is available for the Debian distribution. Before the next major release is published, the maintainers have to answer the question, if a certain upstream version should be included in the distribution or not. This kind of decision is only needed for stable release Linux distribution. In the Arch Linux project there is no need for such a decision, because the upstream dictates which version is the correct one, which is always the latest, no matter if it's an improvement or not.
Academic journal from scratch
Creating a peer reviewed journal from scratch is pretty easy. All what is needed is a two branch development model which is running out of sync. In the unstable branch the authors are uploading their manuscripts and in the stable branch the next release of the journal is prepared. Everything else, for example in which file format the manuscript is accepted, or which persons are allowed to peer review a paper are minor decisions. The same principle of a two branch model works in very different situations. It can be realized for a printed journal, for a predatory journal, for a serious journal, for a non sense journal, for an amateur journal, for a journal which is based on MS-Word, or which is based on LaTeX.
The social mechanic of peer reviewing is the result of a conflict between upstream and downstram branches. That means, a journal which is working with a single branch doesn't provide a peer review, and in case of two branches, a peer review is possible.
March 22, 2020
Building an academic journal with stable releases
From a technical perspective all the tools are available to create an academic journal from scratch. Webspace is available in a blog which allows to upload pdf files easily, the pdf file can be created with most document processors like Libreoffice or LaTeX and the version history during writing the document can be tracked with the git tool. Suppose a single author combines these tool and creates some papers, are these papers the same as an academic journal? No they don't, something is missing because the readers won't trust the journal. The reader understands what traditional journals are doing for example Elsevier and Wiley, but he isn't interested in reading self-created pdf papers, especially not if the content is provided for free.
It's possible to formalize the missing part better. It's called an Open Access downstream. The term downstream was invented in the domain of Linux distribution. For example the Debian distribution is the downstream, while the sourcecode in the stable version is called the upstream. The workflow from the beginning which includes the pdf file format created in LaTeX is located in the upstream. It has to do what the single author has to do for creating the content. The missing part called the downstream makes sure, that the content is forwarded to the normal user. It's a layer between the upstream and the normal user.
Let us describe what Debian is doing. Technically Debian is an additional branch in the version control system. A branch is a copy of the original content. This idea can be simplified a bit for better understanding. Suppose on the harddrive are two folders available. In folder A the incoming files from the upstream are stored, which is the pdf document of the author which contains the paper. In the folder B the stable branch is stored which can be read by the normal reader. The question what the downstream has to do answer is, what exactly should be copied into the stable branch.
In the diagram the picture explains the idea visual. Without the downstream branch, the reader has direct access to the upstream version of the documents. It's some kind of Arch Linux for academic publication. The authors are uploading the pdf files to a server, and the reader can read the information. The interesting point is, that in reality such a direct connection between author and reader doesn't work. To make the information from the upstream easier to read, the users are expecting a layer in between. This is called a journal. The journal is the downstream. It is doing the same what the Debian project is about. The journal forks the content from the upstream into an own branch, and for doing so, some decisions have to be made. In the given example, the decision was made to accept the pdf file 1 and also the pdf fil
e 2. The second decision was which version of the manuscript was accepted. The interesting result is, that for the reader it's easier to consume the downstream information than the upstream one.
It's important to know that in the journal branch no content is created, but the existing content is aggregated. The role model is again the Debian ecosystem. A debian maintainer hasn't programmed a piece of code, but he is talking with the upstream developer on a mailing list. If somebody likes to create an online academic journal, he needs such a workflow. It's only option to create trust.
It's interesting to know, that an academic journal doesn't need to be have a printed one. In the example diagram all the information is organized online only. What is important instead is, that n the version control system the upstream branch is forked into the downstream branch. The concrete decision who to do so is done by the journal editor. The result is two fold. First, for upstream authors is easier to communicate with the downstream section, and secondly it's easier for the reader to communicate with the downstream section.
How to communicate between two parties?
The diagram looks a bit complicated. There are so many circles and arrows. Why are the authors not only copy the files to a server and the reader browse through the content? This is a nice question. So good news is, that it was researched in detail for creating Linux distribution. It's the old question if Arch Linux or Debian Linux is the better development model. What the picture shows is the complicated Workflow of debian. According to the Debian community, it's not enough that the normal user gets the latest software from the upstream, but he needs a hand-curated distribution which is different from a testing repository. The result is that software developers and end-users are separated from each other. The author of a software checks in the latest changes in the upstream repository, while the user of the software has only access to the downstream version. The layer in between, called downstream, is used for communicating back and forth. That means, if the reader of a pdf paper has found a mistake he isn't contacting the original author but he opens a thread in the mailing list of the downstream community.
In the debate around Open Access this principle is sometimes called an overlay journal. An overlay journal takes existing pdf papers hosted in a repository, creates a copy of it and redistribute it to the user. Technically an overlay journal can be realized as a branch in the version control system. Let us make a practical example.
Suppose the idea is to build an academic journal in github. At first, we need two authors who have uploaded a paper to their individual git repository. In this repository the authors are allowed to maintain their individual version history. That means, the initial project gets updated to correct spelling mistakes.
Then an additional git repository is created which is a copy of the pdf file 1 and pdf file 2. Doing so is called forking. Forking means, to take a snapshot of a github folder and copy the content into a new one. Then the fork is improved a bit, for example, a cover letter is created, and a forward is written by the journal. And voila, the new academic journal is ready and can publish his first volume.
And now comes the interesting part. Such a pipeline will produce a lot of stress. The first thing what will happen is, that both upstream authors have recognized that their content was forked. They will open a new ticket in the journal directory and ask for the reason. Secondly, the first readers are not happy with the content and they will open a ticket as well. That means, in the github repository of the journal lots of traffic is created in which both sides are creating unsolved tickets. And this is equal that the journal is accepted by a third party. If somebody creates an issue against a github project he has a need to communicate with this project.
Perhaps it make sense to simply the creation of an academic journal to a minimum. From a bottom up perspective an academic journal is created with the unix command:
cp -r upstream/ downstream/
This unix command copies the existing upstream/ folder into a new one. It's not a soft link or a redirect but a copy. This copy creates a new branch from scratch and can be updated seperately. That means, if somebody edits in the file1.txt both folders will get out of sync. This produces a stress which is compensated by communication of the mailing list. Basically spoken, an academic journal is a forked of existing pdf files.
It's possible to formalize the missing part better. It's called an Open Access downstream. The term downstream was invented in the domain of Linux distribution. For example the Debian distribution is the downstream, while the sourcecode in the stable version is called the upstream. The workflow from the beginning which includes the pdf file format created in LaTeX is located in the upstream. It has to do what the single author has to do for creating the content. The missing part called the downstream makes sure, that the content is forwarded to the normal user. It's a layer between the upstream and the normal user.
Let us describe what Debian is doing. Technically Debian is an additional branch in the version control system. A branch is a copy of the original content. This idea can be simplified a bit for better understanding. Suppose on the harddrive are two folders available. In folder A the incoming files from the upstream are stored, which is the pdf document of the author which contains the paper. In the folder B the stable branch is stored which can be read by the normal reader. The question what the downstream has to do answer is, what exactly should be copied into the stable branch.
In the diagram the picture explains the idea visual. Without the downstream branch, the reader has direct access to the upstream version of the documents. It's some kind of Arch Linux for academic publication. The authors are uploading the pdf files to a server, and the reader can read the information. The interesting point is, that in reality such a direct connection between author and reader doesn't work. To make the information from the upstream easier to read, the users are expecting a layer in between. This is called a journal. The journal is the downstream. It is doing the same what the Debian project is about. The journal forks the content from the upstream into an own branch, and for doing so, some decisions have to be made. In the given example, the decision was made to accept the pdf file 1 and also the pdf fil
e 2. The second decision was which version of the manuscript was accepted. The interesting result is, that for the reader it's easier to consume the downstream information than the upstream one.
It's important to know that in the journal branch no content is created, but the existing content is aggregated. The role model is again the Debian ecosystem. A debian maintainer hasn't programmed a piece of code, but he is talking with the upstream developer on a mailing list. If somebody likes to create an online academic journal, he needs such a workflow. It's only option to create trust.
It's interesting to know, that an academic journal doesn't need to be have a printed one. In the example diagram all the information is organized online only. What is important instead is, that n the version control system the upstream branch is forked into the downstream branch. The concrete decision who to do so is done by the journal editor. The result is two fold. First, for upstream authors is easier to communicate with the downstream section, and secondly it's easier for the reader to communicate with the downstream section.
How to communicate between two parties?
The diagram looks a bit complicated. There are so many circles and arrows. Why are the authors not only copy the files to a server and the reader browse through the content? This is a nice question. So good news is, that it was researched in detail for creating Linux distribution. It's the old question if Arch Linux or Debian Linux is the better development model. What the picture shows is the complicated Workflow of debian. According to the Debian community, it's not enough that the normal user gets the latest software from the upstream, but he needs a hand-curated distribution which is different from a testing repository. The result is that software developers and end-users are separated from each other. The author of a software checks in the latest changes in the upstream repository, while the user of the software has only access to the downstream version. The layer in between, called downstream, is used for communicating back and forth. That means, if the reader of a pdf paper has found a mistake he isn't contacting the original author but he opens a thread in the mailing list of the downstream community.
In the debate around Open Access this principle is sometimes called an overlay journal. An overlay journal takes existing pdf papers hosted in a repository, creates a copy of it and redistribute it to the user. Technically an overlay journal can be realized as a branch in the version control system. Let us make a practical example.
Suppose the idea is to build an academic journal in github. At first, we need two authors who have uploaded a paper to their individual git repository. In this repository the authors are allowed to maintain their individual version history. That means, the initial project gets updated to correct spelling mistakes.
Then an additional git repository is created which is a copy of the pdf file 1 and pdf file 2. Doing so is called forking. Forking means, to take a snapshot of a github folder and copy the content into a new one. Then the fork is improved a bit, for example, a cover letter is created, and a forward is written by the journal. And voila, the new academic journal is ready and can publish his first volume.
And now comes the interesting part. Such a pipeline will produce a lot of stress. The first thing what will happen is, that both upstream authors have recognized that their content was forked. They will open a new ticket in the journal directory and ask for the reason. Secondly, the first readers are not happy with the content and they will open a ticket as well. That means, in the github repository of the journal lots of traffic is created in which both sides are creating unsolved tickets. And this is equal that the journal is accepted by a third party. If somebody creates an issue against a github project he has a need to communicate with this project.
Perhaps it make sense to simply the creation of an academic journal to a minimum. From a bottom up perspective an academic journal is created with the unix command:
cp -r upstream/ downstream/
This unix command copies the existing upstream/ folder into a new one. It's not a soft link or a redirect but a copy. This copy creates a new branch from scratch and can be updated seperately. That means, if somebody edits in the file1.txt both folders will get out of sync. This produces a stress which is compensated by communication of the mailing list. Basically spoken, an academic journal is a forked of existing pdf files.
Can Wikipedia be forked?
The entire Wikipedia is too large to create a fork. The project has over 20k users and building a second encyclopedia from scratch would take too much manpower. But, if the aim is to fork only a single category, for example articles about Artificial Intelligence, a fork isn't very hard.
Suppose a single user creates 30 edits per month with a size of 1000 byte each. And the fork contains of 10 users who are working in parallel. After 5 year the project has generated 9000 article with 2000 byte for each of them. And after 10 years the small team of 10 users has produced the same amount of content which is available in real Wikipedia.
A good starting point of a Wikipedia fork is to submit new articles no longer to the Wikipedia itself, but only to the fork. The list with requested articles about AI is located at https://en.wikipedia.org/wiki/Wikipedia:Requested_articles/Applied_arts_and_sciences/Computer_science,_computing,_and_Internet#Artificial_Intelligence The content isn't written yet. But it can be created from scratch and then the article gets uploaded to the fork wiki. The bottleneck for the project is to motivate some users to participate. In most cases the users are only interested to upload content to Wikipedia but not a fork, because the clone has a smaller amount of pageview and no working copy editing team which is correcting spelling mistakes and moderates the process.
On the other hand, the content of the original wikipedia is overestimated. The articles in the AI sections contains of around 50 flagship articles with 50k bytes, and the rest has a poor quality. It's possible to build something which works better from scratch. That means, without take the existing content as starting point but create everything from scratch which will result into the lowest possible copyright conflict.
The only thing what is harder to fork is Google Scholar. Google Scholar and the underlying full text repository contains of 50 million academic papers. The AI Section in Google Scholar has around 1 million papers written by scholarly authors. Writing this content from scratch is very complicated and would take large amount of time and manpower. In contrast, the WIkipedia project is some kind of slideshow community. The users are creating overview snippets for existing academic full text paper in the hope that this is attractive for a larger audience.
The reason why academic publishers are not motivated to engage in Wikipedia is simple: because the project is trivial. Trivial means, that the amount of ressources which are required to build an encyclopedia is low. The entire WIkipedia which contains of all articles can be run with around 10k people. If the aim is to build only a subpart of the project about a single academic topic, for example artificial Intelligence, the amount of needed ressources are around 10 persons who are creating the content from scratch. That means, academic authors are able to build their own encyclopedia from scratch without copy&paste a single sentence. They are writing all the articles from scratch with less than 100 users in a short amount of time.
Suppose a single user creates 30 edits per month with a size of 1000 byte each. And the fork contains of 10 users who are working in parallel. After 5 year the project has generated 9000 article with 2000 byte for each of them. And after 10 years the small team of 10 users has produced the same amount of content which is available in real Wikipedia.
A good starting point of a Wikipedia fork is to submit new articles no longer to the Wikipedia itself, but only to the fork. The list with requested articles about AI is located at https://en.wikipedia.org/wiki/Wikipedia:Requested_articles/Applied_arts_and_sciences/Computer_science,_computing,_and_Internet#Artificial_Intelligence The content isn't written yet. But it can be created from scratch and then the article gets uploaded to the fork wiki. The bottleneck for the project is to motivate some users to participate. In most cases the users are only interested to upload content to Wikipedia but not a fork, because the clone has a smaller amount of pageview and no working copy editing team which is correcting spelling mistakes and moderates the process.
On the other hand, the content of the original wikipedia is overestimated. The articles in the AI sections contains of around 50 flagship articles with 50k bytes, and the rest has a poor quality. It's possible to build something which works better from scratch. That means, without take the existing content as starting point but create everything from scratch which will result into the lowest possible copyright conflict.
The only thing what is harder to fork is Google Scholar. Google Scholar and the underlying full text repository contains of 50 million academic papers. The AI Section in Google Scholar has around 1 million papers written by scholarly authors. Writing this content from scratch is very complicated and would take large amount of time and manpower. In contrast, the WIkipedia project is some kind of slideshow community. The users are creating overview snippets for existing academic full text paper in the hope that this is attractive for a larger audience.
The reason why academic publishers are not motivated to engage in Wikipedia is simple: because the project is trivial. Trivial means, that the amount of ressources which are required to build an encyclopedia is low. The entire WIkipedia which contains of all articles can be run with around 10k people. If the aim is to build only a subpart of the project about a single academic topic, for example artificial Intelligence, the amount of needed ressources are around 10 persons who are creating the content from scratch. That means, academic authors are able to build their own encyclopedia from scratch without copy&paste a single sentence. They are writing all the articles from scratch with less than 100 users in a short amount of time.
Small rant against the C language
The C language is the big elephant in the room. Everybody is writing C code but nobody is talking about. Let us change the rules of the game and try to overcome outdated C syntax and use a different kind of programming language for writing operating systems kernel, programming embedded applications, create graphics library and write object oriented applications.
Possible candidates for replacing C code are Java, C# and especially C++. A short look into a Linux distribution have shown that the C++ language isn't used very often https://dwheeler.com/sloc/redhat71-v1/redhat71sloc.1.00.html Only 15% were written in C++. And the assumption is high, that especially programcode which is not installed on real computers, for example KDE was written in C++, so that on running machines the ratio is worse for C++. But why exactly was C++ never able to replace C? The first version of C++ was published in the mid 1980s. Since then there was enough time to rewrite and recompile all the code. But this project was never started. All the newly written code is using the normal C language with minor modifications for example C99 instead of C89.
The paradox situation is, that C++ has replaced C in one category: the amount of books written about Object oriented programming in C++ is much higher than for C. The only book ever written about OOP in C was published in 1993 “Axel-Tobias Schreiner: Object-Oriented Programming With ANSI-C, 1993”. Apart from the book, there are two! (not more) Dr.Dobbs articles in the 1990s which are explaining how to program classes in C, and in some stackoverflow postings the topic is also discussed.
In contrast, the amount of papers, journals and books who are explaining how to program Object-oriented in the C++ language is larger than 20k overall. Additionally, nearly all university in the world is teaching how to program in C++ object oriented software. It seems, that the problem has to do with the difference between written code in the wild (mostly C) and computer classes in the university which are focussed on C++.
From a technical perspective it's not very complicated to create object oriented code in C. All what is needed are some function pointers, some structs and a bit discpline of the programmer. A look into existing software project at github will show, that most C programmers are experts for object oriented code. They are managing complexity in the written code by combining structs with functions in the same module. And they have no need for other programming languages like C++, Java or C#.
The only user group who is using dedicated OOP languages like Python or Java are newbies who are not familar with computer programming. They are reading all the C++ books in the hope to learn how to write object oriented code. This paradox situation can be overcome easily. What is needed are books with the title “OOP in C”. SImilar to to the mentioned book from AT Schreiner but published in the year 2020. Such books aren't available yet. And exactly of this reason, the newbies won't learn C at all. The typical newbie has understood that object oriented programming is a here to stay. Because it simplifies the programming of GUI Applications and games very well. And because the newbie has never programmed in any language at all, he decides for a typical OOP language in the hope this is the future. For example he is learning Java or C++.
The consequence is, that the newbie will waste his time. Because C++ won't never replace C code. The C language is way to powerful and provides too much object oriented features that expert programmer will switch to a different kind of language in the future. Basically spoken the existing software projects written in C for example the Linux kernel, the Windows kernel or a larger game can be translated with an UML generator into a nice looking object-oriented diagram. That means, there are objects (aka structs) and functions which have access to these objects. It's not possible to reprogram the Linux kernel in C++ because it is using object-orientation already.
Possible candidates for replacing C code are Java, C# and especially C++. A short look into a Linux distribution have shown that the C++ language isn't used very often https://dwheeler.com/sloc/redhat71-v1/redhat71sloc.1.00.html Only 15% were written in C++. And the assumption is high, that especially programcode which is not installed on real computers, for example KDE was written in C++, so that on running machines the ratio is worse for C++. But why exactly was C++ never able to replace C? The first version of C++ was published in the mid 1980s. Since then there was enough time to rewrite and recompile all the code. But this project was never started. All the newly written code is using the normal C language with minor modifications for example C99 instead of C89.
The paradox situation is, that C++ has replaced C in one category: the amount of books written about Object oriented programming in C++ is much higher than for C. The only book ever written about OOP in C was published in 1993 “Axel-Tobias Schreiner: Object-Oriented Programming With ANSI-C, 1993”. Apart from the book, there are two! (not more) Dr.Dobbs articles in the 1990s which are explaining how to program classes in C, and in some stackoverflow postings the topic is also discussed.
In contrast, the amount of papers, journals and books who are explaining how to program Object-oriented in the C++ language is larger than 20k overall. Additionally, nearly all university in the world is teaching how to program in C++ object oriented software. It seems, that the problem has to do with the difference between written code in the wild (mostly C) and computer classes in the university which are focussed on C++.
From a technical perspective it's not very complicated to create object oriented code in C. All what is needed are some function pointers, some structs and a bit discpline of the programmer. A look into existing software project at github will show, that most C programmers are experts for object oriented code. They are managing complexity in the written code by combining structs with functions in the same module. And they have no need for other programming languages like C++, Java or C#.
The only user group who is using dedicated OOP languages like Python or Java are newbies who are not familar with computer programming. They are reading all the C++ books in the hope to learn how to write object oriented code. This paradox situation can be overcome easily. What is needed are books with the title “OOP in C”. SImilar to to the mentioned book from AT Schreiner but published in the year 2020. Such books aren't available yet. And exactly of this reason, the newbies won't learn C at all. The typical newbie has understood that object oriented programming is a here to stay. Because it simplifies the programming of GUI Applications and games very well. And because the newbie has never programmed in any language at all, he decides for a typical OOP language in the hope this is the future. For example he is learning Java or C++.
The consequence is, that the newbie will waste his time. Because C++ won't never replace C code. The C language is way to powerful and provides too much object oriented features that expert programmer will switch to a different kind of language in the future. Basically spoken the existing software projects written in C for example the Linux kernel, the Windows kernel or a larger game can be translated with an UML generator into a nice looking object-oriented diagram. That means, there are objects (aka structs) and functions which have access to these objects. It's not possible to reprogram the Linux kernel in C++ because it is using object-orientation already.
The biggest strength of Python is it's slowness
If a newbie tries out the Python interpreter for the first time, he will notice that the code runs horrible slow. Compared to the compiled C language a python program is around 20x slower which makes the language unusable for practical application. And exactly for this reason Python is a great language. Because it draws a line between teaching and productive scenario.
From a technical point of view, it's not very hard to make Python faster. One option is to optimize the python interpreter or develop a just in time compiler. The resulting language would have much in common with node.js, java and C++. It will become a language which is used for teaching programming and for programming real systems at the same time.
The good news is, that this is not the goal of Python. It's a teaching language. It allows to learn programming and create prototypes but the Python ecosystem prevents that Python code gets executed in real operating systems. Let us compare Python with other object oriented languages:
Java, C++, C#, node.js and ruby have in common that they are used for teaching programming to the newbies. Java for example is widely used in an academic context. It explains very well what object oriented programming is. The fast executation speed is that main difference of Java to Python. A fast execution speed implies that the language can be used outside a learning environment as an alternative to C.
Is Java able to replace C programs? No it doesn't. C is the number one language in the wild. It's used for creating operating systems, libraries, AAA game and object-oriented desktop application. The only problem with C is, that it's not used for teaching programming, because it has no explicit classes. And exactly this gap was filled by Python. Python is the missing part to train the newbies. If somebody has understand who to write Python programs he can try to use C structs and C pointers for doing the same for writing production ready code.
Python -> C -> Forth
Python is the number one language for creating prototypes and learn to program. The entry barrier for creating python scripts is very low. Even non programmer can create a hello world application within minutes. The C language is the number language for creating software in the wild. Most (>80%) softwareprojects in the reality are realized in C and it's superior to C++, Java and C#. C is the dominant language for the x86 PC architecture and any sort of application can be created. The Forth language is a special case, it's a language for programmers who are already with C and who are searching for a faster alternative. The main difference is that Forth will run on non-x86 systems which can be designed in FPGAs from scratch. Rewritting existing C code into Forth is good startin point to get familiar with stack-based computing.
Educational programming languages
Recent object oriented languages like Java and C# are teached very often in computer courses as an example for object oriented programming. The audience are newbies and non-programmers who are interested in learning the language from scratch. Python can be teached also in such courses. The main difference between Python and Java is, that Python programmers are aware that their language can't be used for practical applications. If they are writing a small prime number generator with a for loop they will recognize very soon, that the language is way to slow for practical applications. Python is an educational only language. That menas, if somebody like to program software in the wild he won't use Python.
In contrast the educational situation for Java is different. Java is used in introduction courses and the same Java language has become popular in writing real applications. Similar to C++, Java is used in an academic context and for practical applications at the same time. The problem is that programming experts are using C since 30 years and they are not planning to rewrite the code in any other language. That means, all the newly written Java, C++, Python and Ruby libraries are useless. Real operating systems are equipped with normal C libraries which are providing the maximum performance and are maintained by experts and any other language is critized as a toy language. In the case of Python, the Python community won't argue against it. They know, that Python can't replace a C library.
The situation in the programming world is, that there is the expert language C on the one hand which is used for creating important software, productive software and for large scale projects, and all the other languages were developed for niche problems, for academic purposes or as an alternative to C. A relative new understanding of computer programming is, that the C language is especially recommended for object oriented programming. This is a bit surprising, because C++, Java and C# were developed as a dedicated OOP language, but they have failed to replace C in this domain.
What the alternative languages over C have in common is, that they are widespread used in an educational setting. Many books were written about it and they are used in computer courses at the university. In contrast, the C language is never teached anyware and modern literature isn't available. The assumption of the newbies is, that the C language is outdated and is replaced by Java, C++ and other languages. This thesis isn't backuped by the percpetion in the reality. If software projects becomes larger, and are realzed with modern OOP technique it's in all cases a C only programming project. This is not wishful thinking but can be determined by take a look into the sourcecode of the software.
Why is C so popular? The reason is, that software engineering can't be separated from low level programming. If somebody likes to write a high level application he will need an operating system and existing libraries for doing so. To get access to the existing sourcecode, an API is needed and every API is working with pointers. Even higher languages like C++ and Java are using pointers all the time, and before the newbie is able to program in Java he has to know what pointers are. That means, it's not possible to ignore the topic at all.
And if C supports pointers, structs and modules out of the box, the programmer has no need to use a different langauge than the existing one. That means, especially newly written code is created in C. The prediction is, that this will be the same in 10 years from now, except somebody invents a language which can replace C.
The only area in which C can be ignored is for academic reasons and for software prototyping. If the idea is to explain in general what object oriented programming is, how an algorithm is working in theory and how to create an UML diagram, the C language isn't the best choice in doing so. A java based UML Generator is the prefered choice for software engineering teaching, while algorithm can be explained with Python very well. It makes no sense to print a screenshot of C sourcecode in a textbook because the syntax is hard to understand. C is way to low level and provides too much details of the underlying CPU.
From a technical point of view, it's not very hard to make Python faster. One option is to optimize the python interpreter or develop a just in time compiler. The resulting language would have much in common with node.js, java and C++. It will become a language which is used for teaching programming and for programming real systems at the same time.
The good news is, that this is not the goal of Python. It's a teaching language. It allows to learn programming and create prototypes but the Python ecosystem prevents that Python code gets executed in real operating systems. Let us compare Python with other object oriented languages:
Java, C++, C#, node.js and ruby have in common that they are used for teaching programming to the newbies. Java for example is widely used in an academic context. It explains very well what object oriented programming is. The fast executation speed is that main difference of Java to Python. A fast execution speed implies that the language can be used outside a learning environment as an alternative to C.
Is Java able to replace C programs? No it doesn't. C is the number one language in the wild. It's used for creating operating systems, libraries, AAA game and object-oriented desktop application. The only problem with C is, that it's not used for teaching programming, because it has no explicit classes. And exactly this gap was filled by Python. Python is the missing part to train the newbies. If somebody has understand who to write Python programs he can try to use C structs and C pointers for doing the same for writing production ready code.
Python -> C -> Forth
Python is the number one language for creating prototypes and learn to program. The entry barrier for creating python scripts is very low. Even non programmer can create a hello world application within minutes. The C language is the number language for creating software in the wild. Most (>80%) softwareprojects in the reality are realized in C and it's superior to C++, Java and C#. C is the dominant language for the x86 PC architecture and any sort of application can be created. The Forth language is a special case, it's a language for programmers who are already with C and who are searching for a faster alternative. The main difference is that Forth will run on non-x86 systems which can be designed in FPGAs from scratch. Rewritting existing C code into Forth is good startin point to get familiar with stack-based computing.
Educational programming languages
Recent object oriented languages like Java and C# are teached very often in computer courses as an example for object oriented programming. The audience are newbies and non-programmers who are interested in learning the language from scratch. Python can be teached also in such courses. The main difference between Python and Java is, that Python programmers are aware that their language can't be used for practical applications. If they are writing a small prime number generator with a for loop they will recognize very soon, that the language is way to slow for practical applications. Python is an educational only language. That menas, if somebody like to program software in the wild he won't use Python.
In contrast the educational situation for Java is different. Java is used in introduction courses and the same Java language has become popular in writing real applications. Similar to C++, Java is used in an academic context and for practical applications at the same time. The problem is that programming experts are using C since 30 years and they are not planning to rewrite the code in any other language. That means, all the newly written Java, C++, Python and Ruby libraries are useless. Real operating systems are equipped with normal C libraries which are providing the maximum performance and are maintained by experts and any other language is critized as a toy language. In the case of Python, the Python community won't argue against it. They know, that Python can't replace a C library.
The situation in the programming world is, that there is the expert language C on the one hand which is used for creating important software, productive software and for large scale projects, and all the other languages were developed for niche problems, for academic purposes or as an alternative to C. A relative new understanding of computer programming is, that the C language is especially recommended for object oriented programming. This is a bit surprising, because C++, Java and C# were developed as a dedicated OOP language, but they have failed to replace C in this domain.
What the alternative languages over C have in common is, that they are widespread used in an educational setting. Many books were written about it and they are used in computer courses at the university. In contrast, the C language is never teached anyware and modern literature isn't available. The assumption of the newbies is, that the C language is outdated and is replaced by Java, C++ and other languages. This thesis isn't backuped by the percpetion in the reality. If software projects becomes larger, and are realzed with modern OOP technique it's in all cases a C only programming project. This is not wishful thinking but can be determined by take a look into the sourcecode of the software.
Why is C so popular? The reason is, that software engineering can't be separated from low level programming. If somebody likes to write a high level application he will need an operating system and existing libraries for doing so. To get access to the existing sourcecode, an API is needed and every API is working with pointers. Even higher languages like C++ and Java are using pointers all the time, and before the newbie is able to program in Java he has to know what pointers are. That means, it's not possible to ignore the topic at all.
And if C supports pointers, structs and modules out of the box, the programmer has no need to use a different langauge than the existing one. That means, especially newly written code is created in C. The prediction is, that this will be the same in 10 years from now, except somebody invents a language which can replace C.
The only area in which C can be ignored is for academic reasons and for software prototyping. If the idea is to explain in general what object oriented programming is, how an algorithm is working in theory and how to create an UML diagram, the C language isn't the best choice in doing so. A java based UML Generator is the prefered choice for software engineering teaching, while algorithm can be explained with Python very well. It makes no sense to print a screenshot of C sourcecode in a textbook because the syntax is hard to understand. C is way to low level and provides too much details of the underlying CPU.
What happens since the 1990s with the C language?`
Around the year 1990 was a major milestone in computer programming. Because in this year, two important programming languages were available at the same time. The well known C language plus the newly developed C++ language. In the year 1990 both larger compiler suites from Borland and Microsoft has declared C++ as the new major language.
From today's perspective it's hard to explain why this event took place. Since the year 1990, the well known C Language is no longer relevant for computer education but was replaced with C++, Java and C#. The interesting fact is, that around the year 1990 some tutorials were published how to combine object oriented programming with a c compiler. Some libraries were written to extend the C standard with classes, but in the tutorials it was also explained how to combine normal C structs with c functions into objects.
The attempt of combining the well known C language with object oriented design technique was never very popular in the literature. In the reality, which means in the written code, it was very popular. Nearly all serious C libraries are using object oriented methods in combination with an ANSI C coding style. But let us listen what the advocates of C++ and Java are explaining in their books. The main idea was, that object oriented programming makes only sense if an object oriented language is used. The C language doesn't contains of objects and inheritance, so it's logical to invent a new programming language, which was C++ in the year 1990 and Java in the late 1990s.
The interesting situation is, that C++ never was popular for expert programmers. Linus Torvalds doesn't like C++, and he is not the only one. C++ was only popular for newbies who doesn't know anything about programming. They dreamed of writing larger projects with the object oriented C++ style. Some attempts were made, but such projects are not very popular for productive machines.
The reason is simple: The c language can be used by expert programmers similar to the C++ language for realizing larger projects. The programmer is dividing the task into modules, uses structs and pointers everywhere and doesn't miss C++ classes. The advantage of C is, that the program can be compiled for embedded systems and the C compiler is easier to maintain than a C++ compiler.
The question is not why the Linux kernel, systemd and the gtk+ system was written in C, the question is why is C++ teached in the university and has become so popular at Stackoverflow? The main problem which is solved by Stackoverflow and acedemic programming courses is not write production ready code, but the objective is to explain to the newbies what programming is about. C++ and other OOP language can be interpreted as a learning language. They were designed for educational purposes. The idea is, that the student can understand with C++ easier what a class is. The unsolved question is, what the student should do with his C++ knowledge if real projects are written entirely in ANSI C and will do for the next 30 years?
Somebody may argue, that knowledge about object oriented programming can be utilized for programming in any language. But can the C++ knowledge be used to create ANSI C programs as well? No it can't, because this is not described in the literature. I have found only a single book which explains how to program in C with the OOP technique, plus some smaller discussion threads in Stackoverflow. That means, according to the literature a programmer has to stay either in the C++ / Java language family, or he has to program with a procedural technique in C which makes it impossible to create larger projects.
But, if no book is available how to use OOP knowledge for writing C code, the normal student isn't able to do so in reality. That means, C++ knowledge isn't teached to use it for writing better C programs, but the literature doesn't make sense at all.
It's some kind of paradox situation, that C programmers who are familiar with object oriented programmer never write a book about the topic, while teachers who are familiar with OOP programming are writing books about Java, but not about the C language. The result is a gap, between theoretical education and practical software development. C programmers and C++ programmers doesn't talk to each other.
The exact year can be traced back in time. It was in the year 1990. In this time only the c language was available, and C++ was not used in mainstream computing. Since the 1990 it was discussed in the literature how to create larger software projects with the help of Object oriented programming. Newly languages like Borland delphi were developed for this purpose. And even today, the question is open which programming language is the best.
The rosettacode website collects programming problems. There is a section available in which the different programming languages should create a class. The interesting point is, that even non OOP languages like C and Forth are asked in doing so. https://rosettacode.org/wiki/Classes#C The example code for C shows very well how expert C programmers are creating a class in their language. At first a struct is created. Instead of putting the struct to the stack, a pointer to the struct is created and the malloc command is used. Then a constructor and a destructor function allows to create and destroy the class. What is interesting to is the naming convention. The function have the class name in the beginning and then follows the method name: MyClass_delete.
Creating single inheritance with the c syntax is possible but a bit more complicated.
From today's perspective it's hard to explain why this event took place. Since the year 1990, the well known C Language is no longer relevant for computer education but was replaced with C++, Java and C#. The interesting fact is, that around the year 1990 some tutorials were published how to combine object oriented programming with a c compiler. Some libraries were written to extend the C standard with classes, but in the tutorials it was also explained how to combine normal C structs with c functions into objects.
The attempt of combining the well known C language with object oriented design technique was never very popular in the literature. In the reality, which means in the written code, it was very popular. Nearly all serious C libraries are using object oriented methods in combination with an ANSI C coding style. But let us listen what the advocates of C++ and Java are explaining in their books. The main idea was, that object oriented programming makes only sense if an object oriented language is used. The C language doesn't contains of objects and inheritance, so it's logical to invent a new programming language, which was C++ in the year 1990 and Java in the late 1990s.
The interesting situation is, that C++ never was popular for expert programmers. Linus Torvalds doesn't like C++, and he is not the only one. C++ was only popular for newbies who doesn't know anything about programming. They dreamed of writing larger projects with the object oriented C++ style. Some attempts were made, but such projects are not very popular for productive machines.
The reason is simple: The c language can be used by expert programmers similar to the C++ language for realizing larger projects. The programmer is dividing the task into modules, uses structs and pointers everywhere and doesn't miss C++ classes. The advantage of C is, that the program can be compiled for embedded systems and the C compiler is easier to maintain than a C++ compiler.
The question is not why the Linux kernel, systemd and the gtk+ system was written in C, the question is why is C++ teached in the university and has become so popular at Stackoverflow? The main problem which is solved by Stackoverflow and acedemic programming courses is not write production ready code, but the objective is to explain to the newbies what programming is about. C++ and other OOP language can be interpreted as a learning language. They were designed for educational purposes. The idea is, that the student can understand with C++ easier what a class is. The unsolved question is, what the student should do with his C++ knowledge if real projects are written entirely in ANSI C and will do for the next 30 years?
Somebody may argue, that knowledge about object oriented programming can be utilized for programming in any language. But can the C++ knowledge be used to create ANSI C programs as well? No it can't, because this is not described in the literature. I have found only a single book which explains how to program in C with the OOP technique, plus some smaller discussion threads in Stackoverflow. That means, according to the literature a programmer has to stay either in the C++ / Java language family, or he has to program with a procedural technique in C which makes it impossible to create larger projects.
But, if no book is available how to use OOP knowledge for writing C code, the normal student isn't able to do so in reality. That means, C++ knowledge isn't teached to use it for writing better C programs, but the literature doesn't make sense at all.
It's some kind of paradox situation, that C programmers who are familiar with object oriented programmer never write a book about the topic, while teachers who are familiar with OOP programming are writing books about Java, but not about the C language. The result is a gap, between theoretical education and practical software development. C programmers and C++ programmers doesn't talk to each other.
The exact year can be traced back in time. It was in the year 1990. In this time only the c language was available, and C++ was not used in mainstream computing. Since the 1990 it was discussed in the literature how to create larger software projects with the help of Object oriented programming. Newly languages like Borland delphi were developed for this purpose. And even today, the question is open which programming language is the best.
The rosettacode website collects programming problems. There is a section available in which the different programming languages should create a class. The interesting point is, that even non OOP languages like C and Forth are asked in doing so. https://rosettacode.org/wiki/Classes#C The example code for C shows very well how expert C programmers are creating a class in their language. At first a struct is created. Instead of putting the struct to the stack, a pointer to the struct is created and the malloc command is used. Then a constructor and a destructor function allows to create and destroy the class. What is interesting to is the naming convention. The function have the class name in the beginning and then follows the method name: MyClass_delete.
Creating single inheritance with the c syntax is possible but a bit more complicated.
Subscribe to:
Posts (Atom)