I was hired (a long time ago) to write a language for a Very Large Telco Equipment Supplier in Canada in order to support their automated regression testing effort for their digital telephone switches.<p>It was called, ingeniously enough, "T" (no, not <i>that</i> "T"). As far as I (and cursory Google searches) know, it was never released to the adoring public.<p>I used lex and yacc (half jokingly referred to as 'ick' and 'yuck') and K&R C for the compiler and VM.<p>The particular type of testing we were targeting involved writing test cases that would read/write over serial lines to a telephone switch's console program. Therefore, the language needed to have good serial/terminal I/O, and it needed to have amazing string/pattern matching.<p>I wrote two features that I am still particularly fond of:<p>- regexps were a built in type. Strings were written like 'hi there' and regexps were written like `hi ..ere` - supported standard unix regexps<p>- associative arrays. Lots of languages have these now, like python's dict<p>The cool thing about it was how we tried to allow strings and regexps have a polymorphic relationship at the language level. The statements:<p><pre><code> x == 'some string' or x == `some [^t]ring`
</code></pre>
would be valid for strings in x, though the regexp had other operators that didn't make much sense with strings. It got really interesting when we combined the regexps with the associative array:<p><pre><code> dict['hello'] = 4
dict['help'] = 2
dict[`he.*`] == [2, 4] # true</code></pre>
If you’re thinking of writing a language in earnest, you will create something much more valuable if you start from a novel semantics, and only then come up with a syntax to express those semantics, than if you were to start from syntax.<p>The world does not need yet another reskin of Java, but it could use new programming paradigms and new ways of solving problems.<p>As a learning exercise, implementing a language is worthwhile simply to gain the understanding that languages are <i>not magic</i>. To boot, you’ll pick up loads of useful techniques in the realms of parsing, data flow analysis, error reporting, and optimisation.
The author says he turned to Coursera, but doesn't mention the course(s) he took, but I'm going to guess it's the the 'Compilers' class from Stanford[0]. I've heard good things about the course and the lecturer (Alex Aiken) so I really wanted to take the course while it was being offered but was too busy last year. I hope they offer it again this year.<p><a href="https://www.coursera.org/course/compilers" rel="nofollow">https://www.coursera.org/course/compilers</a>
Another interesting thing to try (and maybe complementary as well) is building an interpreter or compiler for a language you like, trying to match the spec and feature set as closely as possible, and (hopefully) gaining more insight into the tradeoffs the language designers made when deciding why things are the way they are.
I wrote this a while back on creating your own language: <a href="http://digitalmars.com/articles/b89.html" rel="nofollow">http://digitalmars.com/articles/b89.html</a>
If you are a developer and you have never written a language, you owe it to yourself to do this at least once.<p>Writing a language (lexical, syntactic, semantic phase and then code generation) will teach you an incredible amount of things in much less time it would take you to read about these things.<p>What your language looks like is completely irrelevant, this is strictly about learning from the journey.<p>And once you've done that, make sure to mention it in your resume: I, for one, will instantly give you brownie points if you mention in your resume that you wrote a language.
I've been working on a programming language in my spare time, also. I call it OWL. Its not quite ready, but here's a link anyways: <a href="https://github.com/bsurmanski/wlc" rel="nofollow">https://github.com/bsurmanski/wlc</a><p>OWL aims to be a low level object-oriented language without a garbage collector (albeit with reference counting).<p>The best 'example' program using OWL right now is a game I made for the 48 hour game jam, Global Game Jam 2015: <a href="https://github.com/bsurmanski/ggj2015" rel="nofollow">https://github.com/bsurmanski/ggj2015</a><p>I agree with the poster that making a programming language from scratch is a great way to explore programming. On top of that, its a great experience seeing able to implement all of those features you wish were in your favorite language (or find out why they aren't).
I've recently discovered PEG.js [0] and prototyped a small DSL in the browser [1]. Amazing stuff! I've dealt with ANTLR [2] before, but PEG.js feels so much nicer although it may not be as powerful!<p>[0] <a href="http://pegjs.org/" rel="nofollow">http://pegjs.org/</a><p>[1] <a href="http://pegjs.org/online" rel="nofollow">http://pegjs.org/online</a><p>[2] <a href="http://www.antlr.org/" rel="nofollow">http://www.antlr.org/</a>
I always wonder about the final conversion to assembly. Do you really need to learn all the instructions, the linking, the binary formats and all that stuff ?
When your top-down parser gets caught in an infinite loop, you'll need to convert the left recursion to right recursion. See here: <a href="https://en.wikipedia.org/wiki/Left_recursion#Removing_left_recursion" rel="nofollow">https://en.wikipedia.org/wiki/Left_recursion#Removing_left_r...</a><p>Writing a compiler is a significant amount of work and should be pre-researched to avoid issues like the above.
I was reading something similar here about creating your own language using LLVM (and also using the Ruby bindings for LLVM as opposed to C++) ... <a href="http://macournoyer.com/blog/2008/12/09/orange/" rel="nofollow">http://macournoyer.com/blog/2008/12/09/orange/</a>
I'm curious how people feel about syntax. I tend to think everything should be written in sexp (I like [s]ml syntax too though). Much like this <a href="http://cs.brown.edu/courses/cs173/2012/book/Everything__We_Will_Say__About_Parsing.html" rel="nofollow">http://cs.brown.edu/courses/cs173/2012/book/Everything__We_W...</a><p>Maybe I'm missing something, how many people felt that syntax made an idea pop differently and was part of the understanding ? To me it's often the opposite, it conflates too many things in a few symbols and then you waste time discussing corner cases.
Inaccurately, programming language = syntax + semantics.<p>Do not waste your time on syntax, if you are going to create a new language, rather than a parser.<p>I'm not saying that syntax is not important. But I feel semantics deserves much more attention.
Yes! I agree entirely, which is why I've been diving deep into creating (and playing with) new languages lately. Turns out a lot of problems that I have to solve at work can be fit into a parsing problem too, so it's not just all theoretical, but the big part of learning how to build languages is appreciating how the ones I use every day work; I can extend them, understand bugs, and push them to their limits. I couldn't do that prior: I always thought it was just black magic that greying neckbeard wizards did off in some ivory tower!
"that types are often a great name for variables, which both the programmer and compiler can use to easily and effectively understand most common code."<p>This hit me, what if variable names CONTAIN types? int__i = 1<p>And of course, it can be made optional. I will much prefer to do optional typing in the var name itself rather than the ugly syntax that guido has proposed with python.
the best happy-accident ... Months and months later, I realized that ... thanks to this simple idea, I could ...<p>That sentence is in every act of creation - something new just spawns something else that was not possible before the original act.<p>It's marvellous to see and indicates he is on the trail of something good - all the best.
I scrolled through the article and found some attributes of a language that is probably created by the author. But where are the rewards? I'm confused.
I wonder how much fun one could have with OMeta <a href="http://tinlizzie.org/ometa/" rel="nofollow">http://tinlizzie.org/ometa/</a> ?