In university, I learned it to improve my understanding of computer architecture: How exactly does a CPU compute things? How does the CPU interact with the different types of memory, and what are the performance implications?
It's helpful for writing compilers, particularly with optimization.
Enthusiasts enjoy the challenge and efficiency.
Some environments lack compilers and therefore require knowledge of Assembler.
Some say knowing Assembler guides writing more efficient code. For a low-level language like C, that's probably true, at least on a case-by-case basis. For higher-level languages, perhaps less so.
IMO Assembler isn't especially complex, it's just granular; a very tiny tool, best used for tiny jobs.
🇳🇱
@Full_marx Because aside from its usefullness in special situations it is also extremely vital to ones own understanding and skills as a programmer IMO.
@Full_marx Learning assembly is not hard. Writing it isn't hard either. Reading - is where it all falls apart.
You eagerly learn it, you proudly write the largest program that can fit in your head with it, and the next day you can't read what you wrote. You walk away with some key insights on fundamentals of programming and usefulness of higher level languages, without even realising it.
I’m thinking I’ll follow the following sequence in my journey into low level system.
—Assembly (learn for fundamentals, not for production)
—C (learn for a higher level understanding, not for production)
—Rust (learn it, and build with it)
Do you see any issues I might run into?
This way if I feel I wanna switch I can just switch to C++ when I reach the rust stage.
@Full_marx
GooD gameplan. Id through in haskell around the rust stage. Its a compiled language but functional which is good to learn too. Also C++ should probably be in there too imo. Need some OO.
Functional, procedural, OO, and assembly are the 4 areas to master IMO
I love the idea of functional programming.
It reminds me if that movie Inception.
Functions calling themselves from within themselves.
For a complete beginner I would recommend starting with basics of C/C++, and then seeing for themselves if they want to go down or up, but if you have prior experience then you know better what interests you.
For rust, I feel like some C++ concepts(RAII, const correctness, value/reference semantics, smart pointers) are a natural context, but as you said you can always switch if it feels too "out of nowhere".
@togs That was an excellent post, well done. 
Assembly programming is hardware specific, and therefore much more detailed, and time consuming, specially if you have to support different system configurations.
I remember enjoying the elegance and speed of some programs I used very frequently in earlier, command line intensive days. Some were at least partially written in Assembler, at least the most critical parts, and it showed a competent and knowledgeable developer behind it. Kudos to them.
I have been out of doing programming for a long time, my first language was Fortran, in first year Engineering, and I really enjoyed the new experience of having access to a computer and learning about it. These were the days of Mainframes, my first system was a Burroughs 5500 I believe. One of those that seemed a Cathedral of Computing, with a huge room, tons of air conditioning, and a priesthood to keep things running.
We noobies approached with reverent respect, handed in our jobs for processing, and waited to see the result.
Analog days in that sense - my assignment was written in pencil and paper, I had to understand and believe each step was correct and would result on what I needed at the end.
I would write the code line by line on paper, parse and interpret it in my mind, and if it looked correct, then go on and prepare to take it in for processing.
We students did not have access to a terminal, but brought jobs in as decks of 80 column wide cards. I usually would prepare my own, finding an IBM punch machine in a quieter department (Physics usually).
Handed in the deck, and waited for the processing. You could tell things were looking good even there, by the way the card reader took your stack.
If it read smoothly, no pauses, it looked nice and might not have any errors. If it paused half way, you could expect an error message - in the output, a fan paper printout. Each printout contained at the bottom the cost in US dollars of that processing task, not that we paid for it.
What a difference time has wrought. :)
Forward about 30 years and I was standing and teaching a grade 11 programming class, we used QuickBasic which I thought was wonderful for learning logic, structure, flow, etc.
My students would always be baffled when I gave them a small task, and asked them to sit and write a few lines of code to make it happen. They found that very difficult! :smiley:
Usual type it in, and hit Run on the Qbasic compiler was what they wanted to do, but understanding the logic is much more important.
The concepts you learn, hopefully well, will go forward with you and to new languages which you will probably work with in the future.
I don't know how much you already learned or understand, but I would recommend a higher level language to learn the logic, structures, etc.
At one point in time, I used TurboPascal (early 90s), which was developed specifically for teaching and learning programming.
QBasic, Pascal, are too far back now, but maybe JavaScript, possibly?
sorry for the long post, but it's fun to reminesce. :smiley:
I remember how we used to always compare our programmes to our peers i nteh Math faculty 1st year course. We used Fortran, they used Algol, we all had the same assignments, our profs being from the Math department.
Sometimes one, or the other language "won", with a skinnier deck of cards showing less steps, tighter code. On the next assignment it might change, as each language had its strong points.
Fortran is Formula Translation, and was created specially for Science and Engineering. ALGOL was an acronym too, I am not sure of the wording.
At that time (mid 70s), COBOL was the most widepread language in business, having been created for that kind of task.
Funny fact related to what Doug mentioned -- when Unix was first created, it was from scratch, on paper, and the first program they wrote, the foundation for the whole system building -- was an Assembler, which was punched on paper tape, and read to input into the DEC PDP mini computer that they had got access to.
I love History in general, and Computing History is fascinating.
Read this last night, but was too sleepy and didn't want to post a half assed reply.
I have heard of these machines, mostly in videos and movies. And I'm also familiar with the punch card routine.
What a time, where you had to get in an actual physical line to have your turn at the machine.
An age where where computers had humans working inside them, like task managers.
A point in our time where renting a computer for a few hours was considered unprecedented access to technology.
I think it was in a lecture by Linus, where he said that after the Punchcard age, the number of women in programming steeply declined. Never understood why though.
But I must say, I would at least once would like the privilege to "hear" my code being processed. Must have been a great tactile experience.
---------------------------------
We live in age of instant gratification. I for one believe that this has hampered our ability to learn.
If you modify/condition somebody's dopamine circuits you are doing them in for life.You ruin their ability to sit patiently and learn.
The very internet the programmers created is affecting the patience people need to learn programming.
When people stop learning their minds lose all flexibility.
I don't game on my phone. But i look around me and everybody is crushing candy like their life depends on it. its unfathomable.
The amount of time humanity has collectively wasted is a testament that we don't appreciate what we had to do to get to this point in civilisation.
long post, take your time!
@Full_marx @togs Thanks for a great, thoughtful reply - it's important sometimes to take time out and be able to look at something freshly to be able to better understand it.
Yes, it was a wonderful thing. I remember passing by and seeing that big area all dedicated to the machine and it's servers - in this case, the servers were Human beings maintaining it up and running.
Exactly, we would have to come in and stand in a line, outside the data center, until we got near the front and were allowed to step into the data entry room, which was already heavily air conditioned, like the rest of the data center. People who worked there had sweaters on even in mid summer, since it was pretty cool temps.
I discovered that fact of the smooth reading of the deck, non-stop, being a sign of success by myself. Usually took three runs, more or less, as you could only fix one error at a time.
The job was aborted and stopped when it hit the first error. You grabbed the sad printout and left the area, now to read and try to figure out what went wrong.
An interesting thing too, we were very careful with the decks of cards. If you ever dropped them and they got out of order, ooops. Now you need to figure out which one goes where. 😈
There I was, and in awe at that machine. :)
The Apollo program only had small and quite weak computers on board the space ship and lunar module. It's amazing what they accomplished with that.
Memory and storage were precious!
I remember reading a real nice story - part of the Jargon File.
This was "The Story of Mel, a Real Programmer". These date to a time when a hacker was a highly skilled MIT computer scientist, working in low level languages and squeezing the most from anemic systems.
You got to read this -- but do it when you are rested, and enjoy, It's a great piece.
http://foldoc.org/The%20story%20of%20Mel,%20a%20Real%20Programmer
The whole Jargon File is great fun. I remember another story on it called the Magic switch, also wonderful reading.
Here's "A Story about Magic":
http://www.catb.org/jargon/html/magic-story.html
The formatting is not very pretty, but the story is.
The Complete Jargon File is one level above, at :
http://www.catb.org/jargon/html/index.html
or get it on PDF :
http://xy22y.tx0.org/jargon-4.4.7.zip
I fully agree that our attention span is suffering greatly, but it's not because of the Internet per se - but because of the bombardment of distractions, notifications, pop ups, sounds and flashing colour things. It's all very weary.
We do need to step back and cut stimulli when we feel overwhelmed.
Reading is important, and it's becoming harder to be able to concentrate, lay down with a good book and stay there for hours, fully entertained by the story as I have done so many times.
It's not a good thing.
Looking at the bottom of the Story of Mell post, I noticed the attibution, and that alone tells an interesting story.
"[Posted to Usenet by its author, Ed Nather <utastro!nather>, on 1983-05-21]. "
From that, we see it's quite an early post, 1983, and the Usenet already was active.
But what led me to post this extra message was the fun way his net address was noted -- it's what was called a Bang Path.
The Bang being "!", the exclamation mark, and the first part was the System address, "utastro".
Today we use username@machine.domainname which is reversed, and with the '@' symbol instead of the Bang.
Now you know what a Bang Path is. 😏
long post, take your time!
@Full_marx It much more difficult than higher level programming languages, but produces much faster running programs.
Used to be a major advantage when we had less processing power, memory and other resources to waste. Nowadays, unfortunatelly, bloat is more common and feeds the eternal upgrading cycle.