What do you want, a trophy? Odds are, yes, you are terrible at programming. In fact almost everyone is terrible at their jobs. Why not apply all of that energy wasted on worrying about not having good skills and invest it in, oh I don't know, oh yes I do: work on your skills.

FTW - For The Win

Conclusion at the end: "And that's the end of classical AI."

Neural networks FTW!

It will take 20 years for this to be accepted.

You just have to translate opcodes into whatever library you are using for video / sound / device support. The mods that you are executing already have the hard stuff built in, they handle their own data structures, manage memory, all designed around clock speeds that are magnitudes slower than what is possible with a modern CPU.

This seems kind of like an argument against "You aren't going to need it!" by saying "It will turn out useful later on." Of course that is how a lot of Factory classes get started in the first place. The underlying intention is to prevent technical debt: give an object a life cycle, first construct, then initialize, so you don't have to pay off the debt of adding the life cycle later on. The downside of this is that changes to init() might screw up the life cycle in an invisible way, so you still have to track down all the places where the class is instantiated to make sure they still work, because if you don't you must be willing to eat the technical debt you were only pretending to avoid in the first place. It is a risk either way.

If you are repurposing an init() method to recycle an object, you create a sizable risk of introducing inconsistent state, or possibly leaking data from the old state into the new state. You can't safely use init() to turn an old object into a just-like-new object unless your init() method also restores sensitive properties to their default values - something an init() method wouldn't normally be concerned with.

Does your process generate output and terminate as the functional mechanism? Then you don't really need exceptions, you can exit with an error. Exiting with an error, and that error is an uncaught exception, should be considered rude.

Does your process provide a service, or open interactive windows for user interaction as the functional mechanism? Then you should use exceptions, and catch those exceptions.

You have to strike a balance with how much work is done in a constructor. If you move "unnecessary" code out of the constructor, but still require some kind of init() to be called, then you will end up building Factories, and you can never have just one Factory. But if the factory is calling the slow Init() code you moved out of the constructor, all you have done is added complexity for no actual benefit.

Now you have created a public setter method for a property that maybe shouldn't be publicly settable. For a private property, you certainly don't want a public setter, but creating a private setter seems excessive.

Many post-Java languages use implicit setter methods which avoid the clutter of such boilerplate methods.

99% of people would recommend some language, usually something that has a large open source community surrounding it. I think that provides way too much of a safety net, if you are stumped by a problem and it only takes you 5 minutes to find a solution on Google then you are going to solve your problem but not benefit from the experience of trying lots of wrong things. Also everyone wants something practical they can use later on, but that just makes them more likely to get stuck in a rut, they get attached to the first tool they use, they cling to its idiosyncrasies and never know what else is out there.

So my recommendation is to go to Google Drive and create a new Google Sheets document. The spreadsheet is your canvas. You will need to create a challenge for yourself to make the spreadsheet do something interesting, but here's one to start: write a program that whenever you put an 'x' in one of the cells, your program will draw a dot '.' in the surrounding cells. The first thing you will have to figure out is how to attach code to the spreadsheet. They use a language call Apps Script that is based on Javascript. You will have to learn a bunch of useless things about Apps Script to get your code working, and you will never have a use for that knowledge outside of the Google platform, but you will pick up some skills in the process - or perhaps you will fail miserably. Good luck.

I wish I did, mostly it is just opinion based on experience. A lot of that experience is looking at code actually being used in production and figuring out what it would take to fix bugs / add new features. Deal with enough technical debt and it becomes easier to spot. Working with code written by low cost developers in India or wherever is also a good learning experience.

Now that I look more closely, the third example is really only using objects as a datatype (the objects only have methods and have no properties) which would seem to indicate it is a functional approach, so not really a good example of OO in the first place.

Two minutes into a course on regular expressions and I find this:

if chars[3] == ''

If a character were equal to an empty string then it wouldn't be a character.

Maybe it is supposed to be a silly example?

