Deciding the type of a custom language [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to b开发者_如何转开发e supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

I am thinking about small language specifically for graphs that would provide a lot of functionality to manipulate graphs and the like.

So when I was pondering over the syntax of the language, I read about the functional and the 'obvious' imperative paradigm. How does one decide what kind of a language style would be better? Which one would suit my use case better? I would appreciate answers with some good reasons and explanations.

EDIT: As for the audience for this language: I believe non programmers/researchers who have no prior programming experience, would still be able to use graphs would benefit from it.

EDIT: If you feel that this question is not useful, you are open to vote it down, but please add a comment as to why you feel it deserves it. It might help me in going a long way.

---

Not really an answer to most of your questions, but I've designed a few toy languages (and thought about some non-toy ones). I find it helpful to think about the sorts of things I expect to be done in the language, and then try to actually write some sample programs before designing it, to see how the concepts come out.

It can be hard not to get caught up in extraneous detail like what needs parentheses, exactly how you indicate structure, how you declare variables and types (if you do), etc etc. You're not really interested in syntax at this stage (which is a little weird when you're writing a sample program), so it's closer to pseudocode. But it can help to solidify what primitives you need, what are the concepts that users of your language will be thinking in.

If you're still weighing up fundamental choices like imperative vs functional, try doing it several different ways. For example, what are the building blocks your language would need to provide to write graph transformations in an imperative style? What about in a functional style? Doing this can help you get a feel for what works well in each approach, what problems you'd need to solve for each approach, and so on.

---

IMO when you try design some simple language, you usually have some idea who will use it and what it will do. Then, try to 'use it' first, think about how writing in it should look like. Don't think about paradigms and that stuff - it's something you start to worry when your language goes larger - but maybe it wont:) It can end as a simple interactive shell with basic mathematical-like syntax.