- Design for Yourself and Your Friends. "If you look at the history of programming languages, a lot of the best ones were languages designed for their own authors to use, and a lot of the worst ones were designed for other people to use."
- One of the reasons I've been feeling overwhelmed by this project (besides the sheer number of ways to write pseudocode in general) is trying to think of ways that other people would write pseudocode. I should just write this tool for me and the kind of pseudocode I use, and I can extend the project for more general use in the future if I want to continue to work on it.
- Aim for Brevity. "I think almost anything you can do to make programs shorter is good."
- I think pseudocode is generally not very verbose, but this seems good to keep in mind.
- Speed Comes from Profilers. "What they need is a language that can show them what parts of their own programs need to be rewritten. That's where speed comes from in practice. So maybe it would be a net win if language implementors took half the time they would have spent doing compiler optimizations and spent it writing a good profiler instead."
- I don't know if this will be applicable to my project, but again, it seems good to keep in mind.
- You Need an Application to Drive the Design of a Language. "This may not be an absolute rule, but it seems like the best languages all evolved together with some application they were being used to write."
- My original idea was some sort of translator tool, but a language looked to be the right way to solve the problem. So I think I'm good here. My language will be written to create the pseudocode to real language application.
- A Language Has to Be Good for Writing Throwaway Programs.
- Definitely. I mean, that's the whole idea behind pseudocode, really.
- Object-Oriented Programming. "I realize this is a controversial one, but I don't think object-oriented programming is such a big deal. (...) What this means for language design, I think, is that you shouldn't build object-oriented programming in too deeply."
- I hadn't really thought about OOP in my "language", but it is the paradigm that I've been taught... I'm undecided on this (although, I don't think classes/functions are very prevalent in most of the pseudocode I've seen or written. At least, not explicitly)
I also found this wikiHow, which was surprisingly helpful. It pointed out a lot of things that I hadn't thought of, like semantics (too many to list here). Specifically, I found this to be worth thinking about: "Be careful, in order to keep your language in the Context-Free language category or something inside it, your parser generator and you will appreciate it later on." I'm going to have to walk a fine line between syntax that's easily parsed and syntax that captures the spirit of pseudocode. It also emphasizes designing the language carefully before trying to implement anything. Since I don't know much about programming language design I would like to spend time reading up on that and compilers before I actually design my "language".
And finally, this is an excellent Stack Overflow-esque question and answer that brings up a lot of good points. Once again, design carefully -- "write down precisely what the rules are for determining what is a legal and illegal program (...) Write down these rules as precisely as you possibly can.". And this was intriguing advice, considering my third option for the project: "One of the best ways to get started writing a compiler is by writing a high-level-language-to-high-level-language compiler."
I have a lot to chew on now. I think next I'm going to try to find some more resources on actually designing and implementing a new programming language. And also start narrowing down what I actually want my syntax to be (with examples!).
No comments:
Post a Comment