Programming language idea

Hey Sup Forums I have an idea for an interpreted language
It would be a dynamically-typed interpreted language called "nigger"
syntax:
oogabooga("hello world');"

C+= was funny, your shit is forcing it.

Wow so edgy and wacky op .

almost as cancerous as LOLCODE

C+=?

N++
I like it!

remember to not stay up past your bedtime, op

Better idea for a programming language (not racist):

It would be called ProCreate. It would be an object-oriented prototype-based strongly duck-typed compiled language with C-like syntax. (Dear anti-OO-fags: Before you respond calling my language shit just because it's OO, consider this important counterargument: Go fuck yourselves.)

In brief, here's how it would work.

All objects would be types, all types would be objects, and all objects would be instances of the types which are them. For example, if you have object o, then o is an instance of o. You could declare another instance of o, and call it p, and then p would be an instance of o, but also an instance of p; therefore, since all instances of p are instances of o, but not all instances of o are instances of p, we could infer that p is a derived type of o. Therefore, in this language, instantiation and inheritance are the same thing.

Since types and objects are the same thing, and instantiation and inheritance are also the same thing, an object's type information and its state are also the same thing, and so it's easy to see why duck-typing would be necessary. An object o is considered to be an "instance" of a type (i.e. another object) t, for the purposes of type checking, if and only if all of t's fields have instances in corresponding fields of o.

If one wanted to use an object exclusively as a type, and not as an object in its own right, one would declare it 'abstract'. An abstract object's state can't be accessed except insofar as is done internally to copy it to any objects created as its instances, and is not guaranteed to exist except in that capacity.

Objects, whether abstract or not, can contain static fields, which are always accessible notwithstanding the above. When an object is instantiated AKA inherited from, the new object contains references to static fields instead of copies of them.

So... JavaScript?

No, not quite. The relationship between prototypes and their instances would be even more direct.

Observe:
A {
X; Y;
} /* A is now an object with two fields that are empty objects. */

A B {
Z;
} /* B is now an instance of A with another empty object field. */

B C {
W;
} /* C is now an instance of B (and by extent also an instance of A) with yet another empty object field. */

/* Note that B, being an instance of A, is also a subclass of A. Also, C, being an instance of B, is also a subclass of B. */

wile = while
finna = do

So how is this not javascript?

In JavaScript, all prototypes are objects, but not all objects are prototypes. In ProCreate, all objects are prototypes.

Some more differences are that it would be simpler, cleaner, strongly typed, and compiled. It would also support implicit this.

Further example code:
require Math;

abstract Point {
Num x; Num y;
(Num x, Num y) {
this.x = x; this.y = y;
}
static Num distance(Point a, Point b) {
return Math.sqrt(Math.sqr(a.x - b.x) + Math.sqr(a.y - b.y));
}
}

abstract Shape {
abstract Num area();
abstract Bool contains(Point);
}

abstract Point-Shape Rectangle {
Num w; Num h;
(Num x, Num y, Num w, Num h): Point(x, y) {
this.w = w; this.h = h;
}
Num area() {
return w*h;
}
Bool contains(Point p) {
return p.x >= x && p.y >= y
&& p.x

I don't see how this demonstrates your point. To me it looks like a slightly reskinned Java or C#, now you just use "abstract" instead of "class".

>now you just use "abstract" instead of "class".
Except, that if I didn't want to for some reason, I wouldn't have to, and then I could do this.
require Math;

Point {
Num x; Num y;
(Num x, Num y) {
this.x = x; this.y = y;
}
static Num distance(Point a, Point b) {
return Math.sqrt(Math.sqr(a.x - b.x) + Math.sqr(a.y - b.y));
}
}

Shape {
abstract Num area();
abstract Bool contains(Point);
}

Point-Shape Rectangle {
Num w; Num h;
(Num x, Num y, Num w, Num h): Point(x, y) {
this.w = w; this.h = h;
}
Num area() {
return w*h;
}
Bool contains(Point p) {
return p.x >= x && p.y >= y
&& p.x

>prototype-based strongly duck-typed compiled language
I'm sure some of those are conflicting each other.

Bud let go of his shift key a little too early.

How new are you?

>Doesn't know about C+=
Get out of here, you fucking newfags.

Since you can't really strongly type a prototype-based language and you have to duck type it, then no, it is not conflicting anywhere. However the semantic behind all this shit seems unclear