• ### Announcements

• #### Download the Game Design and Indie Game Marketing Freebook07/19/17

GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Followers 0

# Writing my own programming language

## 17 posts in this topic

What are your goals with this project? It's hard to comment on what I think of it without knowing what it's for.

0

##### Share on other sites

I just started this project some months ago, so it looks raw. But I want to develop it further so that homebrew developers can make portable games using this language. (I know there are other language but I'm not concerned with that). I will write the VM for most of the modern platforms.

Besides that I started this project just for the challenge and fun. I am going for Bachelors of Computer Science next year and hope knowing these kind of stuffs will give me head start...

0

##### Share on other sites

That's rather vague, but I'll give some comments about what I think of the language. It's mostly my opinions on language style.

• Semicolons are redundant to line ends in marking the end of a statement. For people reading, line ends are the more obvious signals that a statement is over, and a line not ending in a semicolon is likely a bug, unless the line wraps around. Therefore a language should just use line ends to mark the end of a statement.
• By a similar token, indentation is the primary indicator of a block for a person, so it's good if that's also what indicates a block to the language.
• AND behaves like multiplication and should have higher precedence than OR. This applies to both bitwise and logical operators. XOR and OR both behave like addition.
• Double precision floating point is used more than single precision. That's probably something you should know, and apply even outside the context of this project. At the least, add double precision floating point.
• C's syntax for declaring arrays is awkward because the type wraps around the variable. It's part of the reason why std::array was added to C++. Don't use it.
0

##### Share on other sites

That's rather vague, but I'll give some comments about what I think of the language. It's mostly my opinions on language style.

• Semicolons are redundant to line ends in marking the end of a statement. For people reading, line ends are the more obvious signals that a statement is over, and a line not ending in a semicolon is likely a bug, unless the line wraps around. Therefore a language should just use line ends to mark the end of a statement.
• By a similar token, indentation is the primary indicator of a block for a person, so it's good if that's also what indicates a block to the language.
• AND behaves like multiplication and should have higher precedence than OR. This applies to both bitwise and logical operators. XOR and OR both behave like addition.
• Double precision floating point is used more than single precision. That's probably something you should know, and apply even outside the context of this project. At the least, add double precision floating point.
• C's syntax for declaring arrays is awkward because the type wraps around the variable. It's part of the reason why std::array was added to C++. Don't use it.

I really don't agree with your line end as ending a statement I want to be free to add layout to my code as I see fit and not as the langauges syntax sees fit.

Block constructs that are marked by tokes is far easier to read when the blocks start spanning 25> lines of code and after that you step back one indentation level. Also only using indentation doesn't allow you to mix tabs and spaces even though the indentation level looks the same. This has lost me quite a bit of time when writing python stuff sadly.

0

##### Share on other sites

That's rather vague, but I'll give some comments about what I think of the language. It's mostly my opinions on language style.

• Semicolons are redundant to line ends in marking the end of a statement. For people reading, line ends are the more obvious signals that a statement is over, and a line not ending in a semicolon is likely a bug, unless the line wraps around. Therefore a language should just use line ends to mark the end of a statement.
• By a similar token, indentation is the primary indicator of a block for a person, so it's good if that's also what indicates a block to the language.
• AND behaves like multiplication and should have higher precedence than OR. This applies to both bitwise and logical operators. XOR and OR both behave like addition.
• Double precision floating point is used more than single precision. That's probably something you should know, and apply even outside the context of this project. At the least, add double precision floating point.
• C's syntax for declaring arrays is awkward because the type wraps around the variable. It's part of the reason why std::array was added to C++. Don't use it.

I really don't agree with your line end as ending a statement I want to be free to add layout to my code as I see fit and not as the langauges syntax sees fit.
Block constructs that are marked by tokes is far easier to read when the blocks start spanning 25> lines of code and after that you step back one indentation level. Also only using indentation doesn't allow you to mix tabs and spaces even though the indentation level looks the same. This has lost me quite a bit of time when writing python stuff sadly.

If you ever get a chance to read other people's Perl code, you'll get a better appreciation of language conventions. If you write code with a weird layout, your code is difficult to read. When the language prevents that, it's a service to programmers reading the code. Code intended for reading; and really all code is intended for reading, throwaway code is a myth; should properly indent every statement to the depth of the block it's in, which is always more than the previous block. Lines in the same block should be indented by the same amount, using either spaces or tabs and not a mix. Otherwise it makes your code look different to different developers, based on their editor settings. So again, it's a service to programmers reading your code that you're unable to do so. These are conventions that should be followed in any language, so when the language enforces it it only helps you.

And it means you never have to read about another missing semicolon when both you and your compiler know exactly what you intend.

By the way, Python actually does allow you to use braces and semicolons.
1

##### Share on other sites

I prefer semi-colons and marking blocks with braces because it feels explicit and unambiguous. The statement will not end without something that marks the end of it, and blocks begin and end in only one way that is indisputable; considering things like JavaScript's optional semi-colons, which sometimes results in a different expression if you ended the line with a semi-colon and without, I say that when people consider line endings to terminate statements, it isn't always clear how it should be handled. If the statement is long enough that I should break it into two lines, how do I bring it to the next line without accidentally marking the end of the statement, and how do I do it in a way that the compiler is guaranteed not to misunderstand my intention? If the answer is add more whitespace, then chances are, I won't use the language unless someone pays me. Everyone has a different style, and languages that try to dictate how many spaces I must use in order for it to have syntactic significance rub me the wrong way.

Indentation is good. The language absolutely requiring it, I don't know about that.

Edited by Ectara
1

##### Share on other sites

I favor the explicitness of semi-colons and brackets (or similar) in lower-level languages like C and its progeny, but dropping these things feels more-natural in higher-level languages like Haskell -- I suspect I feel this way because at some level low-level code tends to be a whirlpool of nested loops for whatever reason, but higher-level code tends to look more like pipelining and functional composition.

But it'd be fair enough to say that good code, or at least good interfaces, tends to approach a fairly functional, compositional style.

You could also do a hybrid system, where end-lines are interpretted as statement terminators unless a special character ends the line (Visual Basic does this, I think, or maybe it was a way to continue strings only), and to provide a statement terminator too, so that multiple statements can appear on a single line if it makes sense. This would obviously not please the camp that favors indentation-based scoping, but I tend to believe that giving programmers the choice is best. If a programmer isn't following appropriate conventions then they're not doing their job -- its a people problem, not a language problem.

1

##### Share on other sites

Also, Walter Bright, creater of the D programming language, just gave a presentation to the Northwest C++ Users Group last week about D's support for component-level programming that's relevent to the point I made aobut whirlpool vs. composition--which are his terms--and a great talk, regardless.

If you look at his example, you can really see how the style of the code would influence the argument for or against explicit statements and scoping.

0

##### Share on other sites

Nice work, even if just for the learning experience.  That said this seems remarkably similar to C or java with just a slight syntactic change.  What advantage does your language have over say just writing a VM for C?  Was there a reason you made your own over using one of the many out there?  Not that there's anything wrong with that, just curious.

btw: I'm with Ectara and Ravyne, in that I like braces and semi-colons.  I really don't like having forced formatting.

Edited by Ryan_001
0

##### Share on other sites

I prefer semi-colons and marking blocks with braces because it feels explicit and unambiguous. The statement will not end without something that marks the end of it, and blocks begin and end in only one way that is indisputable; considering things like JavaScript's optional semi-colons, which sometimes results in a different expression if you ended the line with a semi-colon and without, I say that when people consider line endings to terminate statements, it isn't always clear how it should be handled. If the statement is long enough that I should break it into two lines, how do I bring it to the next line without accidentally marking the end of the statement, and how do I do it in a way that the compiler is guaranteed not to misunderstand my intention? If the answer is add more whitespace, then chances are, I won't use the language unless someone pays me. Everyone has a different style, and languages that try to dictate how many spaces I must use in order for it to have syntactic significance rub me the wrong way.

Indentation is good. The language absolutely requiring it, I don't know about that.

The obvious way to extend statements to multiple lines is to have a continuation character like C's \ or matlab's ... . Also, when a statement is incomplete and a newline is reached, that can also imply continuation, although this forces a coding style that you may not want to force.

but I tend to believe that giving programmers the choice is best. If a programmer isn't following appropriate conventions then they're not doing their job -- its a people problem, not a language problem.

Perl's There's More Than One Way To Do It motto is a language problem. It means no one has intuition about what Perl code looks like. After all, there's more than one way to do anything. This makes it hard to read code written by other people, or even your past self. And since programmers often spend more time reading code than writing code, that's a big failing.

Now I'm not saying a language should not be flexible generally, but in this case the redundant indication of statement termination and code blocks is undesirable. A reasonable alternative could be to allow both: make semicolons optional, unless you have multiple statements per line.
0

##### Share on other sites

Nice work, even if just for the learning experience.  That said this seems remarkably similar to C or java with just a slight syntactic change.  What advantage does your language have over say just writing a VM for C?  Was there a reason you made your own over using one of the many out there?  Not that there's anything wrong with that, just curious.

btw: I'm with Ectara and Ravyne, in that I like braces and semi-colons.  I really don't like having forced formatting.

Well, the benifit of it is that even at this stage (just released version 0.03 bug fixes for compiler), you can grab it and make a simple 2d games with it (Check out the Break Out game I created with it, links on the project site). What I mean to say is, it is pretty straight forward  and you don't need to learn anything else (graphic library like OpenGL or DirectX) beside language  in order to write simple 2d games with the system. And since the syntax is very similar to C, anyone who has the knowledge of C, C++, java, or C# can just learn it in half an hour.

Another reason is portability, I am going to make VM for wide variety of devices.

Another reason is that it's open source, if you want any changes, you can tell me to add it (if I find it useful I will definitely add it) or just tweak the code yourself.

If the OP is still lurking around, here's my input:

Screw all this debate about semicolons and semantic whitespace and all the other religious nonsense that programmers will argue about.

Make the language you want to use. (Note that this is not the same as making the language you want to make. The idea of using it is critical.)

Thanks!!! That's what I plan to do.

0

##### Share on other sites

I am sure you are using this for learning but I don't really see the point in the language.

By looking at the documentation here is what I see.

1. Slightly cleaner version of C
2. VMed cleaner version of C
3. Took some style from C++ to clean up C
4. Not seeing any benefits of using over C

This is just my quick perspective.  I like curlies and semi colons as I am a ANSI C programmer I like it so much it is very clean, small, and fast.  Easy to understand what is going on and not nearly as convoluted as a lot of the C++ decisions.  I just don't see the need to recreate C.  There is no need to run C through a vm it is already super portable if written properly.  The language is tiny so it does not need to be re created.

Ultimatly I don't see the benefits you are giving me over C.  You have no garbage collection you are still using pointers with a different syntax etc....  If I wanted a cleaner language over C I could just go and use Googles GO.

I appologize if it comes off as mean I am not trying to be just a simple critique.  Writing a programming lang is a great way to learn some really cool stuff so keep up the good work.  On the other side your language does not solve a specific problem and is not different enough for me to really consider it in the future when it is mature.

To give you and idea of what I am talking about take into perspective google's GO language.

It solves a few specific problems.

1. Cleaner Syntax then C
2. Procedural (no OOP) like C but has namespaces for organization.
3. Does away with ugly header files
4. Allows closures and coroutines C does not
5. Allows better parallel programing through threading with goroutines
6. One of the few truly compiled to machine code languages that has garbage collection
7. makes systems level programming more friendly to new programmers
8. decently robust standard library

These are just a few of the things that make developers want to learn GO over C for systems programming.  It solves specific problems that people had with C while still keeping the things that people loved about C.  The syntax is also different enough to warrent learning something new.

Again keep up the good work making this language will teach you a lot about development.

1

##### Share on other sites

This looks like an ambitious project. Making your own language is one of the best way to learn a lot of programming. And now and then it will make a contribution the the computer science. Keep up the good work!

0

##### Share on other sites
1. Image as native data type? Wow. I made it a native-class in my system. I'd like to exchange some words on that.
2. operator+ operator-, "used to assign pointer". What is that? I see from the "pointer" description it's... I don't understand what. Some kind of autocast? It also seems to me your "pointers" are actually references.
3. I see you have while, but I don't see for. Oddly, I only have for, because I think it's more convenient. What made you take this decision?
4. I see your functions are like in C. To be honest, I think there's at least one very good reason to use the new func()->rettype syntax, which relates to type resolution. I'd like to hear your opinion!
5. Some functions in your standard library are fairly advanced (such as those involving drawing). By contrast, you have a "basic" rand(). Do you plan to improve support for random generation? In general, I'd like to hear something on your perspective for the future.
6. Are arrays a type or not? Can you inquiry about their contents/length etc?
7. I also thought using group instead of struct would make sense. But I couldn't quite make it (I actually only have class). What made you take this decision? I mean, struct is conventional wisdom (mere naming issue). Do you have support for functions taking a this pointer? (it appers not to me)
8. Inheritance. What's the result of group
group Foo {
int a;
}

group Oops : Foo {
int a;
}
9. You have threads? Man, that's outright scary! I mean, there are so much implications I don't even know where to start. Are you sure?
10. Are image objects "real"? I mean, if I assign an image object to another, will I copy all the pixels? That's going to be... well, like C++ I suppose.
11. Ok, there's startThread... and no other thread control?
12. I'm not even sure what's the deal with weak pointers.
13. You know what? I cannot actually do "Hello world" with per-frame changing color in my language ;)
14. Are you really sure you want to pass objects by value? It's a common source of grief in C++.
15. I'm afraid I don't understand the deal with passing by reference and group (in the "other" page).
16. Don't give people the layout of your image structure. Give them functions to operate on them as opaque data!
17. "If you use '=' copy one 'file' type to another, it will copy the address (like in the case of 'image' type)." What does that mean?
18. The way parameters are cast... it scares me quite a bit...
19. Ok, weakPtr is a cast. How does it work in the case of
group Parent {
int x, y;
}

