Hi Matthias and Vincent, First, thank you for your time reading the article and writing your feedback.
> Matthias Felleisen wrote: > > Leandro, > > Before I say anything else, I really enjoyed your "playing the game > with plt redex”... Thank you for the kind words :) > Your new essay [...] show[s] how to take a program in Racket down to > one in a by-value version of Lambda Calculus. Why stop there? I didn’t: https://www.leafac.com/prose/programming-language-theory-explained-for-the-working-programmer--principles-of-programming-languages/#the-essence > Do we really need to go through all of this to explain that “creating > programs so that our successors can read them” is the purpose of a > language? “Creating programs so that our successors can read them” is an important takeaway from the article, but it isn’t the major one. The main point is that data communication is the essence of computation, and, thus, of programming languages (see the section I linked above). Arbitrary data communication is the common factor between the Lambda Calculus, SKI calculus, tag systems, and any other Turing complete system. Maybe this argument didn’t get across as clearly as I intended, and I’d welcome suggestions on how to improve this. But there’s a hidden agenda to this article. Before I got into my Ph.D. program, I was a working programmer interested in programming-language theory. I found topics such as Church encoding, Lambda Calculus and the Halting Problem fascinating. But I couldn’t read most of the texts on these topics because they used notation and jargon beyond my understanding. I got into a Ph.D. program and invested the last three years in learning how to read through the funny symbols. And I what found were some of the most interesting ideas in human knowledge. Now I’m writing to myself in 2013, unpacking these ideas in a way that working programmers can understand. The article you read is the first in a series, that I’m calling “Programming-Language Theory Explained for the Working Programmer.” To this point, this is the only published article in the series, but I’m already working on the second, which will be about interpretation. Then the next articles will be about intermediary representations (CPS and ANF), and program analysis (k-CFA). Where am I heading with this series? I want to explain my research (https://pl.cs.jhu.edu/projects/demand-driven-program-analysis/) in terms that working programmers can understand, bridging the gap between industry and academia. To explain my research from scratch, I first have to invent the universe. “Programming-Language Theory Explained for the Working Programmer” is me inventing the universe. (Also, it’s an opportunity for me to practice technical writing. English isn’t my first language and I received consistent feedback that I need to improve this skill.) So, language design and the expressive power of programming languages are interesting topics. But my article isn’t dedicated to exploring them. The secret is that it was just an excuse to introduce the Lambda Calculus, which I need to explain program analysis later. Along the way, there are many interesting ideas, like language design and the expressive power of programming languages, and that’s why I hint at those as well. In any case, your insights about language design and DSLs are much appreciated. I’m definitely reading the citations you mentioned. Specially because, when I put by software engineer hat, I’m entirely in agreement with the Manifesto. I’m an advocate of DSLs myself :) I’d love to continue having your feedback on this series. When I have the next articles ready, can I keep sending them your way? I expect I’ll have one per month. Best. -- Leandro Facchinetti <lfacc...@jhu.edu> https://www.leafac.com GPG: 0x5925D0683DF3D583 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
