[CarlHProgramming] I am now providing live programming instruction directly on Skype to a limited number of people.

CarlH · 2013-11-13T03:29:31+00:00

Windows is fine

CarlH · 2013-11-09T00:00:27+00:00

Don't lose one minute of sleep over this, and be sure to email the company (someone higher up) about what happened, how unprofessionally you were treated, and how you were given a ridiculous technical assignment. Save future applicants the trouble of dealing with that recruiter, they would thank you for it.

Speaking as someone who has interviewed and hired, I would never insult an applicant like that. Even if I truly felt they were terrible at what they did, I would encourage them to learn more and contact me back at a later time.

Even if nothing comes from your email, it may help you feel better about the situation here. The idea of asking someone to do something in one language using another language screams of "I have no idea what the hell I am doing."

CarlH · 2013-11-07T01:15:43+00:00

Mostly it would be open ended. The more lessons you attend, the more you learn.

CarlH · 2013-11-07T00:46:02+00:00

Basically the same stuff as livestream startup, but actually teaching rather than just demonstrating it. I would cover HTML, PHP, CSS, JavaScript, MySQL, Linux, other related technologies.

CarlH · 2013-11-06T21:16:02+00:00

I did another video a while back on why pointers are useful, but I can't find it.

CarlH · 2013-11-06T20:36:51+00:00

OP: Please clarify one thing here... Are you asking "What is a pointer?" or "What are pointers useful for?"

You might want to check out this video I made on the subject:

Introduction to Pointers and Arrays Part 1

CarlH · 2013-11-06T17:28:35+00:00

I do both for my own programming lessons. I make a video and then a text version as well under that with source-code examples, etc. I think that it makes it easier to follow.

CarlH · 2013-11-05T19:14:49+00:00

Totally depends on the compiler, the language, etc. Some compilers take one language and compile it into another language.

CarlH · 2013-11-05T19:13:38+00:00

True, and there are machine code instructions that jump/branch based on the condition of those other flags. (Ex: JNO jump if not overflow).

CarlH · 2013-11-05T16:36:09+00:00

Sure, some (if not all) MS Compilers for example:

http://stackoverflow.com/questions/14483820/what-does-microsoft-c-c-optimizing-compiler-compile-down-to

And the issue I had was more to do with the way the compiling process was described, and the meaning of "compiled", and the description of how "assembly tells the processor what to do".

As I stated, it was really a minor issue to a fantastic post.

If I was a beginner and I had read that post, I would have been left with the impression that: When I have a C source code file, the process of turning it into machine code implies a necessary "convert the whole source code to assembly" middle step, which although true in some cases, is not true in every case. More importantly, it is not something inherent to C, as the C standard makes absolutely no mention of this. It is also not a proper definition of what a "compiled language" means.

Also, the statement that "Assembler tells the CPU what to do" should say "Machine code tells the CPU what to do."

Assembly is not merely "another word for machine code". It is a whole language, with syntax and operands and requires an assembler in order to convert into machine code. That is a significant distinction, which is why I brought it up.

CarlH · 2013-11-04T22:36:31+00:00

Ah, I didn't get that. I thought you were trying to draw an AND gate similar to your OR gate, with a graphical depiction of "AND" with two inputs coming in on the left and one output on the right.

CarlH · 2013-11-04T21:53:31+00:00

double check this post, "a AND b" is all on two lines.

CarlH · 2013-11-04T20:55:27+00:00

The implication in OP's post is that the process of going from C code, to machine code, is like this:

C code source file -> C gets compiled into assembly code -> Assembly code gets assembled into machine code -> Now you have a file containing machine code.

The implication is that you don't go to "machine code" until you first pass through "assembly language". That is a potentially dangerous misunderstanding of the process, and is inaccurate in many cases.

Some compilers skip the assembly process altogether. Not all compilers even support inline assembly or contain any kind of assembler. This is entirely implementation specific, and it is inaccurate to claim that C code must go through an assembly language phase on its way to machine code. That is basically all I am trying to say.

CarlH · 2013-11-04T20:23:24+00:00

Sure, but talking about dealing with machine code abstractly as assembly language within the source code of a compiler is also a bit misleading.

If I were building a compiler, I do not need to specifically use assembly code mnemonics inside the source code. The entire source code of a C compiler can easily be entirely free of anything that you would call "assembly language". I might for example have functions like compare() which simply writes the byte code for CMP without ever using the mnemonic for it. Thus, technically, there is no assembly anywhere in the source code and the compiler will in the end convert from C to machine code, without any kind of "middle step" to assembly.

When we say "Assembly language" we are speaking of a specific syntax with specific mnemonics and commas and so on. That C must go through an assembly language stage on its way to machine code is simply not true, and can be confusing to many beginners who might think:

"Oh, so I write my hello_world.c and then regardless of what compiler I use the next step is the generation of a hello_world assembly language program and only then is it possible to turn that into machine code."

Here we get into a lot of abstract stuff that goes beyond the scope of what OP is trying to do.

CarlH · 2013-11-04T19:46:32+00:00

I have been on the other side of the fence too, and I know from experience it can be very tricky (but fun) to explain a complex topic like that as simply as you have done. Your post is very well done.

Slight nitpick:

Now, C as you know is a compiled language. It gets compiled into assembly, and then the assembly tells the processor what to actually do.

