Jump to content

  • Log In with Google      Sign In   
  • Create Account

Writing my own programming language


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
17 replies to this topic

#1 Prads   Members   -  Reputation: 139

Like
4Likes
Like

Posted 27 February 2013 - 02:26 AM

Hello, I have been working on this project for some months now and I
want to show it to other people. Basically speaking, it's a programming
language which can be compiled and ran using a virtual machine. Here's a
detailed explanation I wrote in my blog:


    
Quote:

            
                So, in last blog post I gave small introduction to my current
project that I am working on. In this blog I want to release the first
version of my current project. You can grab it from here: http://www.pradsprojects.com/despair.html

So, this piece of software that I wrote is a system to write portable
programs. It has its own programming language and the program that are
compiled can be executed using a Virtual Machine. The system isn’t
mature and lot of things are lacking but I hope to develop it further in
the future.

Let me talk a little about how this system works. You write a program
using its programming language (here’s the documentation of programming
language: http://www.pradsprojects.com/despair...ion/index.html)
then compile it using compiler tool that I have written. The compiler
generates a file with ‘.dbin’ extension which can be executed using the
Virtual Machine.

I have created a small IDE for developing program for this system
which you can download it from the project site (the one that I gave you
on the top). IDE consist of editor to write and manage source code
(which is fairly basic at the moment, no syntax highlighting for the
moment sorry), a compiler to compile the source code and a virtual
machine to run the compiled file.

Alternately, if you don’t want to create programs for the system but
want to run program created by others, you’re going to have to download
the VM from the project site. There are two types of VM for Windows OS:
interpreter version and JIT version (Dynamic Recompiler). The JIT
version is faster than interpreter version though I am still not very
happy with the JIT performance, I think it can be improved more. I will
port the JIT version to Linux later.

I want to create the Virtual Machine for various different platforms
like android, iOS, MacOS etc so that the program written using
despairLanguage can be run in different platforms. Currently the VM
works in Windows and Linux.

P.S: The software is open source and is on github. Links are on the project site.
            
        


So, I just wanted you guys to look at it and play around with it. Some feedbacks (good or bad) is highly appreciated.

Thanks!


My first 3D game: Click Here

Sponsor:

#2 King Mir   Members   -  Reputation: 2000

Like
0Likes
Like

Posted 27 February 2013 - 02:53 AM

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



#3 Prads   Members   -  Reputation: 139

Like
0Likes
Like

Posted 27 February 2013 - 03:07 AM

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...


My first 3D game: Click Here

#4 King Mir   Members   -  Reputation: 2000

Like
0Likes
Like

Posted 27 February 2013 - 03:33 AM

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.


#5 NightCreature83   Crossbones+   -  Reputation: 2827

Like
0Likes
Like

Posted 27 February 2013 - 05:00 AM

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.


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#6 King Mir   Members   -  Reputation: 2000

Like
1Likes
Like

Posted 27 February 2013 - 08:21 AM


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.

#7 Ectara   Crossbones+   -  Reputation: 2970

Like
1Likes
Like

Posted 27 February 2013 - 01:38 PM

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, 27 February 2013 - 01:54 PM.


#8 Ravyne   GDNet+   -  Reputation: 7409

Like
1Likes
Like

Posted 27 February 2013 - 02:03 PM

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.



#9 Ravyne   GDNet+   -  Reputation: 7409

Like
0Likes
Like

Posted 27 February 2013 - 02:11 PM

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.



#10 Ryan_001   Prime Members   -  Reputation: 1401

Like
0Likes
Like

Posted 27 February 2013 - 02:17 PM

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, 27 February 2013 - 02:23 PM.


#11 King Mir   Members   -  Reputation: 2000

Like
0Likes
Like

Posted 27 February 2013 - 02:42 PM

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.

#12 ApochPiQ   Moderators   -  Reputation: 15765

Like
8Likes
Like

Posted 27 February 2013 - 03:27 PM

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.)

#13 Prads   Members   -  Reputation: 139

Like
0Likes
Like

Posted 28 February 2013 - 03:50 AM

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!!! smile.png That's what I plan to do.


Edited by Prads, 28 February 2013 - 04:21 AM.

My first 3D game: Click Here

#14 blewisjr   Members   -  Reputation: 622

Like
1Likes
Like

Posted 28 February 2013 - 09:08 AM

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.



#15 larspensjo   Members   -  Reputation: 1540

Like
0Likes
Like

Posted 02 March 2013 - 03:25 AM

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!


Current project: Ephenation.
Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

#16 Krohm   Crossbones+   -  Reputation: 3119

Like
1Likes
Like

Posted 02 March 2013 - 12:04 PM

  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!



#17 Yrjö P.   Crossbones+   -  Reputation: 1412

Like
0Likes
Like

Posted 03 March 2013 - 09:13 AM

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.

#18 Ravyne   GDNet+   -  Reputation: 7409

Like
0Likes
Like

Posted 04 March 2013 - 08:04 PM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS