No, algebraic data types so that the elements of an enum like is:

enum colors {
  red,
  blue,
  green,
}
So that red, blue, and green are different values, and don't just correspond to an integer type.  Of course, checking between data types would be done mostly at compile-time.  This is just a little part about how algebraic data types work (different ways to construct them and treat them based on used value constructors, etc.) but it makes things safer and less error prone.

Also, namespaces are good.

@Ashbad, alright, I think I understand and can probably implement that.

@SirCmpwn, the goal is just to be a usable OOPL. I know other .NET languages are more widely used, but I just think it'd be neat to have a language to call my own

I should post about my project of making a programming language...

You should.

Also...

Another thing: the subroutine thing has little point if it *takes* arguments but doesn't return anything.  The function thing is on the right path, though I think you should just stick with the function thing but call it a sub instead (so that way if you in the future decide to add real functional aspects to the language, you don't have to completely re-invent everything)

I disagree. You can have a subroutine that takes arguments yet does not return anything. Especially if you use that subroutine over and over.

For example, before I started using SharpDevelop's TextEditor, I attempted to make my own. In that, I had a subroutine called Reset, and it looked like this.
private void SetCurrent(Color highlight, int pos, int len) {

    this.SelectionStart = pos;
    this.SelectionLength = len;
    this.SelectionColor = highlight;

}

I could use that whether I was highlighting a word, or just setting the colors back to normal to resume typing.

Keeping "sub" and "<any type other than sub>" will also help with organization and readability, in my opinion.

How would having a "separate command" add confusion? C# has "null" and "void" which are essentially the same thing. The only difference (between methods and functions) is in voids, nothing is returned because it doesn't take "void" or "null" as an actual type definition.

When I was taught programming in school, I was told that a subroutine could or could not be passed any number of items and it could choose to directly modify those items or use them to modify something else within the program, and a function could or could not take arguments but returned some kind of value whose type was not null or void, but it could be null in value.
So this would be a subroutine (NOTE: in the class that I took, we used VB6; I'm just applying my learning to C#):
private void RoutineName(<any number of modifiers>) {

    //do stuff, but don't return anything

}
And this would be a function:
private <any type that's not null or void> FunctionName(<any number of modifiers>) {

    //do stuff

    return <variable that is the same type as that specified in the function definition>; //This was the key difference between a function and a subroutine; this actually returned something

}
That's what I mean when I talk about that.

Nah, it's more of my bad because I assumed that that was how those were generally defined. But, you know what they say about assuming

Yeah, I agree now. I tried making a few sample dummy codes and I constantly typed " before ', so I'll just leave strings to be what every other programming language does. If I do implement chars, though, I'll make it similar to C# and use 's to define char literals.

Also, DERP on my part. I forgot about loops

Hey, if you can think of a new loop and at least it's equivalent in VB or C#, I'll do my best to implement it

And I can't wait to try it out either, and hope it catches on too, but I need to at least get the layout finalized and get the compiler ready for a couple of controls