Every time I learn a new language, I always make a simple calculator.

It exercises calling functions, mathematical objects, and more than you'd expect. If I can make a good calculator, I consider the idea that I can actually work with the language.

As a person who uses Python nearly every day, I understand why someone wouldn't want to get into it...

But it's DEFINITELY something that you're (probably) going to use more than any other language, if you're really going to get into programming. It's good for small scripting and quick actions and hardware-level things, especially with something like an rPi... and that's GREAT for modular jobs.

What is this... An ad for another site? What are you showing us, OP?

Python, being an interpreted language, is nice because, if I just want a sensor reading, or to test if something's working, or general hardawre-level things, I don't have to write a script, declare a function, save and compile, then run it all. I can just type in a line (or two) and get a reading. This is compounded moreso when libraries exist for your hardware, and you don't have to write your own C libraries.

Hardware-level is always C.

Not true... Let's use a common example, we should all be familiar with: GPIO. The Raspberry Pi, Beaglebone, Odroid, and other microcomputers are easier to code in Python than C... Don't believe me? Try to code a blinking LED, for the rPi, in C... Then try it in Python.

Python's a bigger pain in the ass, but it's a WORLD faster because the hardware libraries already exist, unlike for C.

You must use Python a lot... but, you know, as volatile as Python is, I'm sure they'll add another way of doing this, remove all of these options, and make one of the ones you stated do something COMPLETELY different... like they did with raw_input and input.

It's convenient, and I use it often, but I can't say that I enjoy using it. I'm always on my guard, about what I'd typing, because (like I said) it's always different among versions. I know each language has to grow and expand, but some of the leaps for Python go WAY beyond just that... which is why I call it volatile. Some of the changes they have made make no sense, are frustrating, and only serve to break code for previous versions... for the life of me, I can't figure out the input-tango they did, or why they did it.

I usually default to Python, when I'm working with hardware-level stuff, or a small sketch that I need to hammer out in a minute, or two, but I still hate it all the same...

Yeah, I hate how volatile it is... changing syntax, every version, for no good reason. Makes old code broken, just because. Print syntax, read syntax, and any other basic syntax change, from one version to the next, making writing anything a chore. For instance, you have:

print 'Hello world.'

print "Hello world."

print("Hello wold.")

and only one of those is right, or all of them are right... depending on which Python version you're using. Why would you do this to me, Python?

This volatility means that certain projects, written with certain code, can only be run correctly with certain versions of Python. So, not only do you have to standardize your code, depending on what you want to do, and how you want to do it, but your sketches HAVE to be run is a standardized version of Python. That's why YouTube is written with Python2.7-something and Python is now on v3.5.2! Google hasn't made the version changes, because of this volatility.

Then there's the space/tab mismatch, which we're talking about here. I do pretty well, staying away from it as an individual, but it always comes around and bites me in the ass in group projects. Nothing chews me more than having invisible characters, somewhere in your code, stop your code from working... even though both sets of invisible characters are acceptable!

I hate the language. It's convenient, with all of its libraries and hardware-level access, but it's generally a pain in the ass. If Python disappeared tomorrow, I'd be a happy man.

Spaces. I've set VIM up to automatically replace a TAB-press with four spaces, so I don't bork up my Python scripting... god, I hate Python...

I wonder if I could create a "safe space" language for these idiots to use. That way they migrate to their protective spaces and leave the REAL coders to their work.

They can go over to this new language, step on each other's toes for the most trivial, asinine, and childish bullshit. They can stay there, hinder each other from being productive as they argue about "microaggressions," and we can all remain productive in our preferred languages.

If we market this new "safe language" as being moderated ONLY to promote "equality," I bet they'll jump on that bandwagon faster than you can blink!

It's win-win, if you ask me.

Repository is a term for the collection of code you have. Think of a folder on your Desktop full of text files... that folder would be called a repository. A repository also logs edits and versions.

These edits are uploaded to the repository as commits, or saves. Since you're not just saving your edited files, but you're also documenting the time, date, and versions of your edits, they're called commits. A good commit will have a short description of what was changed, as well.

Then a branch is a type of fork... Look at a table fork (which you eat with). The single handle "branches" out into the forked prongs. This is usually how code works. Let's say you and I both look at the Voat code and decide we want to change it, but can't agree with what changes we want to make... we'll fork it: branch the code so that there are now two parallel projects, being coded simultaneously, working independent of each other... like the prongs of a fork. Each fork has a common source, but ultimately becomes a different project.

Forks/branches can be consolidated into a final project, implementing only the best of each fork, but this can only be done if commits are documented well, so that each part of the code can be isolated... taking us full-circle. If I document what I did for my fork with appropriate commits, and you do the same, we can condense back into a singular Voat by looking at the commits and changes.

Yeah, I just got to level 3 (where you have to pay). That's where I stopped. It's an interesting concept, bit I'm not paying money for something that's well-documented.

But it seems neat for young newbies.

I don't like how I can't use numbers. For instance, 5h will move your five spaces to the left. It's one of the most powerful features of VIM, and it can be used with just about (I use this conditional, even though I can't think of anything it doesn't work with) everything!

Otherwise, it looks like a neat little game. I've already wasted 5-10 minutes on it!

I actually came to say the opposite. It's going to make me sound like a rachety old man, but...

Now that this kind of storage and memory is cheap and available, many programmers have lost the ability to make elegant programming tricks like here.

When I was a kid, computer and console games were packed as tight as humanly possible, like in the article. Now, a lot of games and programs are bloated for the sheer fact that they can be.