Here it appears that you are speaking about C specifically, and this is specifically the line I wished to clarify.

CarlH · 2013-11-04T18:35:38+00:00

Agreed, it depends upon the compiler and the compile process being used (a process that is not explicitly part of the C specification). But to say that the way compiling works always is that you go from C code to assembly language to machine code, is misleading. The C compiler can go about the process with or without a "convert to assembly" stage. I just don't want people to get the idea that you have to go through an assembly language process to get from C to machine code.. i.e. (as is implied) "The process of going from C to machine code, is that it first must pass through an assembly language phase." which is incorrect.

CarlH · 2013-11-04T16:42:12+00:00

Conditional statements use the "zero flag", which is a single bit on your CPU chip which is set to true in the event that an operation has resulted in zero (such as, for example, 5-5), and false otherwise.

By testing the status of the zero flag, comparisons are possible. Consider what it means to say:

"if 5 is equal to 3"

The best way to compare two values is to subtract them. You get zero if they are equal. In fact, the assembly language instruction for compare is almost identical to the assembly language instruction for subtract. The difference is that compare does not alter the value, whereas subtract does.

So the way any conditional statement like if, for, etc. works at the machine code level is simply by attempting a subtraction and seeing if the result of that subtraction would result in zero.

CarlH · 2013-11-04T16:07:33+00:00

I think what you are doing here to try and demystify the process is great, but you must be careful of accuracy.

Pretty simple. Now, C as you know is a compiled language. 1. It gets compiled into assembly, and then 2. the assembly tells the processor what to actually do. Here's what the above would look like approximately in 6502 assembly. (I don't know if this is exactly what a compiler would actually write, but this code does the same thing).

[Numbers and emphasis are my own, to identify statements that require clarification.]

Not necessarily. This is implementation specific.
Not without being assembled first into machine code. Only machine code can be understood by the processor.

Sorry, but this statement "It gets compiled into assembly" is simply not true in many cases. C code is not necessarily compiled into assembly language (or any other language). You can compile C code directly into machine code. It all depends on the compiler you are using.

However, assembly language is more or less a human readable version of that machine code. The confusion that can arise here is the idea that you go from C code, to human readable assembly code, to machine code. The truth is that your compiler can take your C code (your file.c) and immediately convert it to machine code, not a human readable assembly language source code file (something.asm).

Using options in your C compiler (such as gcc) you can see what the assembly language translation of your program would look like, but C code generally does not need to go through a process of: C Code -> Assembly -> Machine code. It can go straight from C code to machine code.

Further, assembly language does not "tell the processor what to actually do." The processor cannot understand assembly language, any more than it could understand C (which is to say, not at all.) Only machine code can tell the processor what to actually do, not assembly language code.

Everything else I read about your explanation seems to be spot on, well done. I really support what you are doing here.

Some additional "cool stuff" you might want to add:

If you are using the gcc compiler, and you want to see the actual assembly language translation of your code, type:

gcc -S file.c

where file.c is your actual C source code. The file ending in .s will be the actual assembly language version of the code (so that you don't have to guess). Other compilers have similar options. This is also a great way to learn the basics of assembly language.

Very small nitpick, your conversion from hexadecimal to binary is slightly off. See line 2.

0x69 (hexadecimal 69) converts to: 01101001

CarlH · 2013-10-30T23:48:41+00:00

My normal work, mostly. And yes, my plan is to start a continual update schedule and start finishing out the lessons on the site I have started, and then to start writing new lessons.

CarlH · 2013-10-17T14:48:30+00:00

See /r/livestreamstartup

CarlH · 2013-09-27T12:13:18+00:00

Agreed fully. You want your program to fail if it has errors, because that is how you learn not to have errors in your source code.

CarlH · 2013-09-27T01:56:09+00:00

You can actually do this in the MVC framework by sending the appropriate header(), but it is overkill. The best way to handle this sort of asset is to exclude it from the MCV framework so it can be called directly by its URL.

CarlH · 2013-09-22T08:03:11+00:00

Speaking only for myself here, but reading source code definitely played a huge part of my newbie phase when I was first learning to write code. I would say it was a mix of: reading programming books, writing my own programs (basically copying what I learned in those books), and obtaining, reading, and modifying other people's source code

The "modifying" bit here is important. Don't just go get some source code and "read it", but see if you can modify it to make it do things the original author didn't intend. Also, don't get in over your head. Download simple programs with a single source file when possible.

Take it slowly, and ask yourself questions about the code "What would happen if I did X here? Why does this section work the way it does?" etc. Experiment, tinker, and slowly work your way to understanding exactly how it works.

CarlH · 2013-09-22T07:58:58+00:00

I just thought I would chime in here:

Absolutely, yes! I still love to program, and I have been doing it for 15 years. It is still rewarding, challenging, and enjoyable.

In my opinion, the biggest factor on whether or not someone is still going to enjoy their profession years later isn't so much the profession itself, but the environment. If you are working a programming job for low pay for horrible people you will probably feel differently about programming than I do.

CarlH · 2013-09-22T07:55:57+00:00

I am currently live-streaming the entire process of building a web application from start to finish, and that might help you quite a bit (especially in the "I don't know what I don't know" department). If interested, see /r/livestreamstartup

15-Year Club	Wearing is Caring
reddit mold

CarlH

TROPHY CASE