
The Racket Manifesto - nickmain
http://www.ccs.neu.edu/home/matthias/Tmp/manifesto/
======
michaelsbradley
The book _How to Design Programs_ [1], with its "student languages", is an
excellent example of how languages created with Racket can be used to achieve
specific goals (or solve specific problems). In the book's case, the goal is
to provide a programming environment for explaining and exploring a
successively refined software design recipe.

Also, the _Manifesto_ and Racket's documentation (and HtDP) are written in
Scribble[2], another language built with Racket.

[1]
[http://www.ccs.neu.edu/home/matthias/HtDP2e/](http://www.ccs.neu.edu/home/matthias/HtDP2e/)

[2] [http://docs.racket-lang.org/scribble/](http://docs.racket-
lang.org/scribble/)

~~~
muraiki
I can't praise HtDP enough (disclaimer: I've only done through chapter 4 of
the first edition). Still, what I did was sufficient to fundamentally change
me as a programmer.

When I first began learning how to program I started off with Python using
some courses on Udacity. But somehow I found HtDP (I think via HN) and it
really taught me, well, how to design programs.

It also made thinking functionally my default mode of thought. I remember
hearing about FP and asking a friend experienced in FP "How do I think this
way?" and he wasn't really sure how to answer. HtDP helped teach me that way
and made it natural.

The only criticism I can give of the first edition is that it was at times
verbose, but it is clearly written as a textbook (and is definitely suitable
for self-study). The second edition appears to be more streamlined. Something
that might be more of a "dive into it" kind of book is "Realm of Racket,"
although it doesn't appear to go as deeply into Racket's language-making
capabilities and lispy features like macros.

~~~
shriramkmurthi
Indeed, the first edition is draggy at the beginning. The second edition is
meant precisely to dive right in and get cracking, without sacrificing any
principles. I recommend people read the second edition instead of the first
one. [Why should you trust me? My name's on the cover. <-;]

~~~
muraiki
Thank you, that is good to know.

Also, please know that I am sincerely grateful for all of your work. Without
the software and materials that you and your team labored to create -- and
which you provide freely -- I might not be a professional programmer today.

~~~
shriramkmurthi
Wow, thanks. I passed this remark on to the rest of the team. Totally made our
day!

~~~
xaritas
I'm teaching my kids how to program using the 2nd edition because it's the
introduction to programming that I always wish I had received. They love it!
Thanks.

------
PaulRobinson
I sense the whole area of domain-specific languages is due for a belated
renaissance.

Everybody shirks away from it, but most languages are not very good for
solving most problems and the standard libraries bloat out as more and more
gets crammed in.

I don't think in a commercial context we can all step back and say "to solve
this problem, let's first design an appropriate language" but as a means to
define the problem better, or to encapsulate learning we've made in building a
prototype in a general language, it can be very powerful.

If you aren't able to best describe the problem space, how do you intend to
solve a problem within it?

~~~
stcredzero
The problem with Lisp-like DSL construction, is that the interface doesn't
play well with many populations of domain experts. Even Smalltalk, with its
syntax designed to be usable by children can fulfill the technical side of
constructing DSLs easily, but still leaves something to be desired when it
comes to domain expert use. (Various Smalltalks had their rough equivalent to
#lang.)

(I know there is at least one Ruby based DSL which made some inroads to mobile
device software testing.)

Basically, DSLs tend to only get used by experts who are already programmers
or otherwise technically disposed. Maybe we're getting to the point where
rudimentary coding is just going to be a new kind of literacy?

~~~
shriramkmurthi
This is a criticism of Lisp-based DSLs but not of Racket-based DSLs. Racket
actively enables you to impose different, non-parenthetical surface syntaxes
on the DSL. It is not a "this sort of works if you arrange it carefully _and
nobody screws anything up_" thing like in Ruby, it really is an explicit
language definition.

The easiest way to understand this in action is to read about Danny Yoo's
Brainfuck embedding in Racket:
[https://www.hashcollision.org/brainfudge/](https://www.hashcollision.org/brainfudge/)

~~~
muraiki
I really liked the following article, which creates a text adventure language
in Racket that looks like this:

    
    
      ===PLACES===
      ---desert---
      "You're  in a desert."
       [cactus, key]
      north    start
      south    desert
    

[http://queue.acm.org/detail.cfm?id=2068896](http://queue.acm.org/detail.cfm?id=2068896)

~~~
shriramkmurthi
Scribble is another great example. It's amazing in its own right, and by being
embedded into Racket, gets all the Racket benefits: for instance, separate
compilation! (Thirty years and waiting, LaTeX.)

------
brudgers
A great podcast interview with Mathew Flatt, one of the core members of the
Racket team.

[http://blog.cognitect.com/cognicast/061-matthew-
flatt](http://blog.cognitect.com/cognicast/061-matthew-flatt)

------
chiddysk
I agree with Page 1 alot. You can teach a kid to count in 1s and 0s, but that
doesn't necessarily follow that you can teach him to code in machine language.
Even the pros' have to use tools like hex representation to make machine
language programming easier.

------
peatmoss
For some time, I've daydreamed about implementing R in Racket ("Arket"?) as a
means of shining a flashlight in all the dark corners of my R knowledge. Then
I realize this would take me a heap of time and it goes back to being a
daydream.

~~~
shriramkmurthi
Look at how we've structured the semantics of JavaScript, Python, etc. (E.g.:
[http://cs.brown.edu/~sk/Publications/Papers/Published/pclpk-...](http://cs.brown.edu/~sk/Publications/Papers/Published/pclpk-s5-semantics/),
[http://cs.brown.edu/~sk/Publications/Papers/Published/pmmwpl...](http://cs.brown.edu/~sk/Publications/Papers/Published/pmmwplck-
python-full-monty/),
[http://cs.brown.edu/~sk/Publications/Papers/Published/gsk-
es...](http://cs.brown.edu/~sk/Publications/Papers/Published/gsk-essence-
javascript/)). This is how you should go about creating a core of R, followed
by an elaboration from the full language into the core. Steal an existing
parser to get ASTs, then most of your time goes into desguaring.

