Designing good concrete syntax is ridiculously hard. And unfortunately, while the best syntax in the world can't save a lame language, bad syntax can (has) doom(ed) good languages.
If this is a toy language, "full speed ahead" say I! But if you want to create a practical language for people to use, I have the following observations based on my personal experiences. YMMV:
- focus on the semantics and abstract syntax of your language. This is the core of a language, and how people will learn and understand it. Figure out how elements of the language can be defined, combined, and abstracted. Absolutely do not let concrete syntax dictate the semantics or abstract syntax of your language.
- keywords, braces, semicolons -- these are all totally irrelevant as far as abstract syntax and semantics are concerned. There can be multiple concrete syntaxes for the exact same language.
- implementing features as libraries is usually preferable to implementing them as syntax
- syntax is hard to fix
- syntax is hard to extend
- syntax is hard to compose
- syntax is not accessible at run-time
So my answer to your question is: design your abstract syntax and semantics first. Without seeing those, it's very hard to come up with a good concrete syntax. Once you have those, a concrete syntax should be much easier to derive.
Or you could just go with Lisp. ;)
Also, since you mentioned
I want it to make sense by just reading the code, I should point out that designing a syntax that reads like plain English, yet is also simple, unambiguous and powerful has never been done (to my knowledge). I do not believe this is possible (although I hope I am wrong).