Ok so Im doing a project about interpreters for college, and need people to answer questions for it.

If youve ever made an interpreter could you answer these, thanks!

1) how long have you been in the computing industry?

2) what got you into interpreters?

3) what do you think is the hardest part about creating an interpreter?

4) what do you think aare the best practices for creating an interpreter

5) do you think its best to create a language or create your own?

1) Decades.

2) Either some configuration files expanded, or some existing specification was to be implemented.

3) Making it robust.

4) It should perform a syntax check on the full input file(s) and reject invalid input. At least, the dev gets a clear indication what is wrong, and it avoids erosion of standards.

If applicable, the syntax should be defined so that valid, but unknown elements have a defined behaviour as to make older installs somewhat compatible with new features (e.g. treating <picture> as <div>).

Still, there should be some warning mechanism so that typos won't go unnoticed. Variable declaration should be mandatory, or else typos make e.g. new variables, and that invites bugs.

5) If at all possible, don't create a new language. It will lack maintainability because you won't get devs on the market who already know it. Also, the result will probably suck because language design is hard to do well.

But you could e.g. allow a subset of an existing language.

@Fast-Nop thank you!!

Is this an interpreters survey or something?

1. Student, soon to be masters
2. Lisp
3. Ensuring correctness throughout the interpreter and language design (i.e. it does what it's supposed to do and nothing else).
4. Interpreters are way too varied. It depends on what all you want your language to do. You can have an absolutely basic interpreter that just calls appropriate C functions, or a really advanced one with JIT compiling and so on. Protip: functional programming languages rock at transforming code, but not so much at building a runtime environment. Mix the two and it's awesome.
5. Wut?

Also, another interpreter enthusiast: @lxmcf

@Fast-Nop I would disagree with your 5th point, especially since OP's learning. Try making a language, it's bloody difficult and you will end up making a ton of mistakes, but those mistakes are exactly what will teach your the principles of good language design so that you understand why successful languages work the way they do. Then repeat. It's an iterative process and even though you might end up with a clone of an existing language the process is very important.

If for production use then of course, use an existing language. But then it would probably have an existing interpreter too.

@RememberMe enthusiast? Now that's a bit much but hey I'll take it!

1. Debatable how you look at it, in a serious capacity I would say 6 months after I got on devrant?
2. Building a game engine and wanting to build a simple scripting language
3. Logical number processing and lexing into tokens mostly because once you decide on a method you're essentially stuck unless you rewrite
4. Keep your code clean and use OOP for the love of god!
5. Yes? As a recommendation I would start at building a parser for a data type like JSON or INI

@RememberMe Sure, for a learning project, everything is fine because it's meant to be thrown away. Or for personal projects that you actually use, but the impact stays limited.

But the question seemed to be from the POV of the computing industry, at least that's how I interpreted (haha) the first item.

@RememberMe @lxmcf thanks guys!

@lxmcf OOP is only useful if the problem domain has objects. E.g. if the interpreter is supposed to be object oriented itself. Or things like GUIs or physical simulations, many games included.

Otherwise, OOP leads to the typical nebulous classes and abominations like controller handler factory managers in any combination and permutation. That's what happens when OOP is shoehorned onto a problem that it doesn't match.

@Fast-Nop you make a good point, I just recommend OOP for organisations sake mostly, but I am biased because I primarily work in OOP languages