Emerald:



Emerald is a language I have theorized for a long time. I have finally decided to make this

my primary project! I choose to present it here cautiously, not because there's competition

but rather due to the entirely new form of syntax and ideals it portrays. An example of the

syntax:


Code:


ostacks are a main feautre of emerald. Ostcks are object stacks, which essentially hold

unnamed objects in an indexed format. This is one theory I thought HAD to be included, and

is really awesome because to create a new one all you have to do is use 'generate' and say

which stack you add it to. The stacks can be set to accept only certain types, but the

'etc' commands allows for you to later define types that can be inserted into the stack.

Everything in the stack inherits traits from a higher class -- but I didn't use it ion this

example.

Weird concept, but I personally think it's awesome.

That's just one of the surprises in Emerald Coding -- other features include:

- compiles to interpretable bytecode
- full support for object oriented programming
- new additions to the original object oriented approach
- very user-friendly syntax
- to tell the truth, there's about 50 other points I can make, but I'll announce them over time

[More info later]




VixenVM



A low-level minimalistic VM for interpreting Emerald Bytecode! Includes minimal GC, threading control, and forwards compatibility!

[More info later]

Awesome programming lang sounds awesome! Good luck!

thanks

I actually am trying to make a documentation WHILE I'm developing it, and making it so comprehensive even if you only know TI-BASIC to start, you'll eventually know Emerald fluently in a few weeks

Interesting new language and ideas.

Not to discourage you, but here are a few things to keep in mind while designing a language:

1) Don't add keywords just for the sake of having a keyword. Adding words where symbols are equally readable (or where no word or symbol is really needed) leads to verbosity and unreadable code. I'm specifically referring to your "further" and "/further" keywords, which could be replaced with either braces { }, as in C-derived languages (of which there are many), or with nothing, as in languages like Python. This is especially true when the keyword is vastly different from any other language (I haven't seen any other programming language use "further" to delineate a code block) yet doesn't truly contribute anything to the language. The "define" might also fall into the category of superfluous, since it's used where an ostack/type/method.

2) Use words that are already defined for the problem. In this case, "type" could be replaced with "class", since that is already well-defined in the OOP world. "type" can also be slightly ambiguous. "creator" also has the standard name of "constructor" in the OOP world.

3) This kind of follows the same trend, but instead of /n for newline you could use \n, unless you plan to use / as an escape character as well. Most languages these days use backslash (\) as an escape character*, and it's generally not a good idea to go against the grain on the little things like this unless you can justify it by bringing some radical new feature or idea to the language which relies on it.

4) Explain how ostacks can be used in real applications and how they differ from (for example) a user-defined stack class.


In summary, you're most likely to receive good support for your language if you do not deviate in syntax too radically from existing languages, except where necessary to support new features or concepts that would not work with existing an syntax. To illustrate what I mean, you could still introduce ostacks and other language concepts/features while keeping a vaguely C/Java-like syntax:

Code:

As you can see, this example code is much less verbose but more readable (IMHO) than the original code. It also removed the typo of the superfluous keyword "further" as in your Cat creator method ("futher").


* Powershell, I've noticed, uses the backtick (`) as the escape character, probably because Microsoft poorly decided to use the backslash as a path separator.

Ashbad, I'm sorry if I'm rude, but how many languages have you said you'd make so far? I can count 3, not being rude, but perhaps you should try and finish your projects before starting new ones because your finished ones look great (Pyyrix, Vector Tunnel, Trio and Nikko demo).

Especially for calcs, making languages for calcs is even harder.

Either way, good luck!

I shall answer all concerns accordingly



I personally think that symbols make highly messy code and should be abolished. Many new languages these days are abolishing symbols for a certain reason: better readability for quick-reading. A /further or a /if can help you pinpoint exactly where you forgot to match something together, or help you understand the code better We don't get anywhere closer to the future of programming by staying the same with our techniques.




The OOP world isn't always the way to go. Many things in the OOP world are just stupid. I personally think that someone will learn faster with better naming conventions -- I mean, wth is a 'class'? it takes more to explain. However, with a small summary someone can learn what 'type' means 10x faster.




that was actually a mistake of mine. I intend to use '\' as an escape character.



define how most trivial things in OOP like generals and protected traits work in OOP. It's an idea. In fact, it's quite useful. One example -- a assembly line produces many new cars, each one after the other. They have no names, but they all share traits defined in the stack's attributes, so they can be related much easier than a Stack-Class. The idea of stacks is fully handled by the VM along with other 'easily attainable' ideals such as threading and garbage collecting, but makes handling objects much easier in many cases. Plus, there's even more cool things I can add that stacks can fulfill.

TL;DR:

1. It's a different language, so it will have differences in many aspects.
2. Don't like it, then just don't use it

AND SCOUT, I answered you on omnimaga

