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 well). 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. Dan -- *Daniel Prager* Agile/Lean Coaching, Software Development and Leadership Startup: www.youpatch.com Twitter: @agilejitsu <https://twitter.com/agilejitsu> Blog: agile-jitsu.blogspot.com
____________________ Racket Users list: http://lists.racket-lang.org/users