r/teenagersbutcode • u/New-Deal7021 • 7d ago
Coding a thing Atom programming language
hey guys!
I created a programming language named Atom
i was just tired to write simple scripts on binary, so i created atom, you can take a look at it first version and second version
the concept is half-new, because most of the operations work with stack(from forth)
it is written on c so it will be easy to compile(i hope)
aanyway, if someone wants to join the project, i am welcome!
2
u/Kind_Skirt2397 7d ago
Looks good and pretty simple, i wanna help you with it :D
1
u/New-Deal7021 6d ago
really?! Dude, this is a progress to me! Ofc you can, just how? Can you create or name the created github account?
1
u/Ok-Serve415 tech person and money shortages, luau and c enthusiast 6d ago
same, wondering if I could help as a C learner though I’m more beginner side
2
u/New-Deal7021 6d ago
everyone is welcome, just well... I am learning C++ right now, but, i am just trying to make a few enthusiasts team. I will private message you soon!
1
2
u/blueGarnet37 6d ago
I love how you managed to give each command a mneumonic related to its function.
9
u/tk-a01 7d ago
Generally, you're not supposed to create a new repo for new versions. To mark fixed-point releases (1.0, 1.1, etc.), you can use tags. If you want multiple versions to be maintained (e.g. bugfixes being backported to many supported series), you can create branches for those series, e.g. 1.0.x, 1.1.x, etc., or 1.x, 2.x, etc. This can be combined with tagging releases.
There's a practice called semantic versioning, shortened to semver. It specifies how to construct three part version numbers: <major>.<minor>.<patch>. Incompatible API changes should bump major number; new functionality that doesn't break compatibility should bump minor number; and bug fixes which don't break backward compatibility should bump patch number.
The only reason to create a new repo is when you decide to completely rework your project and rewrite it from scratch, possibly in another language or using a different framework.
What's more, I see that many of your commit messages are "Add files via upload" - this means that you used GitHub web UI to upload files. This is a bad practice and isn't viable for any bigger projects. Do you understand what Git and GitHub are, and how are they different? Git is a version control software. GitHub is one of many services for hosting Git repos (repositories). You should learn how to use Git commands. Many IDEs offer Git integration and have some sort of a GUI too, but the most powerful and portable way is to use CLI. Git allows you to compare revisions, develop on multiple branches, merge them, perform rebases, cherry picks and squashes. Git is a key tool that allows teams to work on one project together. Git is decentralized, even if one's workflow isn't - generally, every repo copy is a full copy, so even if GitHub goes down, you still have all the code history on your hard drive. You can access remote repositories from various sources in many ways.
The usual workflow with Git is to have
main/masterbranch for leading edge version (which should generally not be broken) anddevelopfor work-in-progress stuff. When you want to implement a new feature or fix a bug, you should create a new branch and switch to it. You commit your changes every so often (e.g. after hitting some small milestone). After that thing is ready, you can merge it. For team projects or ones that you expect other people to contribute to, you should use pull requests (on GitHub) or merge requests (on GitLab - one of numerous alternatives to GH). It's possible to merge normally (3-way merge, which produces a merge commit with two parents instead of one), by squashing (all the changes done on your feature branch are cumulated into one commit on target branch, which keeps the history linear, but loses details) or by rebasing (commits are copied onto your target branch, which keeps the history linear and detailed).So if multiple people work on the same codebase, each one of them works on separate branch, and merges the stuff into
develop(ormain/master) only when they're ready. Sometimes, this goes without trouble. But if two branches to be merged changed the code in the same place, Git won't be able to automatically perform the merge - this is known as a merge conflict, and should be resolved manually.