Welcome to the Parallax Discussion Forums, sign-up to participate.
I keep hearing this refrain about "poor programming" now a days.
On the other hand we know that people like Google have invested a lot in creating efficient, optimized, programming environments. Like Clang/LLVM for example. There are some very smart and efficiency obsessed guys working on such things. The Chrome browser, for example, may use a ton of memory but it would be much bigger and slower if they had not put that effort in.
So where does the "bloat" come from? Let's look at a simple example, the "Hello World" program:
int main (int argc, char* argv)
What is wrong with that? Can probably be written in a few tens of bytes in assembler.
Well, the "Hello World!" probably needs to be in Unicode. Which already requires a huge pile of "bloat" to handle.
Then of course it needs internationalizing, that "Hello World!" should come out in whatever the users language is. Another pile of bloat.
Then of course nobody uses the command line anymore so that needs a GUI Window to open to display the message. Another pile of bloat.
Well, with that GUI you need to support all kinds of fonts, anti-aliasing etc, etc. More bloat.
Now, you might need this program to work on multiple platforms, Linux, Mac, Windows at least. Not to mention iOS and Android. That means using a cross platform GUI toolkit. Another pile of bloat.
It's hopeless. But every byte of that bloat is required.
WHAT ON EARTH???
Heater. wrote: »
Assuming you already have a project started in some directory and assuming you have git installed on your machine I would proceed like this:
1) Create a git repository out of your existing code.
$ cd myProject
$ git init
That will ask a few questions, mostly I just hit "return" and accept the defaults.
2) Add your code to the git repository:
$ git add thisFile otherFile thisDirectory otherDirectory ...
Or you can just do:
$ git add *
That will add everything. But that may add a lot of binaries and other stuff which are not source but created from the source, which should perhaps not be in the repo.
At this point you could still be changing or creating new files and "git add" them as you like.
3) At this point your code is not actually committed to the repo. You could hack it some more and "git add" it again. When you want to commit it as an actual version you have to use "git commit"
$ git commit -m "My initial git commit"
Now you have a version in the git repo. With a message logged describing what your changes were.
4) You can view your log of changes with:
$ git log
5) You can view the status of your repo with:
$ git status
That will tell you what files you have changed or added that are not yet committed. And other useful stuff.
After that, my day to day working is just, edit some source files, do a "git add" when they look good. Then "git commit". Job done.
Then you might want to put your repo int gighub.com or bitbucket.com for safekeeping and possible sharing. I suggest just signing up for github and following their very clear instructions on how to create a new github repo and get your code into it.
When you have a github or bitbucket repo up then you can do the following:
$ git push
Will push commited changes from your machine to the github repo.
$ git pull
Will pull changes from the github repo to your local machine.
This push/pull thing is neat because you may find yourself hacking your code on different PC's here and there, as I often do. No propblem, push changes from one machine, pull them to another.
Then there is cloning, as in:
$ git clone https://github.com/ucb-bar/riscv-sodor.git
Which is good if your machine does not have the repo yet, it just fetches the repo you want.
Personally, as a beginner I would advise ignoring all talk or branching, merging, rebasing etc. Why?
Because, an important thing to realize is that the repo on your machine, and the one on github are exactly equivalent. There is no "master".
That means that when you hack code on your machine and commit it, it is a branch from github or wherever it came from. Until you push your changes.
If you find you have messed up your branch, you can always just delete the whole directory and "git clone" it back again.
And, well, all that branching, merging, rebasing stuff is complex. I almost never need it.
Heater. wrote: »
Yes it is.
My simple idea is that when introducing beginners to git, is to not talk about branching and merging, add --patch, rebasing and so on. That just confuses everyone. Useful when you need it but most of the time, on one man or with a few collaborators on github etc, not needed.
Heater. wrote: »
I find what you are suggesting with "add --patch" somewhat disturbing. Because:
1) The code you are committing is not actually the code you tested. It's not uncommon that bugs get masked by the introduction of printfs and other debug checks.
But better yet is to remember to just "add" and "commit" for every little fix.
Then you don't have to mess around with "add --patch".
msrobots wrote: »
...just need to write it down. Still independent of the language to use, mostly.
Genetix wrote: »
Just like in writing for something that is short and simple a formal outline isn't required though highly recommended.
I've done many writing assignments, essay question, and small programs with the outline in my head.
On large projects I've had to write things down especially the portions that I need to research or figure out.
One trick I have for hard problems that I can't solve is I go off and do something else and sooner or later a solution will come to me.
Be sure it's something that is fun or relaxing so your mind is free.
Heater. wrote: »
No I didn't. I'm too old to not loath and detest the Smurfs.