You are bad and wrong. You're badong.

I thought you got banned for these Obvious Troll posts already?

Its fine and all, but one day you'll grow out of the "1337 c0d3r" attitude and realize that, frankly, no one would ever get anything done if we were all running about writing assembly. There's a reason we moved on from assembly long ago, even when there really was a pronounced difference between an "average" assembly programmer and the best compiler's available at the time. Nowadays, that difference is negligible on most platforms with modern compilers -- a good compiler for C or C++ these days easily bests today's "skilled" assembly programmer -- and can do it in probably 1/10th the time invested. These days, the only occasion where assembly still makes sense for performance reasons is when the programmer can apply additional context that is difficult or impossible to make the compiler understand, or when the compiler, for whatever reason, happens to be outputting particularly bone-headed code (which is rare, but can happen), or perhaps you're on a small system (embedded/microcontroller) with poor high-level language support (or perhaps none at all).

Everyone should be able to read, understand, and analyze assembly code -- most should be able to write it, or at least be capable of modifying it. Only a few, have any pressing need to write large stretches of assembly. In games, I'm not aware of anyone these days that jumps straight into assembly -- they get it working in C++, profile, find a bottle-neck, try algorithmic optimizations/DOD/intrinsics first, and only as a last resort use direct assembly (or even intrinsics, really) -- more often than not, they grab the assembly output for the source code bottleneck and try to massage it into something that works better, rather than replacing it from scratch with hand-forged assembly.

Basically, assembly is an indispensable tool of last-resort, but that doesn't mean the whole program, or even large chunks of it should be written in it. Especially not when you have to hire 5 times as many developers to do it in a timely fashion, or extend your schedule 5 times past where you'd like to be done.

I don't think you fully understand the purpose of higher level languages. The whole point is to abstract away the underlying hardware and focus on the implementation of the program or the algorithm itself. One primary reason behind this abstraction is due to the multitude of hardware platforms out there.

One good example is the graphics card. You have hundreds of cards out there, most of them are quite different on how the CPU communicates with them on the low level. Supporting these cards on the low level is a monumental task and quite tedious - especially when all you want to do is draw a triangle on the screen. Low level access is also proprietary, and information about them is scarce. Therefore, APIs were invented, such as OpenGL and DirectX, so that the graphics programmer doesn't have to worry about the nuts and bolts, and just get on with making games, or visualisation software, or whatever that earns their bread. This was a real problem in the DOS days, when game developers had to just about write their own drivers to support different VGA cards and sound cards. It sucked.

The same applies to programming languages. C, C++ and even higher level languages gives you the flexibility to port your code to any platform, whether it'd be x86, ARM, MIPS, Cell, etc. You don't have to worry about rewriting the same code in assembler only to run your program on a different CPU. Just recompile. High level languages also give you the option jump ship when the platform goes to shit and move somewhere else. If you have everything in assembler, you are screwed.

Also, programming in assembly is not necessarily efficient. Maintaining assembly code is horrendously difficult for a large project. Very easy to screw up. Very hard to find bugs. Don't get me wrong, assembly has its place, particularly if you do things like SIMD optimisation for inner loops, image processing, or writing a driver, or working on an OS kernel, or work on an embedded platform with very limited resources. But these are special cases. There are few reasons to write an entire commercial project in ASM, unless you do it for kicks, or want to learn about the hardware platform.

Furthermore, why do you need to 'control' everything? I couldn't care less how the hard disk driver streams data to the controller. I couldn't care less about DMA interrupts and making sure their buffers are filled. They are interesting, and love to learn about them, but it's not my job to maintain these menial task, it's the driver's, operating system's or the API's job. I just want to make games.

That's your argument? No offense, but I kind of expected a discussion here and not just "badong" as a response.
Let me hear your side of this ... Why is it bad and wrong?

Every single one of your sentences is completely and obviously wrong. They're all made up illogical nonsense.

The only assumptions I could make from this is that you're either learning-disabled or you're trolling. I decided to give you the benefit of the doubt and make the more flattering assumption that you're a troll rather than that you're retarded.


If you're actually serious, your problem is simply that you're bad at software engineering. You don't understand software engineering whatsoever and complex designs are too confusing to you. Throwing them all away and playing in a simple sandbox is more comfortable for you at the moment. That's all.


High level languages such as C to C++ to C# do give you low-level control. You can manipulate specific bits and bytes and perform assembly-level optimisations to your heart's content. Likewise, they do provide low-level hardware access in the same manner that you can achieve via assembly. No, using assmebly you can't control your GPU fully - you're limited to the parts specified via common standards, which excludes any actual real GPU usage.

This is all simply plain wrong. You've stated something as fact that just obviously isn't true -- how do you want me to argue against this nonsense?

Universities do teach assembly. It's not practical for day-to-day work though so it's mostly taught to help people gain a bigger picture of computer organisation, not so they can actually use it.

Most API's are not "complicating, unreadable, illogical and overwhelmingly exasperating and psychotically tiring" -- this observation demonstrates that your opinion is simply rooted in inexperience, ignorance and incompetence.

Assembly code isn't as readable or maintainable. It's not as debugable. It's not portable. Unless you've read the several-hundred-page manual and guide supplied by the supplier of your target-processor, the in the general case hand-written assembly is usually slower than complier generated assembly. Coding in assembly is slower than in a real langauge. Refactoring assembly is slower. Bug-fixing assembly is slower.

Go get yourself a software engineering or computer science degree and you'll learn some valid points.

[color="#1c2837"]C++ is about as low level as I've ever had to go. Although there were two cases I can remember in which I needed inline assembly to bypass some short comings in C++ but I ended up dropping the idea altogether because it was IDE dependent. The fact is if companies used it to produce large projects they would be throwing money out the window and this is the reason it's not taught in college.

Dude, show us some working sample code and prove that your way of doing things is better.

(Anyway, I think he might be an alias, trolling for his own amusement... and I fell for it, damn it. )