Fair enough. Why not abolish all special symbols and require the programmer to code mathematical operations like this:

Code:

Surely that is cleaner and more readable than this:

Code:

But seriously, why not use "begin" and "end" or similar for method definitions? Algol-based languages (eg, Pascal) use those keywords instead of braces. I personally don't like them, but I think they're substantially better than something like "further"/"/further". On the other hand, since you mentioned "if" and "/if", you could be more consistent and use "/define" to mark the end of a class or method definition like this:

Code:



That's not a valid comparison. Generals (I've never heard of those in OOP) and protected traits are OO primitives. Protected traits are there to hide implementation details in order to simplify the interface to the class (yes, the word "class" in OOP makes perfect sense, just as real-world objects are classified into--guess what? classes!). An ostack, on the other hand, can be easily implemented as a regular class.


"They have no names" aka anonymous objects. "but they all share traits defined in the stack's attributes" aka objects instantiated from a class. Those are easily created in a stack/list/queue/whatever user-defined class as well.



Tell me this: what are the semantics and operations available with an ostack? Can objects be pushed on and popped off in LIFO order? A stack is a LIFO data structure, and if an ostack doesn't support pushing and popping in LIFO fashion, then it's not a stack at all. It's something else entirely, possibly an ordered/unordered list or even a queue.

Note: the Java (for example) language proper doesn't have any built-in classes for stacks, queues, lists, or other types of collections. All of those classes are defined in the standard library using regular classes. The language is general enough and powerful enough to be able to support any kind of stack that is needed.


Of course it will have differences. I only take issue when a language is different purely for the sake of being different (except when that is the very purpose of the language, eg Brainf*** or Whitespace).

Thanks! I probably won't! Others might feel the same way too! I'm only trying to say that more people are likely to use a language if it is similar enough to existing languages (so it is familiar and easy to pick up) but different where it matters (to support new concepts, or where existing languages clearly fall short).

I'd really prefer that comments on this build upon what I have and don't just try to convince me to change something, or make it seems stupid for keeping it the way it is. The arguing doesn't help me any more to theorize this. The things I have are staying. Feel free to come up with more ideas, though.

EDIT: and I don't think I made it clear, but "further" is much different from a normal definition. You can use it to further define an type whenever, and define is used only as a keyword that sets up an empty class. 'further' is used to actually fill that class with stuff.

