I mean with all the "unknown and weird" difficulty behind the parsing, compiling and generating of the compiler, pre-processor, other programs and step, etc., isn't it nicer to know EXACTLY what you did, what's going on and what's what in your program?
Not to sound crazy or trolly, but actually learning machine language or Assembly is definitely more favoring to programmers in the long run. Sure, #include <iostream> using namespace std; int main(){cout << "Hello, boring old high-level language!"; cin.get();} is definitely easier, but it's just so gloomy and dull after you realize how far you are from direct hardware access and control.
It's like ... here's an example... I want to go see a basketball game. C++ is like sitting on the 18th row about 200 feet away from the court. Assembly is like sitting on the first row only 15 feet from the center of the court. The court itself is the processor...
Understand?
I feel that more programmers should dig deeper into what they're "really doing" rather than just tire themselves out with high-level lack of control, confusion on "APIs work", which is only 100 feet away from the game.
It's a long walk, but for what? You can't actually see the game clearly, can you? And even with all of these "tools", nothing beats sitting right in front of the players and witnessing it up close and direct.
It just, to me, seems like a big mess of disorder and tirade attempts for people to torture themselves learning these APIs, high-level languages, etc., when low-level is more right on to things and there's no memorizing/references of thousands of things that you don't even really know what they do 100%.
...I came to see a basketball game with binoculars on the last row. I can see it, but the people in the front are really witnessing the feel of it and getting more excitement, thrill and just full brain-eye accomplishment.
I'm sorry if this comes off in a bad way, it's just an opinion.
I had a friend who had this special ability for cracking. He got to a point to be able to remember quite a few machine bytecodes and know what they meant.
Technically speaking, machine code is bits. LOTS of them. I think most humans lack (still) enough short-term memory to remember such long sequences. I think there was a standard limit for that but I don't remember.
I know machine code. So what? I made a small scrollable text viewer/syntax highlighter program with assembly (well, that's not really machine code I admit it). It was fun. So what? I wouldn't make ""complex"" games/applications with it.
Stop trolling and start coding. You haven't coded too much yet, It's obvious. That means your opinion isn't worth JACK SHIT:
Learning at least a bit of Assembly = YES.
Learning machine code = useless IMHO.
Assembly can really help you out if you want to optimize your application.
If you wrote your game or application in VS you can take a look at the dissembly of your program.
The dissembly is your program in assembly, after the VS compiler did all his optimizations (Maybe that's also possible with other IDEs but I'm not sure about that), if you know at least a bit of Assembly you can figure out what the compiler did optimize and -maybe- if the compiler screwed up optimization (e.g. forced inlining etc.)
On the off-chance that this is actually a real opinion and not trolling like the last time:
Yes, we all go through that phase at some point. And while an understanding of machine code and how it works (as well as theoretical constructs like Turing machines and primitive recursive functions) is certainly something a programmer should be aware of, we also learn (usually the hard way) that choosing the right tool for the job is important. Machine code is seldom the right tool for any non-trivial job that does not involve work in an extremely limited or extremely performance critical system.
To stay in the metaphor: for the common project, using machine language is like watching a basketball game by analyzing the magnetic pattern of a video tape of the game by hand. It can be done, it's just neither fun nor efficient. Just very, very tedious.
[color="#1C2837"]I think you should know to use the right tool and the right skill set for the right job. [/quote]
I can make any job complete as long as I have an OS and machine code. I can directly access hardware myself, I don't need "third-party" crap except what I already came with in my licensed-end user agreement with my computer.
I don't need any damned "tools"... Do you people understand that? Tools are not for me!
You people will never get the fulfillment of creativity... This is comparing to painting.
Painting on a canvas, to be precise.
Why paint on a canvas if you don't know the application of force to the canvas, what the canvas is made of, how you can make it and make sure you've created the perfect canvas for the job, while assuring correct depth, application of force to the canvas from a pivoted angle, direction, etc.?
BUT NO... High-level programming is too easy, yeah... NOT! It's harder...
Think about it... Go read a DirectX source code for a small racing game. 3,000-7,000 LINES OF CODE THAT'S UTTERLY, SICKLY AND PSYCHOTICALLY DIFFICULT TO EVEN UNDERSTAND OR MAINTAIN!
Compare that to: 0 and 1. Who do you think wins, besides just ease and straight-up logic?
At the tiring and sad rate people go for "these days" in programming, I'm going to have to come down to having to make my own hardware.
It's like ... here's an example... I want to go see a basketball game. C++ is like sitting on the 18th row about 200 feet away from the court. Assembly is like sitting on the first row only 15 feet from the center of the court. The court itself is the processor...
Understand?
It's a long walk, but for what? You can't actually see the game clearly, can you? And even with all of these "tools", nothing beats sitting right in front of the players and witnessing it up close and direct.
Here's another example. I want to build shit. C++ is like sitting up on the 18th floor of an office building, drawing out awesome blueprints for a bridge that's being built over a massive fucking river, and then driving home in a Porsche that you designed. Assembly is like being one of the poor dirty cash-in-hand workers getting paid a buck fifty an hour to haul bags of cement to build a bridge, but who'll never actually get to see the magnificence of it's completion because they're about to fall to their death in their unsafe work environment and never amount to anything.
Understand?
You can't actually build a bridge, can you? Even with your sandpit and little sand-bridges, nothing meats standing right there in front of that massive river-conquering fucker of a bridge that you built.
You people will never get the fulfillment of creativity... This is comparing to painting.
Painting on a canvas, to be precise.
If you want the painting analogy to work, I would suggest making your own brushes, making your own canvas (neither with bought ingredient, go out and hunt some furry animals and start weaving your home-grown canvas) and grinding your own paints instead.
I can directly access hardware myself, I don't need "third-party" crap except what I already came with in my licensed-end user agreement with my computer.
What? Since when does a modern operating system allow you direct access to hardware? That's handled by hardware drivers, regardless of if your program was written in C++ or x86 assembler. As far as needing "third-party crap", I don't need anything but what came with my computer to complete a task using C or C++. I use linux and GCC comes standard. Did your operating system not come with a compiler? If not, I'm surprised it came with an assembler.
I don't need any damned "tools"... Do you people understand that? Tools are not for me!
You people will never get the fulfillment of creativity... This is comparing to painting.
You are an internet troll. I have my doubts that you can write anything at all, much less a work of art in assembly.
I'm not going to quote the rest of your post because you are just rambling incoherently.
