Home
Blog
Projects
Cookbook
Library
RSS
Donate
XMR
Lately I've voiced some of my opinions on the current and future of the software industry and probably the biggest threat to the industry and one of the biggest threats to modern society is the laziness of soydevs. Soydev is a term coined and popularized by Luke Smith and as a combination of the terms "soy-boy" and "software developer" and I'd say that the best description of a soydev is a developer who lacks professionalism, especially when it comes to familiarizing themselves with worthwhile but difficult coding practices.
A long time ago I'd spend time scrolling through parts of the internet where individuals would share programming memes, of course none of the stuff there was actually funny and it got quite repetitive as I realized that half the memes were about people's inability to type the sequence :wq while in normal mode in Vim, copying and pasting things from Stack Overflow, or it was people screeching about how HTML isn't a programming language and then probably not knowing how to correct people on that misconception by saying it is a markup language despite "Markup Language" being what the ML in HTML stands for. These are uninteresting people who were taught the difference between Git and Github through a meme comparing it to Pornhub and while we already know they don't use Vim they probably don't even use ctrl-z to undo their mistakes and instead use their mouse to open a menu to find the undo button (yes, I have seen people who call themselves programmers do this). The people creating and consooming this sort of content are a plague to the industry, they are not professionals they are meme loving posers.
That last paragraph may sound a bit harsh until you realize the severity of the problem, as Bob Martin points out in the talk I referenced in an earlier article it is only a matter of time before some lazy soydev is tasked with writing software that runs on a large commercial airplane and their lack of discipline causes them to miss a bug that causes the plane to malfunction, crash and kill hundreds of people. As the modern world becomes more reliant on software it seeps into areas where bugs and glitches have much worse consequences than dead links and corrupted files.
In my opinion, one of the most dangerous soydev tendencies is the worship of Python as if it is the only language needed for anything. Of course I don't see Python as worthless, the last few projects I've showcased here were written in Python, it is a great language to use while exploring new areas of computer science because it allows programmers to focus on the new concepts they are exploring rather than syntax, but Python is not really suitable for much beyond that since it is slow due to the fact that it is an interpreted language.
But that fact doesn't prevent these people schilling it and producing graphics like the one below that I'd like to discuss.
This graphic is clearly meant to persuade people of Python's superiority over C++ as it shows that the same thing can be written in Python with less lines of code than it can be in C++, emphasizing ease of programming over actual performance of the program being written (in other words these people put their convenience before that of their customer). But I'm not going to spend time talking about that, you can find that sort of commentary all over the place, instead I'm going to analyze this as a graph because that is what it is trying to mimic and with all graphs floating around on the internet it needs to be properly analyzed before it is taken seriously.
When trying to figure out how much effort is necessary to write a program, or how difficult an already written program was simple lines of code aren't a good metric because all lines of code are not created equal. I've had to write a program that takes a month number and a year as inputs and needed to correctly display the calendar for that month at least three times and I'm sure there are some of you who have had to write this kind of a program in a beginning level class as well. This program would have many different parts in order to function properly, an example of one of these parts would be the part that takes the month number and figures out which month it actually is since the actual word would need to be displayed rather than the number, another example would be the part that has to determine what day of the week the first day of the month lands on.
Which of those two parts of that calendar program is harder to make? Obviously it is the part that determines what day of the week to put the first on since that's not something that is at the top of our head unlike translating numbers to month names which we were taught to do in kindergarten. Now which of these two tasks takes more lines of code? While it is harder to place the first day of the month it is also possible to be done in a very small number of lines because there exist handy formulas to do that (I might have done it with just one once but I can't remember), while translating a month number to name will take at least 24 lines of code no matter how you do it. Pure length of code is not a measure of difficulty, instead software is often measured in what is called effective lines of code.
An effective line of code is one that does something non-trivial, within the 24 lines that pick out month names not one can really be considered an effective line of code (the hardest part about it is spelling February right) while just about all the lines associated with placing the first day on the right day of the week can be considered an effective line of code, proving that this measurement is much more effective at measuring difficulty.
Now let's look at our graphic through that lens rather than the lens that our brains default to, in this scenario we could consider both of the lines of Python to be effective, but looking at the C++ program we don't have an effective line until the first for loop and we can really only call the two for loop declarations and two cout statements as effective lines of code. This graphic is making something that is 2 to 4 look like it is 2 to 16, 2 against 4 is a lot more fair of a comparison.
But even if we ignore the whole concept of effective lines of code it is still quite clear to anyone familiar with C++ that the C++ program the graphic presented is designed to lengthen out the program. The innermost pair of curly braces are completely unnecessary because the for loop it belongs to only has one instruction, single line loops don't need curly braces, so that takes off two whole lines. Then of course there is the issue of formatting the curly braces, most people do put them on separate lines when writing C++ but if you are worried about total lines of code then there is nothing wrong with putting the opening brace on the line above like is conventional with Java, so that would take off another two lines.
But those of course are forgivable sins, the first two lines within the function are not at all represented in the Python program. If the Python program uses a constant rather than a variable in the for loop then the C++ program should be able to use a constant as well so we can get rid of that first line. Then there is the cin statement, if the Python program isn't asking for any user input then neither should the C++ program. (Plus what kind of moron expects the user to give them good input without prompting them?)
Then if we really want to start cutting lines you don't need to have "using namespace std" in there, I went a whole semester not being allowed to use that, and the main function doesn't actually need a return statement. So with that we've determined that half of the C++ lines are completely unnecessary and I've still let two lines with only a closing curly brace slide.
Why would anyone trust a graph that shows one thing twice as large as it should be, or looking back at the last section four times as large?
Now if I were to be in some sort of a debate with a soydev about this they'd try to brush off the severity of the bad graphic and claim that the real point of it was to take a look at how great it is that you can multiply a string by an integer to get that behavior. In this hypothetical debate I'd have two things to say, first I'd ask when else this sort of thing actually comes in handy since I've never found myself needing this functionality, but the more productive of my arguments would be to point out that if you really need that functionality in C++ (and with many other languages that don't offer it by default) you can just code it in yourself.
Overriding operators is not that hard, here I've rewritten the C++ program from the graphic where the main part of it functions just like the Python one does by multiplying a string by an integer to duplicate it:
#include <iostream>
#include <string>
using namespace std;
string operator * (string const &lhs, int const &rhs)
{
string result;
for (int i = 0; i < rhs; ++i)
result += lhs;
return result;
}
int main()
{
string brick = "* ";
for(int i = 1; i <= 5; ++i)
cout << (brick * i) << endl;
return 0;
}
With this we have two effective lines of C++ code compared to two effective lines of Python code (and I didn't even use an efficient algorithm to override the * operator). Of course overriding the * operator is quite overkill for this scenario but if there was actually some sort of use case where you'd have to be using this functionality it is always important to remember that overriding operators is an option no matter how dumb it seems.
But back to the graphic, we can see that it is clearly soydev propaganda and we should pay little attention to it
and there is no reason for us to take it seriously.
The fact that we shouldn't take this seriously is made even more clear when you look closely at the Python code and realize that it isn't
even correct as it is missing a pair of parentheses so the last line should be print((i + 1) + "* ") for it to actually work. That was one
of the first things I noticed when analyzing this graphic but I chose not to point that out so that it wouldn't distract from my more important
points, but still, why would you trust a graphic that doesn't even get the thing it is promoting right?