
Server: Racket – An ebook about web development with the Racket HTTP server - macco
http://serverracket.com/
======
giancarlostoro
Of all the Lisps I've toyed with (mostly Clojure and Racket) I think I enjoy
Racket the most. I wish more languages (I know some already do: Python,
Processing, and others) would at least include a minimal text editor that can
build and debug code - coded in the same language. Matter of fact, I've wished
this were the case for Rust (and maybe D? - I guess there's a minimalist emacs
for D but that's not as approachable as say Dr. Racket for newcomers), it
would give them a chance to build a bare bones UI stack for Rust that is
officially maintained.

On the other hand, my experience with Racket has been fantastic, I have not
done too many significant projects, but when I toy around with it, it doesn't
get in my way. I just don't have a good project for it as of yet. If I want to
do web I'm already accustomed to using other web stacks so I don't see the
appeal there, one thing that always surprises me is the GUI stack for Racket
though, it just feels straight forward. It feels like we still haven't figured
out the whole GUI thing, Electron is so popular because you can get a GUI done
fairly quickly since everyone understands the front-end code so well out of
the box.

I was also fairly impressed by Clojure. You install the package manager (Lein)
and you have all you need to do any Clojure work, iirc it will go as far as
installing Clojure for you. The repl approach to GUI design with Clojure was
also quite interesting for me. I think Clojure and Kotlin are the only two
things about the JVM that impress me these days, but that's just my opinion.

~~~
noncoml
These days it’s more about the ecosystem rather the language itself.

While most language provide the basics, sooner or later you will end up
needing something that is only available for the most popular 5-6 languages.

E.g. S3 APIs or drivers for Riak, or gRPC or rabbitmq or something else.
Something always comes up.

Having said that, the packages listed in Racket’s webpage seem quite
comprehensive.

~~~
baldfat
> you will end up needing something that is only available for the most
> popular 5-6 languages

The thing that is the Special Sauce for Racket is it's macro system. You can
build your own language for specific things easily or you can extend Racket
with a library also much easier then the other 5-6 languages.

Racket really has a chance of being the Python of functional(ish) languages.
The ability of the community to produce a great ecosystem is all right there
baked in. [http://jeapostrophe.github.io/2013-07-22-123list-
post.html](http://jeapostrophe.github.io/2013-07-22-123list-post.html)

I also think the documentation is all in one place. The library Scribble makes
it simple for everyone to document your macro/library simply and uniformly. I
really have high hopes for Racket over the next 5 years.

~~~
irahul
> The thing that is the Special Sauce for Racket is it's macro system. You can
> build your own language for specific things easily or you can extend Racket
> with a library also much easier then the other 5-6 languages.

Compare the raw format:

[https://stripe.com/docs/api/curl#metadata](https://stripe.com/docs/api/curl#metadata)

with Python:

[https://stripe.com/docs/api/python#metadata](https://stripe.com/docs/api/python#metadata)

How are macros going to give me a better solution that the one which exists,
is tested and have been used by others for some time? Besides, macros are a
meme. What difference are macros going to make when wrapping a api? Can you
show me an existing lisp/clojure wrapper which is more expressive than
python/ruby?

~~~
bad_login
The example you give doesn't have boilerplate so macro can't do more.

Macro can help for two things:

\- reduce boilerplate

\- add new function to your language (often specific and limited in context of
use [racket's macro a suposedly composable]). Example: racket match,
clojure.async.

~~~
irahul
> Macro can help for two things

I know what macros are and what macros can do. The parent poster made a
comment that somehow macros can help overcome non-existence of wrappers in
Racket. We both agree that macros won't help in this case, and my personal
opinion is macros are a meme. They help some in very limited circumstances yet
they are touted as a productivity multiplier. A pattern match over if-else
doesn't really buy much. It's nicer, sure, but not by much.

~~~
bad_login
The specific problem of wrapper around HTTP API have been resolved with WSDL
([https://www.w3.org/TR/wsdl](https://www.w3.org/TR/wsdl)) assumming the use
of WSDL the only thing a macro could do is equivalent of what an external
program that generate a python file implementing the WSDL could do. I have
written a php parser with the racket LLAR macro and it doesn't add more than
an external tool like bison.

Reducing boilerplater could make your code less buggy (bugs you catch with
your eyes) and could make the meaning of the code more clear.

Racket match is realy nice but it will shine if:

\- You use a lot of immutable datasctructures.

\- Explore shallow tree like data structures.

> and my personal opinion is macros are a meme

As far i has understand macro is already in use as Annotations for java.

In php, programmers developped complex frameworks that generate code (Symfony
for instance) before running the user's code even if it isn't a macro per-se
it share the same goal.

And i could have mention c++ template, so i don't think macro are a meme they
already exists and there is a demand for it.

~~~
irahul
> assumming the use of WSDL the only thing a macro could do is equivalent of
> what an external program that generate a python file implementing the WSDL
> could do.

I am not assuming the use of WSDL and macros still don't do much.

> Reducing boilerplate could make your code less buggy (bugs you catch with
> your eyes) and could make the meaning of the code more clear.

Macros aren't required for reducing boilerplate and don't necessarily reduce
boilerplate compared to a non-macro solution in an expressive language.

I read almost all of racket's documentation cover to cover and learnt Clojure
about 5 years ago. There are a lot of good things to say about them but as far
as expressiveness go, but I didn't found them anymore expressive than Ruby or
Python.

> Racket match is realy nice but it will shine if: > \- You use a lot of
> immutable datasctructures. > \- Explore shallow tree like data structures.

The things you pointed out are non-macro things. I like match, especially when
it's well integrated in the lang. viz f#. I just don't like the difference
that being able to cook up your match using macros makes a huge difference
when it comes to programming productivity.

> i don't think macro are a meme

You misunderstand my point. Code generation with or without macros is useful.
That's not a meme. "Macros are a secret sauce" is a meme.

~~~
bad_login
> Macros aren't required for reducing boilerplate and don't necessarily reduce
> boilerplate compared to a non-macro solution in an expressive language.

So i suspect you are thinking of ruby metaprogramming, in that case you have
good and bad. With macro you can expand your code and have static tool reason
about your code (IDE à la Éclipse). In the other hand in metra prog. you have
all the info availlable at runtime and it is more easy to implement.

> I just don't like the difference that being able to cook up your match using
> macros makes a huge difference when it comes to programming productivity.

For the specific racket's match you can build your own match rule
([http://docs.racket-
lang.org/reference/match.html?q=match#%28...](http://docs.racket-
lang.org/reference/match.html?q=match#%28tech._match._expander%29)) and that
is macro power..

In my own use of lisps i havn't realy used any macro.

> "Macros are a secret sauce"

It is probably an overstatement, if they have been useless for you (and me)
doesn't mean they are.

~~~
irahul
> It is probably an overstatement, if they have been useless for you (and me)
> doesn't mean they are.

You are conflating "useless" with "secret sauce". I didn't claim they are
useless. I said macros are a meme and are useful in very limited
circumstances.

------
mebassett
Really glad to see this book. I have shipped webapps in racket two or three
times (once in typed/racket, because I was feeling especially crazy). It
really was the most fun I had programming in a long time. But some of the
problems I was tackling I felt like I was treading new ground - it wasn't
clear if a ProxyPass to nginx was the best thing or not, it wasn't clear if
this was the correct way to implement sessions or not, et cetera. I'm glad to
see an authoritative book for the racket community on these topics.

------
sriku
To take lisp based web development to another level, what if we had a
"browser" environment that embedded racket and executed sandboxed code instead
of JavaScript/html? (Goes back to dreaming)

~~~
pjmlp
We had a taste of them in the past, Xerox PARC created Ethernet and their
workstations (Interlisp-D, Smalltalk, Mesa/Cedar) offered some support for
interactive objects across network.

[https://en.wikipedia.org/wiki/NoteCards](https://en.wikipedia.org/wiki/NoteCards)

[http://www.ubiq.com/hypertext/weiser/UbiHome.html](http://www.ubiq.com/hypertext/weiser/UbiHome.html)

Which is why Alan Kay is not a big fan of the Web as such,

"The Internet was done so well that most people think of it as a natural
resource like the Pacific Ocean, rather than something that was man-made. When
was the last time a technology with a scale like that was so error-free? The
Web, in comparison, is a joke. The Web was done by amateurs."

\-- [http://www.drdobbs.com/architecture-and-design/interview-
wit...](http://www.drdobbs.com/architecture-and-design/interview-with-alan-
kay/240003442#)

~~~
dualogy
> _The Web, in comparison, is a joke. The Web was done by amateurs._

Which (like it or not --- I jump back & forth myself) is probably why it took
off as explosively as it did..

------
alien_at_work
Racket is interesting, but what turns me off about the language is that they
decided they needed OO for some things and they... implemented a single
dispatch based system. Why would you limit yourself this way if you don't need
to? Single dispatch systems force you into all kinds of "power deficiency
patterns" (e.g. all double-dispatch patterns) that just wouldn't be necassary
if you do multiple dispatch a la CLOS. You don't have to re-implement all of
CLOS if you don't want but at least use something like generic functions
instead of the inferior (and ugly in Racket) single dispatch style.

~~~
moron4hire
Dynamic dispatch is available for functions: [https://docs.racket-
lang.org/multimethod/index.html](https://docs.racket-
lang.org/multimethod/index.html)

Since Racket methods are just functions around a class context, it seems like
it should be possible to make these into methods.

~~~
alien_at_work
It's good that they have that, but most of the OO API's (including the web
server stuff AFAIR) is single dispatch.

~~~
samth
The web server doesn't really use the object-oriented features. OO is mostly
used in the Racket standard library for the GUI, where it models existing
single-inheritance GUI libraries.

------
fu86
An eBook for $50?

~~~
r3bl
And, as always, they sync the prices in EUR and USD, so it's $8 more expensive
to buy the book from Europe.

~~~
always_good
Meh, how about the variance in purchasing power and cost of living among all
the places that use just one currency? You'll find differences even greater
than $8.

Prices are arbitrary. Locking USD = EUR makes you superficially feel like
you're getting ripped off but it's still arbitrary. You're also paying the
same as someone making $100k/year more or less than you.

------
milesstevenson
Will the book have exercises?

------
achikin
It's just an upcoming book advertisement. Nothing valuable in this article.

