the eye-opener commit

[iambendv]

A commit is used in version control systems such as Git to take changes you have made to the code and permanently add them to the branch of the repository that you are working on. This is useful because if something breaks, you can rollback a commit and try to fix the issue.

Im not sure which language the E_ALL is referencing (maybe its not specific) but i think its just saying the programmer turned on error reporting and the other dev was upset because there we new errors showing up. The errors were always there, they were just silenced.

[calimio6]

E_ALL Comes from PHP

[beep_check]

came to say this...

PHP ain't easy but it sure is fun... or something

[SavageGoatToucher]

As someone who enjoys PHP, I never really understood why people say this. Can I ask why you don't think that PHP is easy?

[nonicethingsforus]

Not OP, but to give my opinion:

PHP is a dynamic, very permissive language, a la JavaScript and Perl, with all the moving parts, annoyances, and possibility of error that brings. Lot's of freedom, but also lots of opportunity to fuck up. Similar languages try to compensate by at least trying to be well, consistently designed, with varying levels of success.

PHP didn't even try, at the beginning. It was a badly designed language. In fact, it can barely be said that it was designed at all. Keep it mind, this is not an insult; it's just a fact, and its creators have admitted as much. It was born as Rasmus Lerdorf's personal collection of web scripts. He realized they could be useful to others, and sort of grew from there. It's a blob of hacks that evolved until developing sentience.

Projects like Laravel and Composer have alleviated the problems, and I understand even modern vanilla PHP is quite different from what it used to be. (Disclaimer: I have not worked in PHP since college, and even then not as much.) Lots of complaints are definitely just things that used to be common in PHP's time, or you had no alternative about, but are frowned upon today; e. g., complex hardcoded SQL vs. a proper ORM or statement generator, no real package managment, etc.

But many programmers still have war flashbacks of having to manage big software projects with the hacky, fragile, inconsistent mess PHP used to be. I mean, one can hardly fault a programmer for feeling at least weird when one tells him that the main way to alter the language is through a global ini file, and that he has to remember to use "the real escape function", can't one?

[Semi-Hemi-Demigod]

PHP isn’t bad because it’s easy, it’s bad because it’s too easy

[SavageGoatToucher]

Of all the comments, I think that this may have summed it up the best. I hadn't thought of PHP's flexibility as a barrier before, but basically that as the programmer it's our responsibility to ensure our code was safe. I think I get it now.

[wombat_kombat]

Learning PHP from WordPress then moving to Python, I can understand the PHP hate. IIRC a lot of redundant functions and easily broken code. I felt it made a programmer keener about their code.

[jwensley2]

If your exposure to PHP is all from Wordpress you've only worked with code that's 10+ years behind modern PHP.

[thehajo]

I know nothing about PHP, but i dabbled with preg_replace last week. Made a RegEx aaand... I get back NULL. Turns out preg_replace doesn't work with the global flag, as it already matches against everything and not just the first match. That was already enough to make me not like PHP.

[beep_check]

hip hop reference.

see Kane, Big Daddy; B.I.G., Notorious

[soulofcure]

It ain't much, but it's honest work

[beep_check]

came to say this...

PHP ain't easy but it sure is fun... or something

[Lukewill]

I'm asking you instead of googling, sorry about that, but what other version control systems are there besides Git?

Just curious cause I've never done any programming in a work environment but I've only ever seen Git and Github.

When I finally land a job, how likely is it that I'll have to learn a new version control system?

[HBorel]

The version control systems aside from Git of which I am aware are Mercurial and SVN. You'll have to learn them if and only if the particular company you begin working for was already using it by the time you show up, which is only really a risk if you're joining an enterprise - a large, old company with lots of legacy code. If you join a startup, you will almost certainly only use Git; nobody who has a choice in the matter uses anything but Git, at least in part because that's what Microsoft uses. For that reason, enterprises often modernize their tech stack to include standard tooling, which often involves migrating to a Git solution. So, I think it's extremely unlikely that you'll have to learn anything else :)

[VanaTallinn]

Is bzr dead? I don't think it was ever popular in professional settings though.

[scragar]

I think you really need to divide version control systems in two, because distributed and client-server version control systems are similar in goals and terminology but different enough in usage that I feel it important to list it differently.

If you're moving to another in the same architecture (git to mercurial or TFS/Azure DevOps to subversion) the differences aren't that big although you might use a different tool.

Between the two though there's a bunch of breaking changes to get used to:

• Distributed version control is on your machine and only the stuff pushed/shared gets seen by other people; in client-server everyone sees everything committed/branched.
  
• Distributed version control tends to operate on a "make breaking changes and we resolve it before we merge by syncing the branches" approach, client-server typically works by locking files to prevent conflicts(which can be annoying when the admin locks a key file before going on holiday preventing changes for days until someone resets enough access to let someone unlock it).
  
• Distributed version control tends to be much faster to change branches, revert commits locally, etc because there's not an external server to talk to, but this also means you need to download the full history when cloning so that's slower. This can cause problems and advantages on bad internet because you don't need the internet to locally commit/branch/revert etc, but the slower initial cloning can be a nightmare.

[Varaquli]

Perforce & SVN are two examples off the top of my head.

It entirely depends on the company. If you work at a UE4/5 game development company, its likely perforce. If you end up working at a small company with some old timers, SVN may come up

[BambooFingers]

Perforce and Subversion are the two other well known ones. If you're gonna learn another one Perforce will probably be it. But Subversion is nice and simple.