In my humble opinion -- admittedly never having "developed" a programming language myself -- you shouldn't be designing "by syntax example", adding some sugar here, some there.
You should sit down and create a list of features, goals and principles that you want to see implemented in your new language. Then write a formal syntax, and then implement a parser for that... (The parser, really, is the easy part of it, especially when based on a complete formal syntax. That much I know for a fact, because I am maintaining a parser for a non-trivial DSL...)
I do have goals for ExC;
- I want it to be a programming language which promotes code organisation and modularity
- I want it to be a programming language suitable for both low level work and high level work
- I want it to be a programming language which is decently easy to write (i.e. it doesn't look like a massive regex like some esolangs)
- I want it to be a programming language which can compile to machine code to maximise portability
- I want it to be a programming language which doesn't require a run-time library or pre-existing memory management etc.
These are the features planned to be in ExC:
- function, variable, constant and structure definition
- package-based code management system with member hiding and remote referencing of functions, variables, constants and structures
- traditional if, while and for loops
- single or multi-dimensional arrays
When I'm working on the syntax or taking suggestions from others, I keep these goals in mind, and look for the optimal way to implement ExC's planned featureset. At the moment, pointers are proving tricky, but I have a good idea what I want to do for the other features.