group Child : Parent {
int z;
}

void test(pointer Child p) {
//body
}

Parent parent;
test(weakPtr parent);


I mean, it's a cast depending on function parameter type... to be resolved against overloading... ouch. And by the way, why should one downcast a struct to its parent?
I guess I missed the part of the documentation in which you stated groups are passed always by reference. Perhaps that's what you meant a few points above?

Having my own lang as well I am very interested in hearing different opinions!

1

##### Share on other sites

Also, Walter Bright, creater of the D programming language, just gave a presentation to the Northwest C++ Users Group last week about D's support for component-level programming that's relevent to the point I made aobut whirlpool vs. composition--which are his terms--and a great talk, regardless.

If you look at his example, you can really see how the style of the code would influence the argument for or against explicit statements and scoping.

I have to say D is looking fantastic and anyone looking to create a C-like language should take a very close look at it. Even with the C++11 enhancements, C++ feels downright ugly in comparison. Stuff like deep const, the way the language checks and infers function purity, being able to run any code at compile time if the inputs are const and outputs are deterministic, safer generic algoritm code thanks to ranges. And so on.
0

##### Share on other sites

Also, Walter Bright, creater of the D programming language, just gave a presentation to the Northwest C++ Users Group last week about D's support for component-level programming that's relevent to the point I made aobut whirlpool vs. composition--which are his terms--and a great talk, regardless.

If you look at his example, you can really see how the style of the code would influence the argument for or against explicit statements and scoping.

I have to say D is looking fantastic and anyone looking to create a C-like language should take a very close look at it. Even with the C++11 enhancements, C++ feels downright ugly in comparison. Stuff like deep const, the way the language checks and infers function purity, being able to run any code at compile time if the inputs are const and outputs are deterministic, safer generic algoritm code thanks to ranges. And so on.

I don't want to derail, but yes I think its a very interesting language and its got the benefit of hindsight in both correcting and evolving the C lineage of languages. I've followed it for many years, but haven't yet done anything serious in it.

Every so often I get the create-a-language bug myself, but then I go looking for inspiration and D, Scala, and Haskell are so close to my high-level ideas (devil's in the details, of course) that I never follow through--I figure the amount of difference between these and any language I might create would be too small to justify the effort, and I've written plenty of parsers and small languages so its not even worth it as an accademic exercise for me. I mean, it's terribly interesting, but I'd just end up re-inventing one of these with slight changes and different syntax, and I've got better things to spend my time on.

0

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account