[racket] Racket in the large

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Fri Aug 19 20:55:40 EDT 2011

First, due to what journalists call "full disclosure", I should mention 
that I make a living as a consultant who uses Racket almost exclusively 
now, and will probably write a Racket software engineering book soon, 
and so I have a conflict of interest in encouraging new projects to use 
Racket. :)

gonzalo diethelm wrote at 08/19/2011 06:07 PM:
> So let me get to my point before I bore everyone here to death: can my 
> desire be realistically fulfilled? Can Scheme (Racket) be used for a 
> more "enterprise-y" project (console app, GUI app, web app, whatever, 
> accessing data from any RDBMS in transactional ways) where I will have 
> a team of developers working on separate parts of the system at the 
> same time?

Yes.  One of my consulting clients has a large code base (order of 
magnitude larger than the Racket/DrRacket distribution and its standard 
libraries), in production for years, making heavy use of PostgreSQL.

Regarding project management, most of the usual practices apply, and 
there are only a few differences with Racket that I see, and you can 
predict what I'll say, but I will spell out for the larger audience here:

* The first biggest difference with Racket that you *must* consider is 
what, at least in the US, industry used to call "nobody ever got fired 
for buying IBM": any time you use something that not everyone considers 
a "safe" choice, that is a political vulnerability, so you need to have 
the political power to choose.  (This is not exclusive to Racket.  
Separate from any technical considerations, choosing Python is 
politically risky in some environments, and even Java can be politically 
risky unless you're doing a routine intranet Java enterprise app and 
using a "safe" framework.  I think the difference here is "Why are you 
using Java/Python when I think it is unsuitable for this purpose," vs. 
"Why are you using something on which I do not already have an opinion?" :)

* The second biggest difference with Racket that you *must* consider is 
simply that usually project team members will not come to the project 
knowing Racket like they "know" Java.  This can be mitigated, and the 
learning cure might well be "in the noise" if you need and have smart 
developers on a substantial project.

* Then, as you know, there are advantages of Racket that you *may* 
consider, which are linguistic, like the productivity and 
maintainability leaps you might get when a team member makes DSLs that 
are used by multiple other team members.

* You might also find sometimes that there's a library for Java that 
does something you need, but you can't find a similar library for 
Racket.  This situation has improved a lot in the last few years, plus 
there is now an FFI for easily calling C libraries.  But eventually you 
will encounter this situation, so be prepared to bang out that bit of 
functionality (perhaps much better than the Java library does) after 
first asking on the Racket email list to see if anyone else has such 
code or knows an easy and good way to do it.  This downside to this 
situation might be more political than practical, if it's easy for you 
to get the same functionality, but you'll have to explain to management 
that the project is still winning with Racket, even if in this case you 
did not have a library that a Java programmer would've.

> Which brings me to my second question: can Scheme (Racket) be used to 
> develop all these different kinds of applications (console, GUI, 
> etc.)? Can anybody point me to real life examples of each type of 
> application developed with Scheme (Racket)?
>

DrRacket is a good example of a complicated GUI app that is used in 
production.

Racket ships with a few console apps that are implemented in Racket.  
Close to 10 years ago, I had a long-running console app in Racket that 
was a specialized Web spider, and I also occasionally write utility 
scripts as console apps.  I think people write console apps frequently, 
without considering them noteworthy.

The server apps in Racket tend to be non-public, because they are for 
internal use of an enterprise, or for competitive or other reasons.  I 
believe that the PLaneT server is implemented in Racket, and it is public.

>  
>
> [In fact, I specifically came to Racket after having had a grand 
> vision of being able to develop all the components for a web app (SQL 
> to access the DB, business logic, HTML for presentation, CSS for 
> styling, JS for interactivity, even XML for configuration) using a 
> single unified language (or many small separate DSLs based on a single 
> language) and I have been kind of surprised at not finding this idea 
> fleshed out anywhere as a framework, library, module, etc.]
>

Yes, I have a client who has credited Racket's utility for SXML 
processing and dynamic programming with being a strategic advantage.

There is another company down the street from  me here that Google 
bought, after they used another Lisp dialect to implement what in the 
past had only been done with mainframes (and to interoperate with the 
very complicated legacy mainframe network).  They credit the DSL 
capabilities of Lisps with being crucial to being able to do this at all 
in a timely manner.  (They also credit using a Lisp with being able to 
attract a much better talent pool than they would've otherwise.)

>  
>
> if Scheme is the be-all and end-all of programming languages,
>

Before we go further, Racket is Racket, not Scheme.  As soon as we start 
saying Scheme, people start getting confused. :)

When people start talking about why does industry currently use the 
technologies it does, people identify and speculate on many reasons.  
Some of the reasons concern pragmatism and accidents of history, and 
sometimes people are very critical about the state of current practice.

I think you'll find with Racket is that it's been a well-kept secret for 
a decade, up until this last year, around the time when the name was 
changed and it started to get noticed by more people.  Many of the 
people who stumbled upon Racket earlier ended up doing 
industrial-strength app development in Racket, but on apps for use by 
university students and schoolchildren, which is why I suggest looking 
at DrRacket as a good example of an app developed in Racket.  I think 
we'll start seeing more publicly-accessible projects using Racket now.

FWIW, I have a background in mission-critical software engineering and 
methodology, and, like you, did real development in C, then C++, then 
Java, and various other languages in there (Perl, Smalltalk, Python, 
Common Lisp, 4GLs, more obscure ones...), until I gravitated towards 
Racket.  I decided on Racket for the greater agility and sophistication 
of the core language, and for the smart developer community.

Since you asked, I don't think anyone has yet invented the be-all and 
end-all of programming language platforms, but Racket is the current 
all-around best I can think of for most modern app development purposes 
that are not externally constrained to use Java.  (There is even a 
project to adapt it for embedded systems.)  The other platform that came 
close for me, linguistically, is Haskell, but I think Racket wins for 
DSLs and a few other reasons.

Another, smaller, advantage over Haskell: I can take an industry 
programmer who used Pascal once in school, sit them in front of Racket 
and have them ready to start being productive with other people's 
libraries by the end of the day, treating Racket as only "a better 
Pascal, with parentheses, plus some code patterns I've I'm using without 
fully understanding".  They can then learn idiomatic Racket, how to make 
their own DSLs, and functional programming precepts incrementally as 
they work, over the course of months.  But sitting that same programmer 
in front of Haskell... would be much more difficult.

-- 
http://www.neilvandyke.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20110819/0cd28177/attachment.html>

Posted on the users mailing list.