The first example, processing a csv file and putting the data into a database, isn't really complicated enough for the structure to really matter. The only critical issue with that example is abstracting out file paths and user credentials. Otherwise the task for this example is a straightforward procedure.

The second example is such a clunky programming exercise I would assume it was originally chosen for its didactic value, since there is nothing practical about a coin flipping program.

In the third example, Will takes actual structured code and turns it into a maintenance nightmare. I have seen this type of thinking in a production system, "Hey, let's just turn these nested conditionals into a switch statement with 25 cases." Depending on the lifespan of the project, it can become a complete quagmire. It also tends to propagate itself into other code, since the choice of conditional logic (instead of a collection of objects) here will mean there is no layer of abstraction for other code to take advantage of, and another process, possibly dealing with the exact same collection of meaningless strings, will have to use switch logic as well. Using procedural code here is a decision to choose the option with loads of technical debt.

In the fourth example, Will shows that his procedural approach is better by producing an object oriented design. I am confused how this supports his original thesis that OO code is bad.

It is part of the "rock star programmer" appeal of the profession. Programmers have been in such high demand for so long, it has attracted a lot of inexperienced folks who want to get a foot in the door. If you want to be a literal rock star, you have to already know how to play your instrument, you can't go in all like "Well I studied music theory for three years and I've been playing the guitar for 3 months" and expect to get recognition for your knowledge. You can't want to be a rock star, you have to simply be a rock star, and of course some people are better at assuming this attitude than others. You can't be willing to learn a new framework on the job, you have to know the framework, even if that just means you've been reading a bunch of blogs can make smart remarks about the latest beta features - "I am really looking forward to dynamic threading in the next release, it is going to make things so much easier!"

Also I find it strange that people now place an emphasis on the difference between OOP and procedural programming. They are orthogonal to each other. Declarative versus procedural is more meaningful.

The conclusion - "we have evidence of bias against women" - is a bit strange, and should really be evidence of a bias against outsiders of known gender. As for the theory of survivorship bias, that seems pretty clear. Considering that males outnumber females by an order of magnitude, there is far greater competition between the males. More competition means even the most skilled programmers have to withstand peer scrutiny, and many of those peers are, quite frankly, retarded monkeys.

These are all largely procedural programming languages.

1. Don't repeat yourself

-1. Don't optimize prematurely. Abstraction to save five single lines of repeated code in two files might seem like a good idea, but it might also hide important information and made the code harder to understand.

7. Follow the boy scout rule

-7. No good deed goes unpunished. If you disturb something that doesn't belong to you, be prepared to deal with the consequences tomorrow, or next week, or two years from now.

So he / she / it is quitting but they are still going to maintain their code. They are abandoning the community but will continue to use free open source software. And they are doing this because they don't like a variable name. I give this rage quit 1/2 star out of 5.

This post is so short, the case against dynamic typing is basically "Because it is bad." Surely someone could present a specific case showing the problems of dynamic typing where static typing is the clear winner.

Ditch the framework and try rolling your own set of tools for publishing content to a site. At the very least you will get some insight as to why Django is structured the way it is, and if you are lucky you will achieve satori. Give yourself from 6 months to 5 years to accomplish this.

Was one of the trends "Present textual information using excessively large (1000px by 7001px) JPEGs"? Added bonus: include URLs in the graphic copy.

If you look at the archives for Project Euler you will find ten year old programs that had to be written with care. Now people come along and solve the problems using some Python library and are so proud when it only takes a few seconds for the program to run. I can understand not wanting to write your own library to calculate prime numbers, but there is a difference in quality between knowing how to use a library versus being able to write a library.

Group theory is important to cryptography and stochastic problems, and understanding overflow and underflow issues (one of the largest classes of software vulnerability).

Combinatorics and probability are critical for making a process efficient. Computability teaches you that infinite loops are a constant danger.

Linear algebra has a very clear purpose in graphics programming. Geometry, as a high school level subject, is a foundation for other branches of mathematics.

Regex is far more complicated than Algebra I.