> On Aug 23, 2017, at 9:49 PM, Alex Harsanyi <alexharsa...@gmail.com> wrote: > > As someone who managed to write a 30000 like Racket application without using > macros, I think they are overrated for application development. Macros are a > powerful and necessary feature for designing or extending a language, but > most people are better served by just using existing, well documented > languages. > > I think Racket is a really good language and can be directly used to write > useful applications. Yet new users are encouraged to start using the most > difficult to understand feature of Racket for their simplest of projects.
Yes, Racket is a good language. But let me point you to the blog of a reflective developer, and I consider reflective developers the best of their kind: https://medium.com/@daveford/80-of-my-coding-is-doing-this-or-why-templates-are-dead-b640fc149e22 This write-up is completely unrelated to Racket, but like many others out there, this developer has recognized an essential idea that is emerging in the world of sw dev: problems are best solved on their own terms and that is best done with a multitude of languages — but all these languages must live in the same ecosystem so that it is easy to glue the problem-specific components together. This, in essence, is also the Racket manifesto (http://www.ccs.neu.edu/home/matthias/manifesto/) also available as a PDF article for CACM (http://www.ccs.neu.edu/home/matthias/Tmp/cacm.pdf preferred version). If you would like to see a concrete example, fully worked out, see the ICFP paper on constructing a domain-specific language for scripting the production of videos (say RacketCon presentations): https://www2.ccs.neu.edu/racket/pubs/#icfp17-dnff At the surface, this could be done as a piece of two modules: the surface language (boring) and the run-time library that connects to existing NLVE systems. But as it turns out, if you truly take the slogan seriously, you can easily see how we build this application as a composition of EIGHT (8) DSLs, three used at the surface (Video, Typed Video, and Docu Video) and five below, inside the application. Like Neil, I don’t have any good metric other than “lines of code eliminated/never written”. Based on my personal experience, I find uses for small DSLs or at least bundles of macros everywhere. My most recent example is the construction of a test suite for a distributed board game project. I noticed that I was writing a lot of variations of setup/test/tear-down that were reasonably compact (say 10-15 lines per unit test) but hardly readable. So I rewrote it with a DSL that allowed me to articulate each test as a description of a game scenario. I demoed it to my class, made up of students who do not know Racket. I showed the test suite, I explained the cases for a particularly difficult aspect, and a student spotted a missing corner case. The class was able to dictate the missing test case to me — and of course the code broke. (It was also fixable in about 2 minutes.) If I had demoed the rackunit cases, they would not have been able to formulate the test case — because they simply don’t know (enough) Racket. Time to think — Matthias -- 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.
