75 replies to this topic

[AndyWonHarglesis]

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.

[owl]

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.

[szecs]

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:

[FelixK15]

Machine code != Assembly

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.)

[BitMaster]

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.

[Tachikoma]

I think all assembly programmers should know everything about ASIC design and electronics engineering.

I think all ASIC designers should know everything about physics.

No.

I think you should know to use the right tool and the right skill set for the right job.

[AndyWonHarglesis]

I think you should know to use the right tool and the right skill set for the right job.

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.

[Hodgman]

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.

[BitMaster]

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.

[lpcstr]

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.

[Hodgman]

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?

Again, you're just telling us that you suck at programming. Go cry, emo kid.

If coding in machine bits is easier, you'll be able to tell me what this code does, right?
1100101111100010110010101000001011001011111000101101101010111110
1111110100110010000110100110001101010010011011110001101001101101
1111111101100100010100100001011001010001100110000100001101001001
1111010101000001001101010101000101000110010100000000000011011111

If you translated those 7,000 lines of D3D-using high-level code into plain assembly (and also replicated D3D's functionality yourself), how many lines of psychotic assembly would you end up with?

[AndyWonHarglesis]

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.

O.o

Someone's upset because of me just being honest! >.<

Here's the clearest example possible ... C++ is downloading an IDE to swallow up all of your RAM when compiling half a gigabyte of DirectX API files that do shit for you except hurt your head and offer little control without lots of headache and torture.

On top of that, we forgot the "size" issues... Commercials game take usually over 1GB of RAM to run on most modern OS. Why build in high-level, memory hogging and mentally pincing atmospheres? Exactly!

Build from the ground up only by using what IS necessary and leaving all the bulk and trash of APIs and such where they belong: in the trash.

It is a KNOWN fact that Assembly language programs usually take about 1/2 the RAM of high-level work/programs. Look it up.

If I did my lower work in Assembly, yeah, my work'd take a heck of a lot longer than yours would in your "higher languages". But break down the code and you'll see that my lower-level work is not only better organized, will have better performance regarding speed of the program, the feel of actually using building blocks rather than third-party headaches and not killing my CPU with 6GB of RAM on some crappy high-level program with tons of bulk and garbage that Assembly could've cut it down to less than half of that.

If coding in machine bits is easier, you'll be able to tell me what this code does, right? 10001010011011001010110010001100010010100110110010101010100000110111111101001011111110110110101111010100100010101100011010001001010010001000110001000110101000100110101000101100011010101000101100010100110101001000010110010100010101001001100100010101000111

Very vague and blatant. Just spewing out 0s and 1s doesn't show anything other than the fact that you're letting your anger get the best of you here. And insulting me is just pathetic... I never insulted you once. Childish.

Anyhoo, if you give me about 4 hours and some instruction sets, I could find out what that would do exactly.

But, since it's just meaningless code you spewed out, you probably don't even care, so yeah... why bother with you?

To you they're just "bits". To me they're the building blocks of everything. I use them with knowledge, not spew them with hostile emotions.

Once you learn that these "bits" are everything, you'll see that coding directly to and from them is what REALLY is efficient and beneficial in the end.

High-level does NOT and WILL NOT have the same capabilities or control that Assembly or machine language has. Deal with it.

[lpcstr]

C is not a high level language. If you are as smart as you claim, then you should be able to "compile" a C program in your head, as most lines of code compile into just a few instructions each. Linus Torvalds calls C "portable assembly", which brings up one of the largest points for non-assembly languages: portability. The only thing worse than having to program an operating system, game or database in assembly would be having to write it multiple times.

[lpcstr]

High-level does NOT and WILL NOT have the same capabilities or control that Assembly or machine language has. Deal with it.

Give multiple examples of common scenarios that display this "lack of control."

[Hodgman]

O.o Someone's upset because of me just being honest! >.<

I'm not angry -- I'm trying to emphasise how fucking awesome that bridge is! It's ridiculously fucking cool! If I enjoy building shit (which you should associate with, being a painter and all), you'd know how awesome it is to complete a wonderful creation.

Seriously, how many bridges have you built? And by that I mean how many games have you finished?

On top of that, we forgot the "size" issues... Commercials game take usually over 1GB of RAM to run on most modern OS. Why build in high-level, memory hogging and mentally pincing atmospheres? Exactly!
Build from the ground up only by using what IS necessary and leaving all the bulk and trash of APIs and such where they belong: in the trash.
It is a KNOWN fact that Assembly language programs usually take 1/2 the RAM of high-level work. Look it up.

Using either C++ or assembly has no impact on the amount of memory your game ends up using. Every PS3 game has to fit into 256MB of RAM, and I assure you that they're generally written in C or C++, but never in 100% assembly.

Anyhoo, if you give me about 4 hours and some instruction sets, I could find out what that would do exactly.

If I posted the equivalent code in C++, it would take 10 seconds for you to know exactly what it does. Q.E.D. 0's and 1's are 1440 times less readable than C++ (4hrs*60mins*40secs / 10secs). Look it up.

But, since it's just meaningless ... you spewed out, you probably don't even care, so yeah... why bother with you?

This is what we're all thinking! You're spouting nonsense and ignoring reason. Why should anyone bother to listen, unless they enjoy feeding trolls?

[darxus]

When I started programming by 2004 there was a cliche aspect that a programmer should be a mathematician (probably those who were not into programming though that it was as difficult as math). But by experience I learned that a developer has to get things working, there's no simply room philosophy in that, you use tools to make tools.

Software development is categorized in many specific areas and there are the appropriate tools for each task. So the point is to know how to use the best method and the most suitable tool for each task and requirement.

[AndyWonHarglesis]

High-level does NOT and WILL NOT have the same capabilities or control that Assembly or machine language has. Deal with it.

Give multiple examples of common scenarios that display this "lack of control."

Not exactly a "lack of control", but more hassle with control. HLLs like C++ and Java COULD MAYBE get as low to the point of controlling bits, nibbles and bytes, storing and such, but it's going to not be done in the same manner as Assembly.

Since bits are really behind this "IDE you're using to hide them", it's pretty obvious that without full bit control you're not doing it right.

[BitMaster]

Here's the clearest example possible ... C++ is downloading an IDE to swallow up all of your RAM when compiling half a gigabyte of DirectX API files that do shit for you except hurt your head and offer little control without lots of headache and torture.

You know, confusing C++ and an IDE for C++ is one of the prime indicators for "I like to talk but I have absolutely no clue what I am talking about". Arrogance and absence of knowledge have always been a difficult combination as your posts clearly show.

[lpcstr]

Not exactly a "lack of control", but more hassle with control. HLLs like C++ and Java COULD MAYBE get as low to the point of controlling bits, nibbles and bytes, storing and such, but it's going to not be done in the same manner as Assembly.

Since bits are really behind this "IDE you're using to hide them", it's pretty obvious that without full bit control you're not doing it right.

What are you saying? Firstly, I rarely use an IDE for any language. A text editor and command line is more than enough. Even if I did use an IDE, it wouldn't be "hiding" anything. An IDE is a fancy text editor, it doesn't hide any aspects of the language your developing with.

Since when can you not work with bits and bytes in C or C++? It's all there, and obviously it's going to be different. That goes without saying.

[owl]