Probably, unless he uses REGEX to filter out non-GCC calls.

Don't.
We have to show the world we are normal human beings too.

The fact is that we're not

How many "normal" people feel the desire to make a machine perform odd tasks?

If you're going to use 7zip, use PPMd. However, if you'd like something with even higher compression, try PAQ, which is generally considered one of the best general purpose compression algorithms in existence.

That said, what algorithm you use depends heavily on what you're compressing. If you're compressing things with a lot of repetitive data, simple Huffman encoding will give you a near optimal results. If you're compressing random binary noise, no compression algorithm is going to do well.

I don't think this is a shell.

With large projects, OOP is much easyer to find the piece of code you should work at becouse you can store the classes in different folders so you won't have to spend 70% of your time by scrollingto the code you want to edit.

I'm working at a large project with java, and it has got a total of abouth 1500 lines of code, but becouse they are arranged in five different classes, the files only have got an average of 300 lines. This is much easyer to find the code you need

Khavi, the project I mentioned in my first post, as approximately 4000 lines of code at the moment*. The code is currently divided into 3 subprograms and it takes me around 15 seconds to find the code I'm looking for. I'm not sure that putting

public static void main()
{
      Something
}

 significantly improves your code's organization above "#include <file.s>" or ".macro"

*I assume you meant 1500 lines of code, not 15000, because 300*5= 1500.

I've been curious about what tangible benefits Object Oriented Programming offers over normal procedural programming [for some unknown but competent programmer], since everyone seems to rave about it.

From what I understand, OOP basically expands upon the idea of a class that's effectively a general classification of objects. To create objects, you instantiate them from their classes. This is actually very similar to a problem I solved in Khavi where multiple threads have to be created that are very similar to each other. However, since Khavi is written in a procedural language (ASM), I couldn't just instantiate from a class. My solution (which took remarkably little code) was just to treat the initial primary thread as an array of bytes and do a simple array copy to another location in RAM.

As for objects, I don't see why they're any different than subroutines with argument passing. You pass the arguments to the methods, which operate on them and change the state of the object, precisely as subroutines do to the program state in procedural programming. This also brings up the point of data encapsulation, which I honestly can't fathom a reason for as long as the programmer is competent enough to properly debug their code (or not do stupid things like arbitrarily change the arguments the function requires).

Another argument I see for OOP is code re-usability, which touches on several things, most notably inheritance. Inheritance can be fully implemented in any reasonable procedural language with a simple subroutine call or copy and paste. A subroutine call doesn't take much more code than a declaration of inheritance. However, if you want to re-use code across different projects, it would seem that classes are good as black boxes, right? If you think about it for a minute, the most widely re-used code in existence, the C standard library, is entirely procedural. It's also incredibly simple to use, effective, and a nice black box to most programmers.

Packages are another story. What benefit is there to using hundreds of classes over using subroutines or subprograms? Almost every operating system ever written has a library of some sort. That's represented procedurally and yet people maintain operating systems for years. Same for pretty much every library.

"Self Documenting code:" My general view on self-documenting code is that when you go to maintain it in ten years, it won't seem so self-documenting. Use comments. They're there for a reason.

"Maintainability:" If your code is well written, maintenance should be relatively straightforward.


So, can anyone try to explain what benefits there are to OOP? I feel like I must be missing something if so many people rave about it (And it's taught in every software school).

Wait, "welcome.exe?"

Are you seriously parsing .exe files?

- BF doesn't have get key Having a built in get key with this would be stupid.  It could be done interlaced with assembly, and I think its already bad that it supports output to screen as characters.
...
Half of above doesn't even relate to this directly at all I know what turing completednesss is and that this is a TCL.

BF uses the ',' command as a "getkey" of sorts. It takes a byte of input from the user and places it in the cell at the data pointer. TCPS doesn't appear to have anything like that aside from the filename thing, which is... annoying. Also, not having I/O takes away from the ability of the language to replicate programs in "real" languages. Sure, they aren't necessary for Turing completeness, but they make brainf*ck a theoretically useful language by not forcing everything to be hardcoded and perfectly deterministic.

As for how the proof relates to the language, you can't just say "This language is Turing complete" and have it be so. The creator of Malbolge stated that it was Turing complete in his presentation of the language, while the language actually isn't. What I provided was an informal proof (which would serve as a nice outline to a formal proof) of the language's Turing completeness.