I'm currently toying around with a very large project. A interpreter for a simple scripting language. After weeks of planning, I decided that the best course of action would be to prototype part of the interpreter in Python, and then port that code into C.I started off by writing a simple lexer based upon some EBNF I had written, using Python. The lexer needed to handle state, so I made heavy use of Python's OOP tools. Once I was satisfied with my prototype, I decided to have a go at porting it over to C.Python, of course, is object oriented and has classes. While C on the other hand, has not such concept. I begin to wonder whether I should re-write my lexer. It had heavily relied on the state provide by classes, but I of course couldn't use classes in C.So I began re-writing my entire lexer from scratch to use only functions and global variables. This started to produce code which was a bit verbose, and hard to debug. I stopped and wonder whether I was making the right call. Should I be forced to ignore features of one language just because the language I plan to solidify the code in, does not have such features?.This may seem like an easy no, but what about the case in which a prototype largely relies on a certain feature of a language(such as mine)? Should you really spend hours trying to make up for the lack of such features?But the flip side could just as easily be argued. Why should you be forced to write unidiomatic, verbose code in one language, just to compensate for the lack of such features in another?Since @MichealDurrant had requested it, I'll give my reasons for using C:For speed For portability 3 For learning purposes I prefer the language in general.C seems to be the de-facto for creating programming languages. Numerous languages have been created in C.
Should I ignore features of one language when I plan to port my code to another which doesn't have such features?
design;programming practices;language agnostic;porting;features
Based on my experience writing compilers and related tools in C and similar languages, I would NOT choose to write a compiler in C if I had any other, better choices. And in 2016, there are plenty of better choices. But, it's your compiler, and YMMV.The TL;DR backstory:We should forget about small efficiencies, say about 97% of the   time:   premature optimization is the root of all evil.                                            Donald KnuthHe goes on to say Yet we should not pass up our opportunities in that critical 3%. Assuming you take Dr. Knuth's advice in such matters (and you really should), the key question is therefore: Are you in that 3%?Seems doubtful. C can run faster on low-level code than any Python, Perl, or PHP ever will. It is a great medium-level language, excellent at rendering structured code into machine instructions. For those writing core compilers, databases, and middleware, C is a solid choice. But for a scripting language? That's still in development? That...seems premature.In my experience, Python has adequate speed even for performance-focused work. I run programs that parse, analyze, and transform millions of text records. If everything were written in pure Python, it probably wouldn't be fast enough. But many tasks--parsing text or XML, churning through mounds of data, etc.--those are almost always handled in C already. Modules like Pandas, NumPy, and LXML do their heavy lifting at the lowest, most optimized level possible. Python takes advantage of their optimizations, but in a very clean, standardized, high-level language. I have rarely found a need to go elsewhere. When I have, very narrowly targeted optimizations in C or Cython, with main program flow managed in Python, has been excellent. Having stared at tons of C over the years (operating systems, compliers, middleware, applications, utilities), and having written some of same, I challenge the idea that C is especially portable. It is compared to the era from which it emerged. But that was the 1970s and 1980s. The competition was almost entirely non-portable. C remains extraordinarily exposed to differences in platform byte order, word length, addressing semantics, and operating system flavors/versions. Code meant to run many platforms is often littered with #ifdef and direct platform knowledge. It's ugly. In the end, C is not very portable in comparison to more modern languages such as Java, Go, Python, and JavaScript.So if you like C, want to study it, or want to work there, God bless. But as you're already finding, it's not a particularly supportive environment by modern standards. Classes, dictionaries, flexible lists, good and simple string matching, problem-oriented data structures like set and Counter, easy exception handling, strong module support.... The list of valuable things that C lacks is very long. You might be able to get some higher-level features back if you use a framework like Cello. Still, C is the best design of 45 years ago; it lacks the many advances in ease, flexibility, robustness, and structure than have emerged since. You should weigh the advantages of C's potentially greater execution speed against the less-supportive environment, longer development time, lower likely reliability, and other factors. In 1970 or 1980, system resources were extremely tight, so optimize-optimize-optimize made sense. In this day of multicore processors and gigabyte memories even on smartphones, you can legitimately consider optimizing attributes other than performance. Time-to-market, program sophistication, reliability, maintainability--there are a lot of things that you can reasonably optimize in Python (or another high level language) that you can't readily optimize in C.