On Tuesday, June 7, 2022 at 11:09:13 AM UTC-7, Jeff Blakeney wrote:
> Perhaps *you* should stop whining because someone else doesn't agree
> with your opinion?
Everyone is free to share their opinion on the internet. If you don't like it, move on.
> Kent doesn't like or want to use GitHub and that is
> his opinion and choice.
And water is wet.
> Trying to insult him for it makes you look
> petty and mean
Where did I insult him? Did you miss the emoticons?
> You could have just posted what you think are the
> benefits of it instead of talking down to those who don't agree with you.
I *did* list the benefits. Do you want them listed *again?*
> I too don't see the need for such a system as I have never been involved
> in large, collaborative programming projects.
SCM are handy even if you are only on a 1 person project. Yes, there is some overhead, but that is minor to the benefits it provides.
Amateur programmers tend to make excuses for avoiding SCM. i.e. They think "backup folders" are a way a to "manage" version control.
Take CI/CD. Yes, this is a PITA to setup. For small toy projects it is a complete waste of time but eventually you reach a point of code complexity where you NEED automatic testing of code coverage and NEED to know when a build breaks. You want tools and a system that let you incorporate new features of project management. GitHub has done a pretty good with this.
> I gave on on programming for a career as I really didn't like all the extra overhead people kept adding (I need this one function so I'll add a multi-megabyte library to get it),
100% agree. That is indeed a big problem of Cargo Cult Programming: Including 1 library which includes a 2nd library which includes yet another 3rd library just to use one function that could have been written in less then 20 lines of code. One of the common Crap++ examples I use is pointing out Boost's bloated CRC code. And then people wonder why it takes an hour to compile their code.
Nothing to do with SCM though.
> all the new terms people were coming up with to describe things we already had or already did,
Yes, that is a problem. Programming tends to run in a 20 year cycle where some new hotness is reinvented because some kid didn't understand or even know the name of the old tech.
There are also times where new concepts do get invented and refined. Distributed SCM is one of those times.
Nothing to do with SCM though.
> the cryptic nature of the languages many programmers ended up making the popular choice,
Dumb programmers keep inventing new programming languages (Python, JavaScript, etc.) because they are 1/ too lazy to learn how to use the existing language, 2/ want more syntactic sugar for their pet feature while not understanding the man-years that went into debugging the entire toolchain. Except it is half-baked, tries to be a silver bullet, and ends up being over-complicated, solving some problems and ignoring all the other ones, and you are lucky if you get a functional profiler, let alone debugger. Fad X language gets popular as everyone jumps on the bandwagon. Eventually it gets abandoned as people realize all the old problems are STILL there. Some new Shiny Language Fad Y promises to fix all the old problems and rinse-and-repeat every 10 - 20 years.
Nothing to do with SCM though.
> finding source code that took forever to use because the
> programmer didn't comment it and other issues that I just got tired of
> dealing with.
Far too many programmers (professional and amateur) don't understand:
* Code documents HOW
* Comments document WHY
The lack of comments is a BIG problem in the industry.
The second biggest problem is shitty variable names.
I wish every professional programmer was forced to watch:
Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks
https://www.youtube.com/watch?v=FyCYva9DhsI
This has nothing to do with SCM though.
> I still dabble sometimes but do it my way, not the way
> "modern" programmers do.
There is a HUGE difference between using a modern tool and jumping on the band wagon of fad programming. Most of "modern programming practices" are crap, reinventing solutions that existed previously that were less overengineered.
I used the analogy of git + GitHub being a power tool for a reason. It is a good one.
git + GitHub is just one superior tool (among many.) If you are a professional programmer and aren't using it then you aren't taking the time to understand WHY it exists, WHAT problems it solves, HOW it solves those problems, and how every other SCM is basically crap for versioning of code. The advantages FAR outweigh all of its problems.
The downsides of git are:
* can be complex to learn. I didn't have a problem with it but many think the learning curve is a vertical cliff. i.e. staging area.
* is useless for storing binary data. (See LFS for a workaround/solution.)
* managing multiple branches can be tedious (workspaces is one workaround/solution.)
* not everyone likes the command line (although this is less of an issue since there are numerous GUI front ends)
i.e. For game dev a perfectly reasonable solution is:
* git for code
* svn for binary assets
Good Engineering is being aware of and understanding the tradeoffs for solutions. I've never seen a better solution for SCM then git+GitHub.
Talk and LISTEN to other developers. They will share the same sentiments.
That's my opinion and you are free to ignore it. =P
m