[racket] FYI: A new Racket-powered startup

From: Daniel Prager (daniel.a.prager at gmail.com)
Date: Fri Feb 7 07:28:00 EST 2014

Hi Gustavo

I'll do a fuller "YouPatch story (tech Geek edition)" hopefully soon, but
would prefer to submit to Hacker News a little bit down the track when the
site has evolved a bit more, and there's more stuff of general interest for
the HN audience. I actually think the most interesting parts of the story
are yet to unfold - so stay tuned!

That said, I thought I'd respond here to part of your email here:

TL;DR: Racket's a great choice for creative, experimental programming, that
can also be deployed into production.

Why are you using Racket, and why is it "better" than C?

I'm using Racket because it's a high-level, productive language, with a
really smart and supportive community. I happened to be doing most of my
"programming for fun" in Racket when the idea of automating pixel quilt
design occurred, so I picked up the nearest tool and gave it a go. That was
Racket, and I've hardly looked back.

In the initial, highly experimental, hack / research phase I was pleased to
find that the batteries included in Racket were great. Having a REPL makes
it possible to do lots of mini-experiments, and out-of-the-box performance
tends to be very good compared to more popular, high-level "scripting"
languages like Python and Ruby.

Realistically, I might have worked in Python, which I'm also currently
fluent in, but the need simply didn't arise.

Later on, when performance issues arose, with a bit of profiling I was able
to identify major bottlenecks, make a few simple optimizations and get
"good enough" performance.

> Do you hate the ugly syntax? Do you implement something very complex that
> is too long to write in C?

Why not C? I haven't programmed in C for many years. It's very low-level,
and lacks expressive power. The syntax isn't too bad, but real functional
programming fits my mind better, and is much faster to develop in.

The last point is key. I learned the lesson that programmer efficiency is
often more important than code efficiency around 20 years ago, when I
working on my PhD in computational mathematical physics writing numerical
black hole simulations -- how times change! -- and switched from writing my
simulations in Pascal and then C++ to Mathematica. What happened? Instead
of running for minutes, my simulations took hours and I had to run them
overnight. BUT, the pace of my research sped up because I was able to
develop faster, and better interrogate the results interactively. Since
then, computers have got much swifter, so there's even less reason to use
low-level languages in application and creative programming, except perhaps
in key bottlenecks.

* * *

Now, what I described above mainly referred to the research or "hack"
phase, but when it came to commercialisation the technical considerations
changed somewhat.

I invited John Barham -- who I had previously worked with in a corporate
setting -- to join as a co-founder. John is very knowledgeable about
web-programming and "the cloud", where my skills and knowledge is far less
advanced. I.e., we have complementary and overlapping skills (and get along

I had noticed that John's latest web-service, turbohdr.com, when you stand
back and squint, had structural similarities to what my wife Andi and I had
in mind for YouPatch: it's also a cloud-based service in which the user
uploads a photo, stuff happens, and you pay to download something. Adding a
highly intelligent and capable colleague who had recently worked
successfully on a similar project seemed like a good way to complete our
founding team.

Anyway, when it came to technology choices, one thing I didn't intend to do
was convince John to learn Racket! Similarly, I didn't want to have to
learn everything that he knew. In fact, I would have been quite willing to
translate key code from Racket into say Python or JavaScript had the need
arisen -- say for performance reasons or in order to facilitate
collaboration with John -- but we decided to leave the core algorithms in
Racket (for image processing and PDF generation) for as long as we could,
and they're still in place!

John built most of the rest of the site using mainly JavaScript, Python /
Django / Mezzanine CMS served by nginx: a far more conventional stack, and
I helped out on the front-end design and implementation.

On the development side I continue to maintain the Racket part and we share
the UX / front-end work, and John handles everything in-between. I have
further "research" going on in Racket, as time permits.

* * *

I hope that these notes are of interest to others who might want to try
their hand at a start-up. The barriers to entry have never been lower, but
that also means there's a lot of competition in the general space. I was
heavily involved in an ultimately unsuccessful VC-funded startup from 2005
to 2010, and needed to take a few years out from the scene to recharge and
recover. Startups are a huge buzz and great for people with creative and
generalist leanings, but also tend to be an emotional roller-coaster.

I recommend using Racket (or some other cutting-edge language) in *your*
startup, because you get to make the choices, it may well confer real
advantages, it's likely that the community support will be greater than for
a more conventional choice, and it can help attract a more passionate,
discerning and adventurous class of colleague than going down the path of
the conventional.


*Daniel Prager*
Agile/Lean Coaching, Software Development and Leadership
Startup: www.youpatch.com
Twitter: @agilejitsu <https://twitter.com/agilejitsu>
Blog: agile-jitsu.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140207/4d349e3e/attachment.html>

Posted on the users mailing list.