I'm using Racket for a major project right now. It's been hit and miss. On the one hand, Racket is by far the best alternative/non-mainstream language—the docs are good, there are surprisingly broad libraries, and of course it's great to support the good people at Northeastern.
On the other hand, there is evidence here and there that this language isn't commonly used in production. For example, the pattern-matcher is very well-implemented and feature-full, but there's no way to use it programmatically nor is there a way to get the set of bindings. There is also the sad fact that Racket is a Scheme in the traditional Scheme fashion, and so is still trapped in an 80s design aesthetic. Generics are poor, ADTs aren't easily implemented, static types exist but are not so widely used and have strangenesses.
"no way to use it programmatically nor is there a way to get the set of bindings"
These don't really make sense in the context of Racket. Pattern matching is a macro and thus doesn't exist at run time, though of course with eval the distinction between run time and expansion time is not so well defined. Accessing the lexical environment is not something you do in Racket -- it breaks optimisations and is generally considered a bad idea.
We're using it in production at my job. (In a decent-sized polyglot system also made up of Haskell and Clojure).
There aren't as many libraries available compared to more popular languages, but I haven't yet had too much trouble getting things accomplished. For the above-mentioned languages we're using, I'd put the useful library situation at: Racket-> Haskell-> Clojure in order of least to greatest.
Depending on what you need it to interoperate with, it's totally usable in production environments as it stands.
I'm using different languages for different parts of the system.
While I could probably do everything in one language, I'm not sold on the idea that that's actually a good idea (aside from developer convenience, which considering I'm the only developer I don't rate very highly). I also don't feel qualified enough as a language person to really hold defensible opinions about their relative strengths and weaknesses yet.
For example, part of the system is a network service that runs deployed on servers in our environment. All that code is Haskell. I didn't want to have to deploy and manage an interpreter or JVM on those systems, and I don't trust myself to write C that I feel confident deploying in production. Haskell seemed like a good win there (other folks might use Go, or whatever). It turned out to be really easy to write a network server in Haskell that receives the messages that the service needs to receive. Also, it was the first time I used a language that had good (or really, any) pattern matching, and I'm sold on it.
The "business" logic of the system is all currently in Racket. It could certainly have been written in Haskell, but I'm still getting up to speed in it, whereas I was able to get pretty minimal functionality up and running with Racket very easily.
Right now only the web interface is Clojure. I briefly considered using Yesod for the web piece, but it seemed really complicated. And although Racket has a nice web server, it requires buying into the "continuations" style that they advocate (or rolling your own web libraries, which seemed like a bad idea for this project).
I think the continuation-based approach for web servers is certainly valid, and maybe even technically better, but they're swimming against the tide with that approach, and as web programming is so far my least favorite part of building this system, I wasn't willing to buy into that enterprise.
Thankfully, I was able to get a Clojure web app up and running very quickly (basically just Ring and Compojure).
The system is designed where there's pretty hard boundaries between all the parts, so by the time all is said and done, it might all be written in the same language; but that's not necessarily a design-goal. I figure different languages seem to have different strengths, and there's not really a good reason for me to try and shoehorn everything into one.
If you want to try out Haskell for web development again one day ping me (email in profile) and I'll send you a copy of Snap for Beginners[1]. I'm releasing it at the end of the week and it should make getting started in web dev with Haskell easier.
Yeah, I pre-ordered your book, I look forward to reading it.
When I originally looked at using Yesod, it seemed fairly complicated for what I needed (which is basically just the crud-iest of crud apps). I'd only been using Haskell for a couple of months, and I'd never done any web programming; so I figured I should try to use something that wouldn't require quite so much "stuff".
I finally decided to try out Clojure because I'm planning on using Datomic for the main datastore (because it looks like I can have it backed by Cassandra, which lets me store all of our data in an HDFS cluster.) and the "Web Programming with Clojure" book just came out. I figured I could probably figure out a very basic database-driven view web app just by going through the book. That turned out to be true, actually, and it wasn't that hard to get my app up and running.
What dawned on me going through the book was that what seemed complicated to me really wasn't a function of the language, but the way almost all mvc web libraries seem to be laid out; and that actually once I understood how they worked, I could probably implement the same thing very similarly in almost any language that has a similar library.
So I might eventually look into making a REST api using Snap to handle the requests, and sort of encapsulating all input and output in the system with Haskell.
Have you had the opportunity to try out the GHC 7.8 release candidate yet? For network io work loads the new io manager has some great scalability. I'm actually planning on writing some distributed systems tooling in Haskell once I get my first release of numerical Haskell out, which is soon!
Happy hacking and best of luck on the business side
" Many sites are replacing inetd with tcpserver, for several reasons:
* inetd is unreliable under high loads. It cuts off service for 10 minutes if it receives ``too many'' connections in 1 minute.
* inetd does not provide effective resource management. It will happily use up all your memory if you are running a popular service.
* inetd has trouble with sudden bursts of activity. Its listen() backlog is typically only 5 or 10 and cannot be raised.
"
Personally I use tcpserver. I have an SMTP server I wrote in awk - http://www.proweb.co.uk/~matt/awk/smtpd.awk
I ran this as the main SMTP server for production web site for about 5 years.
amusingly I've just spotted a bug in the smtp code. a missing _ for logging unexpected EOF reading from the client. Not fatal but maybe useful for spotting spammers.
I've inspired myself to resurrect using this instead of Postfix for incoming mail. See if I can get it hooked up with spamassassin.
I wasn't (although that admittedly is one of the best benefits of Clojure).
Also, that's not a listing of the total number of libraries; it's ranked based on the number of useful ones (where "useful" is a completely subjective term that relates to how often I've looked to see if a library exists that does what I want).
Racket actually has more overall libraries than you'd expect considering its popularity, but I've found that many of them are old, no longer updated, scheme libraries (from the days before Racket rebranded from Dr. Scheme). That certainly doesn't make them useless, but I'm reticent to mix scheme-style code into my project.
I'm least familiar with Clojure (I've only been deploying it for the past two weeks or so), so I'm sure my opinion will change, but right now it feels like a slightly less good Racket with a philosophy I find agreeable and more practical libraries (plus Java interop).
> Racket actually has more overall libraries than you'd
expect considering its popularity, but I've found that
many of them are old, no longer updated, scheme libraries
(from the days before Racket rebranded from Dr. Scheme).
That certainly doesn't make them useless, but I'm reticent
to mix scheme-style code into my project.
Which libraries are you referring to? Libraries distributed with Racket, or libraries on Planet (or somewhere else on the internet)?
And any sense of which libraries in particular you notice being missing?
Sorry, I should have been more specific; but I was referring to the libraries available on Planet.
It looks like the new Planet that you guys just shipped doesn't have all the legacy mzscheme packages that used to seem to be the majority of packages. I don't know if that was intentional, but if not, I think that it's a nice tangential benefit.
I just remember every time I'd search for something on Planet, most of the results I'd get back were for old scheme libraries.
I know it's annoying as a developer to hear a vague criticism like "there's less useful libraries" without being able to provide a list of concrete items; but I'm going to annoy you by not being able to come up with anything specific right now. Sorry ;)
I will say though, I think Marketplace looks really neat, and I'm looking forward to testing it out for some things internally.
I am also very interested in Marketplace. I am just starting, but when I saw it I thought Erlang/OTP-ish concurrency and network stuff on Racket? Yes please!
Personally I don't use it for anything server-side, but that doesn't mean it's just for education. I suppose it's an unavoidable misconception given that its most obvious strength is the quality documentation and IDE.
Its built-in image support is much better than anything I've seen in any other language, so I've used it a couple times for writing simulations that need a histogram. It's also much better than Clojure for things that require low memory usage or fast startup time.
Their continuation-based web server is neat, if you can handle not complaining about the same thing in the Arc/HN combination everyone does when it is brought up.
I also recently discovered a web sockets library, but am not good enough at coding Racket to use either yet. I am definitely planning on it.
(And seeing you're handle, just want to thank you for your contributions to Clojure; I can only image what would happen if you got more involved in the Racket community).
Yes, and I am not sure if this was addressing my comment. I believe the Arc implementation here (despite being a language built with Racket) is run with its own implementation of continuations.
I mentioned people complaining because, well, people complain when you get timeouts with your continuation. That is why when you click More at the bottom of the page, you see a URL that looks like this:
I believe this is calling into the continuation space. I could be wrong, however. I am just starting my Scheme journey.
Nonetheless, sometimes continuations do not work well on HN and I see people mention that. It is different way to handle state (Racket calls their Racket server stateless for this reason). I just wanted to point that, even if people will pass judgement from their experience here, it is a cool concept nonetheless.
Also, more experienced people should correct my analysis of HN if I am wrong.
Geiser is great, but SLIME is much better mostly because Common Lisp was designed with interactive programming in mind(the condition system, the object system, dynamic variables ect. are all features that help with interactive programming). You get an almost smalltaskesque feeling with slime.
I learned with Racket, and I found it to be a great experience. It comes with an IDE, DrRacket, that makes it very comfortable to start experimenting. It's also "batteries-included", with libraries for GUI, graphics, networking, etc. It also comes with really good documentation (at least as good as Python's, I'd say, and better than either Perl's or Ruby's).
Racket has a good foothold in educational environments, so it's no coincidence that it's conducive to learning. However, Racket also sees a lot of usage in the PL research space, so it's also conducive to just experimenting. Those two combined can make it a very fun environment.
There's also #racket on freenode, which I've found rather welcoming.
If you are interested in learning a LISP, then Racket makes a lot of sense. It is actively being developed and extended and because of its roots in academia extensions tend to be address interesting problems- many arise out of computer science research by professors and grad students.
On the other hand, if you want to learn Scheme by working through SICP, then I would recommend MIT Scheme to avoid impedance. There's not much benefit from using the Racket ecosystem for that. Likewise, if the goal is to work through On LISP then a common Lisp implementation makes sense.
Of course there's no reason not to have all those languages installed..or at least that's what I tell myself.
My last advice is that Racket is an ecosystem. It provides many languages including Algol and Datalog and Scribble and Typed Racket. This makes for a lot of documentation and it is uneven. The guide will be too shallow and the reference will be more boilerplate rather than providing deeper explanation and further examples.
I've been working through SICP, and as far as I can tell Dr. Racket is actually the best way to do that. You just need to use Neil Van Dyke's SICP package for Racket. http://www.neilvandyke.org/racket-sicp/
FYI, brudgers makes good points, but the beauty of Racket is they have subsets and supersets of languages, from an Algol implementation to a specialized language built for studying SICP. Neil van Dyke and some other Racketeers built it. I think it might be in need of a maintainer, but here it is nonetheless.
Also keep in mind there is a different subset language designed by one of the developer/professors for his own book based upon his improvements to the SICP methodology, entitled How to Design Programs, as explained in his paper.
Felleisen's How to Design Programs has an entirety different set of goals than SICP. HtDP teaches programming practices. SICP teaches 'computer science.'
HtDP is a great book, but no substitute for SICP in terms of content.
While I haven't read HtDP, I've read similar things.
I'm in my late 20s going for a second BS (this time in comp sci), and wanted to go through SICP on my own (plus the online lectures). I felt that I needed a bit of a warmup, though, and chose 'Concrete Abstractions' instead of HtDP. I'm satisfied with it so far.
It may seem obvious but HtDP emphasizes designing programs. It's not really trying to teach theories of computer science or abstractions. It's about developing coding habits - in terms of SICP it's all about good wishful thinking.
SICP, and this is not a criticism, is more like a stamp collection of computer science topics. It provides a point of reference when I've read about operating systems, state machines, compilers, data structures, etc. etc.
Between the two, SICP is flat out a better book qua book. On the other hand, working through just a little of HtDP will probably have more impact on the way you write software than working through a little of SICP.
Lastly, while there may be some similarities to other introductory texts, I doubt that there is any computing pedagogy backed by as much research as Felleisen and the PLT group. While SICP and Scheme were intended to facilitate teaching, the Racket ecosystem [and PLT Scheme before it] are continuously developed with pedagogy as a primary driver.
Most pedagogy is driven by "I think this would be a better way to teach programming." The PLT group checks their theories statistically and their theories are tied to educational theories in general. And they've been going down that road for several decades.
It has admittedly been several years, but I distinctly remember MIT Scheme being an utter pain in the ass to get built. I'd recommend Racket for people just getting off the ground for that reason alone.
However, there hasn't been a release since 2011. The primary maintainer (Chris Hanson) is now at Google, and seems to be busy with other things. Previously, he was at MIT and used to write most of his own research projects in Scheme, so it got a lot more maintenance attention.
Last month I built MIT Scheme on my 13 year old Toshiba Satellite (and it was the cheap one in 2001) under Wary Puppy 5.5. No problems. Because of its richer feature set, Guile was another matter and I gave up.
All the major lisp dialects are rather different and encourage different styles. My own opinion is that no one is a better first lisp, as long as you check out the others eventually. Racket is an excellent start. I always advise people interested in lisp to check out racket, clojure and Common Lisp in whatever order they wish. I started with scheme in 2008, moved to clojure in 2009 and I've been a happy Common lisper since 2010/11. Depending on your own style as a programmer you might choose a different main dialect you like best, but only after you try them all :)
I don't really agree with that. Although Clojure has many great things, for example its out-of-box immutable data structures, I wouldn't say that it's "more modern" than Racket.
If anything, lately Clojure has been drawing on Racket for inspiration in many areas (for example Typed Racket).
In fact, if you wanted to find a criticism of Racket, it might be that occasionally it is "too" modern -- in the sense that some parts are implementations of research papers. You might encounter the occasional module whose documentation isn't much more than "Implements foobars in the sense of Researcher [Year] <link to paywall paper>". To be clear, that is not 98% of Racket. I mention it just to counter the idea that Racket is "less modern". It's constantly evolving with new things.
Finally, for someone getting started with a lisp, Racket is (a) download, (b) install, (c) start coding and running -- within literally 5 minutes. (Of course experienced people aren't limited to DrRacket if they prefer Emacs or Vim or whatever.)
The whole notion of a "modern" programming language is a big joke considering that mainstream languages have been playing catch-up to Lisp for decades.
Congrarulations, the Racket team! It's really a joy to use Racket. Racket is elegant, powerful and fast. Everybody should try it. It's extremely easy to install and setup. And whenever you have any question, a fantastic community is there waiting for you.
Anyone used Racket AND clojure in production? Any first hand experiences? We're looking to add another language/environment to our, currently RoR+Postgres stack, and have a soft corner for lisps.
Having used clojure for a few things recently, I am interested in picking up a non-jvm lisp. It seems like Racket and Chicken Scheme are both well recommended. Anyone reading this have experience with both / insights as to why I might want to select one vs the other?
I like that the docs look less like they jumped out of the geocities era. Still could go a long way though. Signalling is important, and if you signal "old and unupdated" to your users, that's not a great start. (e.g.: http://docs.racket-lang.org/pkg/Package_Concepts.html)
"prev", "next" (when the table of content is right there next to it) and "top" (usually the header / logo link these days) and collapsible TOC trees screams "we copied this out of MSDN '97 and windows .chm files".
The "...search files..." looks like it was written by a programmer. The white on gray line with the black on white line next to it looks odd. Natural spacing sometimes is a great substitute for lines.
The main docs page (http://docs.racket-lang.org/) contains way too many fonts and way too many colors. Pick a scheme and go with it.
My favourite examples of docs that look like people cared:
http://www.gnu.org/software/smalltalk/manual/ (whenever I see the gendocs selection page I get nostalgic. Really? 120 vs 420kb? I didn't care even when I was using dialup. Also the "one webpage per node" version almost always sucks because you can't search for anything. And the "all in one page" version sucks because it's too huge sometimes. Who uses the ascii text version or the info docs version?)
I think you have a valid point (other than in the case of the Vagrant docs, which I absolutely detest [0]).
The simplest way to make good-looking docs might just be to 'just use Sphinx' (as does Flask, mentioned and http://docs.python.org/ and [many others][1].
The docs are a necessity to make up for the shoddy, inconsistent patchwork that is their language design, but they are damned well designed and easy-to-use for the wading through flat scope that is required by those who use the language.
[0]: Disappearing sidebar when you resize to narrow, huge amounts of spacing everywhere and sidebar names that can't be expanded without navigating to their root. :/
Ooooh the PHP ones are even better than they used to be, I hadn't checked in a while. I have always loved the user comments in docs idea. I've noticed so many bugs, gotchas and idiomatic patterns simply by looking at those comments. I bet it gives the devs a good idea on what to work on next, too. It didn't used to have votes which was bad because it perpetuated bad advice sometimes, but now it seems they have that too!
When Racketeers talk about documentation, they're not talking about the sort of documentation that you are holding out as better. They're not talking CSS and markup and formatting. No.
When Racketeers talk about documentation, they are speaking in Lisp and the context is code as data and data as code. When Racketeers talk about documentation they are talking about Scribble.
My critique was more on the visual side of things. I think it matters. That said, onto your comment:
I liked the presentation. The @ notation is kinda neat and elegant, and no doubt enabled by the ridiculous power macros give you in terms of modifying how everything is parsed. It's cool that it's implemented as a DrScheme lang, and it can run and is all code-is-data-y, and it's not a totally separate language. However, I don't really see anything in here that any modern document processor (say http://sphinx-doc.org/) can't perform.
The second-last question brings up a great point that when you tightly couple your documentation language with the platform (PLT), you run the risk of it being a PITA to use it to document other languages. I think the presenter's solution of automatically creating stub classes and such is really unsatisfactory and kinda kills the benefits.
So there you have it, there are pluses and minuses. I think Scribble is neat, but it's really not all that out of the ordinary.. It's definitely not true that "nothing comes close".
* That it's a full programming language, unlike systems like Markdown, or Sphinx, or JavaDoc, or other similar systems. But it also doesn't sacrifice being easy to write, the way that text is easy to write.
* That is works properly with binding. If you're documenting a function, you want to document the correct one -- that's handled with binding, the same way it works when programming. When you're writing an example, the same should be true -- again, handled with binding in Scribble. This works for _programs_, not just identifiers, which is what it looks like Sphinx does. That's why, for example, every single identifier in the examples on http://racket-lang.org is hyperlinked to its documentation. If you go to http://docs.python.org/3/tutorial/controlflow.html , the examples aren't hyperlinked at all.
I think the binding is really the big thing here. That basically the whole module environment is also available to scribble since it is also legitimate code, and it's being executed by the same interpreter, in essence.
I'm unconvinced that this is not possible otherwise though. If you're parsing the darn language to get to the AST to generate all the module names, contents, etc, I don't see why you couldn't have access to all that info when generating an example code block.
Right, people have certainly implemented hyperlinked versions of code by re-implementing the parser etc. LXR is an excellent example of this. What sets Scribble apart is that
* It's a documentation system, not just a code formatter.
* It's a programmable documentation system, and the code that _implements_ your documentation is kept appropriately separate from the code that you are documenting. This makes use of Racket's support for phases.
* That it doesn't re-implement the parser etc, but can use the built-in one, because of Racket's macros.
And, as you say, even if none of this was unique, there's the fact that Racket does it, and has 500k lines of documentation, all done comprehensively in this style.
I've read "beating the averages" about a billion times, along with all the other PG essays. I was (and still am) a fan. I took several classes using PLT scheme and I've used PLT scheme for a reasonable amount for other tasks (wasn't called racket then). I've also dabbled with some lisps. I've read the little schemer, I've went through the wizard book. I've written the obligatory metacircular evaluator. All this got me excited.
Over the years though, I've done my best to learn the lessons and move on.
Is it really a surprise that lisp, an aged tool of refined elegance, was a competitive advantage over the other popular languages in 1997, which were still in their neanderthal phase? I'm not sure if the difference is that huge these days though. While in the olden days languages seemingly refused to learn from the teachings of lisp, it seems today they steal from lisp like pop artists steal from each other. Say, a ruby DSL with blocks and other tricks is not as flexible as a defmacro based lisp one, but could there maybe be a tradeoff here?
Writing in lisps give me what I call the intellectual warm-fuzzies. I get to use many elegant tools to form abstractions upon abstractions to create the DSL for my problem domain. I like that. Some call it doing the Right Thing. The polar opposite of duct-tape programming if you will. A quote from the article: "to translate this program into C++ they literally had to write a Lisp interpreter [so basically a lisp-to-c++ compiler]". This is exactly the sort of thing I'm talking about. It's cute. It's the Right Thing. Rewriting the code by hand in C++ is for plebians.
And, given enough code, maybe writing the lisp-to-c++ compiler is less effort than a rewrite initially. Maybe. I'll allow the benefit of the doubt. But what about the machine-outputted C++? Is the code idiomatic? Is it performant? Who wants to maintain machine generated code? Who wants to maintain a custom compiler? Maybe none of these are problems, but my vote is that it's unlikely.
The blub paradox applies much more strongly (or maybe I could say "only applies") when you haven't been exposed. When you, in your arrogance, refuse to try something different. I've traveled up and down the proverbial ladder, and I know where I'm comfortable. For now. I suspect it'll change sooner or later.
What astounds me is the arrogance to claim that lisp(s) is the One True Language, and anyone who doesn't agree Just Doesn't Get It. It's like the audacity a religious person has in claiming that their god is the one and only, in effect taking for idiots all the millions of remaining people who ever existed and sincerely believed in their own creation stories. What are the chances that everyone is stupid and you're the only enlightened one?
I disagree with your examples. Taste is an odd thing that way.
Specifically, previous/next are great if you are reading it straight through. I agree this isn't that likely, but is nice to have. (I have actually used these. Recently, even.)
The fonts and colors are mostly pleasant. I can see how you would like other schemes. But I can't find anything atrocious.
I love how linked everything is. Specifically in the code samples. Even in the intro[1], all code samples are linked to the docs for what is there. Contrast this with the flask documentation, where if I want to see what @app.route does, I have to go find it elsewhere.
So, yes. There are things I would find to complain about if asked to look for them. At no point in actually perusing and using the site have these ever bothered me. And there are more niceties thrown in there that have made things easier than any of the complaints you mentioned.
Despite me not really liking Java all that much, the javadocs can be very useful; although in that example they chose a bad non-default colour - black on (dark) green is difficult to read.
I think we just disagree on taste for documentation pages. For example, I find the Vagrant docs somewhat garish and hard to read.
The current look of the Racket documentation was designed by Matthew Butterick. You can see his excellent book on typography and design here: http://practicaltypography.com/ -- and it was made with Scribble, the same system that generates Racket's documentation.
On the other hand, there is evidence here and there that this language isn't commonly used in production. For example, the pattern-matcher is very well-implemented and feature-full, but there's no way to use it programmatically nor is there a way to get the set of bindings. There is also the sad fact that Racket is a Scheme in the traditional Scheme fashion, and so is still trapped in an 80s design aesthetic. Generics are poor, ADTs aren't easily implemented, static types exist but are not so widely used and have strangenesses.