What I learned at the Emerging Languages Camp
journal.stuffwithstuff.com
What I learned at the Emerging Languages Camp
1–10 of 16 posts
Re: What I learned at the Emerging Languages Camp
#2The author also presented on his own language, Finch (http://bitbucket.org/munificent/finch). It was a great presentation, and the language implementation is incredibly easy to read and understand. I don't see using Finch for any real projects (like many of the languages presented) but it was inspiring to see so many people presenting well-crafted labors of love.
For someone interested in programming language design or implementation, Emerging Languages Camp had a lot to offer. It received universal praise from everyone I talked to.
Re: What I learned at the Emerging Languages Camp
#3Good article, but I have to nitpick here:
Any well-versed programming language person can tell you about both recursive-descent parsers and generated parsers. They’ll also tell that generated parsers are the “right” way to do that.
Most of the time that advice will save you from wasted effort, but sometimes I think it keeps people from going down paths that may actually be fruitful. Sometimes the thing that everyone knows is true isn’t. (For example, every language I know of with a lot of real-world users actually does use a hand-written parser.)
Recursive descent parsers are good when 1) you have a simple grammar and 2) you want fewer dependencies. Most lisps have hand-written recursive descent parsers because lisp grammar is easy.
Also, MRI ruby (aka CRuby1.8) uses a generated parser.
Re: What I learned at the Emerging Languages Camp
#4Glad I read this, because I learned about Frink: http://futureboy.homeip.net/frinkdocs/ and the FAQ: http://futureboy.homeip.net/frinkdocs/faq.html
This guy knows units of measurement.
Re: What I learned at the Emerging Languages Camp
#5 I would prefer a conference about emerging features in languages, since many languages only differs in superficial aspects. Is better to located what new features are needed.
Re: What I learned at the Emerging Languages Camp
#6I would prefer a conference about emerging features in languages, since many languages only differs in superficial aspects. Is better to located what new features are needed.
There were a number of talks in that vein. Rich Hickey's talk about his experimental "pod" feature in Clojure for safe scoped mutation, Joe Pamer's talk about making F# suitable as a first-class .NET language, and Jonathan Shapiro's talk about the correctness constraints guiding BitC's design all focused more on problem domains and the features necessary to fill those domains than superficial language features.
Re: What I learned at the Emerging Languages Camp
#7Good article, but I have to nitpick here: Any well-versed programming language person can tell you about both recursive-descent parsers and generated parsers. They’ll also tell that generated parsers are the “right” way to do that. Most of the time that advice will save you from wasted effort, but sometimes I think it keeps people from going down paths that may actually be fruitful. Sometimes the thing that everyone…
I think the recursive descent ones are also worth favoring when you want to have more informative error messages
Re: What I learned at the Emerging Languages Camp
#8Good article, but I have to nitpick here: Any well-versed programming language person can tell you about both recursive-descent parsers and generated parsers. They’ll also tell that generated parsers are the “right” way to do that. Most of the time that advice will save you from wasted effort, but sometimes I think it keeps people from going down paths that may actually be fruitful. Sometimes the thing that everyone…
Yes, I like writing recursive descent parsers but I don't know of any in "industrial" use, beside the lisp parser you just mentioned.
I'd like to know if there are more.
Re: What I learned at the Emerging Languages Camp
#9Good article, but I have to nitpick here: Any well-versed programming language person can tell you about both recursive-descent parsers and generated parsers. They’ll also tell that generated parsers are the “right” way to do that. Most of the time that advice will save you from wasted effort, but sometimes I think it keeps people from going down paths that may actually be fruitful. Sometimes the thing that everyone…
Yes, I like writing recursive descent parsers but I don't know of any in "industrial" use, beside the lisp parser you just mentioned. I'd like to know if there are more.
Industries using a recursive descent parser: http://www.edg.com/index.php?location=customers_oc
Re: What I learned at the Emerging Languages Camp
#10Good article, but I have to nitpick here: Any well-versed programming language person can tell you about both recursive-descent parsers and generated parsers. They’ll also tell that generated parsers are the “right” way to do that. Most of the time that advice will save you from wasted effort, but sometimes I think it keeps people from going down paths that may actually be fruitful. Sometimes the thing that everyone…
Yes, I like writing recursive descent parsers but I don't know of any in "industrial" use, beside the lisp parser you just mentioned. I'd like to know if there are more.
LLVM's clang uses a recursive-descent parser to parse C, ObjC, and C++ (http://clang.llvm.org/features.html#unifiedparser).
Clang is the "C Language Family Front-end", which means we intend to support the most popular members of the C family. We are convinced that the right parsing technology for this class of languages is a hand-built recursive-descent parser. Because it is plain C++ code, recursive descent makes it very easy for new developers to understand the code, it easily supports ad-hoc rules and other strange hacks required by C/C++, and makes it straight-forward to implement excellent diagnostics and error recovery.