We haven't crossed paths in quite some time. It's nice to hear from you
Thanks. I don't post unless I can say something useful to something - or at least what I think useful was.
I was still here all the time and also watching "your FreeBSD career" from "Windows guy 'no terminal but GUI only for me, thanks!'" over "terminal is great!" to "...I now start programming on C++ and C"
. Very good!
Exemplary.
I'm for sure not the only one loving it to see some one new comes to FreeBSD, being convinced to give it a shot, then digs into it, starts to love it, digging into it even deeper,...finding her/his own path.
But back to topic:
I actually looked at Rust last year and my conclusion is that someone had the idea to turn JavaScript into a compiled programming language. I swear that it is alot like JavaScript
I cannot say anything about that, since I glimpse at Rust by now just very shallowly, and I never learned neither Java nor JavaScript, since without even knowing at least the latter one to me is for programming webpages, and that's not what I'm doing. But there are always similarities between almost all programming languages, since most languages (the serious to take ones, not some experimental or 'joke' languages like e.g.
Brainfuck) are started to do something better the existing ones are bad at or do not provide at all, orientating at what there already is. So of course there are similarities. The heritage tree (second picture down on the right side on
Wikipedia:ALGOL gives a rough idea how it "all started" (not quite true, since there is at least one other tree issued from lisp.) And most of the times somebody presents a new programming language (not seldom self advertised as "now this one will solve all our programming issues - but it's not finished yet; in fact I just started on that..."
) I look at it and think, 'how this look like C again.' There have been many attempts to produce a better C. Most were not really convincing.
But programming languages do not only differ only by their syntax, that's more superficial. You need also to grasp their "philosophy" (for lack of a better word), and if you're not only learning programming languages by pure curiosity but going to be interested in really to do some serious programming - maybe join some open source project, maybe FreeBSD - you also need to learn which programming languages are used in which projects.
Could go more into details here, but there are many others by far way more experienced programmers on a professional level here could tell you better than me.
About version control there are some, and you better take at least a closer look yourself at their introduction, to understand what they are doing and what they are for. The most popular and by far most used one is of course
git
Like a few others personally I use
SVN, which maybe a good start for get into versioning control at all, because it's less complex than git, but it needs a central server running the repo. And if you're going to collaborate one day with others it's almost certain you need to use git anyway.
But there are others of course, like Fossil or Mercurial, which I do have no experience at all with, but others here do.
Anyway, reading for yourself a bit about versioning control enlightens you more than I write long posts.
However
currently work with the file named "mymath49.c" so yes, i save versions anytime that i make a change to the software.
That's exactly the point you better start using a VCS. This suggests you already have at least 49 files somewhere somehow stored. With a versioning control system instead you would have only mymath.c. The VCS stores all the former versions for you, provides the possibility to jump between any version anytime, and gives you a list of which versions there are, and what their core point in difference is (see writing comments at the end of this post.)
As long as you only work on single files, for doing a beginners class or just writing a very small experimental program, there is no problem. But once you say 'I could (re)use this program or that function a bit modified for something else', the chaos starts. Having programs consisting of more than one file, start creating libraries, and at the latest, when you are not working alone on some files anymore, trying to have different versions/modifications/derivates/states all as copies of files - some are in a useful state, some may be useful later for something else, but most are just in some in between "solved something but not really useful yet" state... to be "organized" in several directories ... this "system" reveals quickly its limits: chaos is predetermined.
When there is a total mess, and it's just a question of time when there will be chaos, you are confronted with the choice what to do now - happened to myself many years ago: Stop frustrated with programming at all, what was a pity, because you had so much fun and the problem ain't lacking of programming skills, but because in the lack of organization. Or to start all over again, or bite the bullet, and clean up the mess. Neither way is nice. And your programs don't have to become large to get there.
So better learn and start ASAP how to organize and prevent the mess by using a versioning control system.
Versioning Control System: learn what they are for, what they do, use the rich expertise of this forums to get more input, help and other points of view than just by me.
Then pick one, learn its basic usage, and integrate it as soon as possible as a part of your programming processes, because it is part of any serious programming beyond beginners classes.
Learning to use a VCS is not done alone by learning the usage of its UI. You need to learn at least two things you cannot learn by books or any other text or explanation by others:
When is a change worth to become a commit. And write short but catchy commit comments, so to see later quickly which was the core point of which version. This you can only learn by doing it yourself.
I'm pretty sure you will be very glad if you started on using VCS soon.