EDIT2: and this language uses OOP that is implemented from a non-poisoned point of view (poisoned as if made by someone who only wants to stick to the conventions of C#, Java, C++, etc. the ugly OOP languages). This is made in a different approach because I find modern OOP to be ugly and stupid. My opinion. Feel free to agree. But I still find it quite ugly and non-representative of real-life objects.

OK, you're right. I'll try to keep my comments constructive from now on.

Do you have plans for separating a class (or "type") interface from its implementation? Java (I know you think it's "ugly", but it really is well designed as a whole) stores a class's public interface (public methods and attributes), as well as the return type and argument types of each method, inside the .class file, and all references to these interfaces (from other classes) are checked at link time. Linking happens either when the program is run inside a JVM or when the program is compiled down to a native executable file (as with the gcj java compiler).

C++ typically uses .h (or .hpp) header files to declare classes (the interface), and then the definition (the implementation) is put into the .cpp source file. The drawback to this is that all private class members have to be included in the class declaration, which means that any changes to the private class members also requires compilation of any source file that uses that class. This is because code that instantiates a class needs to know how big the class is, and private members are included in that size. This is admittedly a design flaw of C++. Java, in contrast, stores objects in the heap (or somewhere similar) and passes only an object reference to any code that creates an object.


As I understand it, you use "define" where many other languages call it "declare", and you use "further" to define the body of a method. Do you plan to allow the class declaration to be separate from the class definition in any way? Of course, if you follow a Java-like route as far as this goes, doing that becomes unnecessary.


I do disagree. I too have issues with some OO languages, but not to the point where I feel that they are ugly or stupid. OO concepts and terminology are relatively standardized and are language-independent ("class", "object", and "instantiation" are the standard names for three of the core concepts of OOP), so it seems that you don't like the standard names in OOP. These concepts have these names for a reason. For one thing, "type" is a broader term than "class", as "type" could also refer to integer or other data types which may be primitive types (not classes) in a language. I won't convince you to change anything in your language so I'll just end with that.

By the way, I am still curious about how an ostack will work, as in what other actions you can perform on it. Your example code only shows that you can create a nameless object on it and then access the object in the ostack like an array. I'd like to see what else you can do with it.

Don't let me dissuade you yet, since I haven't really read your proposal thoroughly, but you're falling into what I think I'll call the SirCmpwn Present Tense Trap. Specifically, you say things like "other features include: " and use present tense throughout, which usually is used to mean "these things are complete", and is misleading. I bring it up because I've found it can indicate a strong possibility of not finishing a project, often because people raise expectations too early, only to have their audience disappointed when they find out it's all future planning. Sounds cool from the skim I made over it, though.

Yeah, I always use the present tense my bad. But, I intend to finish it no matter the cost. I have a 10 page documentation already, so ha XD

christop: good points. I'll have to think over some of them when I have time (in about an hour)

I'll just leave this here...

I have decided to change the idea of the 'Stack Theory' I had -- it was a decent idea, but the way I implemented it was stupid. However, it did evolve into GROUPING, the main form of inheritance and erm, grouping objects in emerald.

Basically, a group of objects are all related by an 'extending' type (class). everything in that group inherits everything from that group's master type (superclass). Every object in there is not extended to that master type during declaration, but during generation. This means that one class can be made in unique forms and can extend different types.

Another thing about the 'Group Theory' of mine is that it allows more flexibility of Object Polymorphism. You see, everything in a group extends a master type -- that makes all grouped objects 'brethren' classes. Protected attributes can by shared only among brethren types. However, I also plan to have it so that groups can be grouped my master groups, so then that makes all brethren objects in one group brethren with brethren objects in another group. This layout totally kicks out the wall of normal OOP and can actually be quite useful in a large variety of applications, whereas an OStack most likely won't. Thanks for all the advice christop, sorry about my bit chin'

Another thing: I've been reading about different programming languages lately, from ALL paradigms and generations that can be found on wikipedia, and from that I've gotten interesting ideas. Please express what you think of them:

- Atom variable types, which basically define anything you set them to define. This can lead to confusing code, but on the contrary in some instances can also lead to cleaner implementations

- when you further a class with the 'further' and '/further' keywords, you don't just define a type. 'further' can be used any time, any place to extend the attributes of a type -- so you can create tons of cats with only a name, but later extend them to also have an age (I actually came up with this one on my own)

- simple polymorphic code

- you can declare a class anywhere -- and with polymorphic code included, you can put a class declaration in a nloop (for loop) and change the name of the class you define each loop, so you can effectively create 100 types in <5 lines of code (kinda came up with this on my own)

- allow for pure-functional code to be the basis of a program as well, to support many different paradigms to help more people enjoy the language (well, I obviously ripped this from >50 modern languages )

any others? I spent a while today thinking these up, so I would appreciate any concerns, comments, or suggestions and I'll try to be more grateful for feedback from now on; again, sorry christop, no hard feelings I hope.

JavaScript allows this too but probably in a different way. It's a loosely-typed language and allows you to add methods and attributes to any object at any time. Actually, there's no way to explicitly define a class in JavaScript, so that is the only way to create a class. Here is code that shows a common way to create a class, create an object of that class, and then use that object in JavaScript:

Code:


JavaScript allows polymorphism on the fly too in similar fashion.

No hard feelings here. I'm pretty thick-skinned (and thick-headed).

I'd like to see what kind of language you manage to come up with. Good luck!

Even C++ allows you to arbitrarily extend classes into other classes while adding methods and members. I don't know that I particularly see the value of modifying class structure on the fly, although I'm likely just missing something. Also +1 on Ultimate Dev'r's link.

Kerm, I'm sure you wouldn't be editing a class' structure regularly, but let's say you have a program like this:


Code:


somewhat bad example, but it does work fine in explaining methinks.

With a few changes, that would make a good example of inheritance and polymorphism (since the Man, Woman, and CreepyGuy types could all be derived from a base class/type called "Person").

I noticed that all of the creator methods are named "Man". Is that on purpose? The creator name isn't used anywhere else, though, so you could maybe:
1) change the names to a special name, eg "creator" or "new":

Code:

OR
2) change the names to the same as the type, and drop the "creator" keyword:

Code:

Either of those options would remove a bit of redundancy in the syntax. C++, for example, follows option 2. The constructor for the Woman class must be named Woman. VB.Net, Perl, and PHP5, on the other hand, follow option 1. VB.Net names the constructor method "New", and Perl names it "new". PHP5 names the constructor method "__construct".

See http://en.wikipedia.org/wiki/Constructor_%28object-oriented_programming%29 for a lot more examples. Just something to think about for Emerald.

See also http://en.wikipedia.org/wiki/Duck_typing

that's actually a good idea

also, duck typing seems interesting -- polymorphism between classes with no inheritance. I find that cool however, I'm not sure if I'll make it the main form of polymorphism, since the main type is grouping -- though, I think I shall consider it as a second approach

Well, duck typing would probably introduce a lot of run-time overhead, so it might not be appropriate if this language is designed to run on a calculator. Actually, any kind of dynamic typing would add some overhead too.

good point, I guess

however, I think I talked with you about atomic types in SAX -- for those who didn't hear, basically atomic types can be loaded with any type of variable or object and can't change. very useful for arg vars.