If we want Racket to become used by more people in industry I think we should include more information that addresses the misconceptions of many imperative style programmers in industry that may push them away from developing in Racket. Information that emphasizes why Racket is “practical”.
When I talk to my programmer friends who work in industry and who typically use c#, c++, java etc. there are certain misconceptions that keep coming up. 1) All scripting languages are slow (and pretty much the same kind of like PERL). 2) LISP and all LISP dialects (including SCHEME) are used by Academics for playing around with artificial intelligence and are totally impractical for programming in the “real world”. To speak to this audience I would emphasize that Racket was designed to be practical. 1) The module system makes large development projects easy to organise and trivial to resolve any naming conflicts. 2) Its “fast”. I think someone just posted that Racket should be 10 times faster than python. Tight loops are only 2 to 3 times slower than in C. 3) The FFI lets you interface to other packages and most importantly if Racket changes its version or the package you are interfacing changes its version the interface to the foreign package still works. In my experience this was a problem with using for example Ruby to imagemagick and Python to its windows tools third party package. 4) You have “unsafe operations” that allow you to do unsafe things if you need to. But they are labelled as unsafe. 5) Because it is a fully bracketed language it is much easier to learn than unbracketed languages. You don’t have to remember operater precedence rules. You don’t have to remember “Does this language use “;” at the end of the line or not? There is almost no syntax you need to learn. 6) The IDE is extremely simple to learn and use and is linked to the documentation and has a built in debugger. You can learn it in half an hour. 7) It has extensive libraries (this is mentioned) 8) What other language lets you ask questions on its mailing list to the language developers. 9) MOST IMPORTANTLY all these factors greatly reduce debugging time. Before Racket I would typically spend 25% of my time developing and 75% debugging. Now with Racket I typically spend 75% of my time developing and only 25% debuging. Harry Spier
____________________ Racket Users list: http://lists.racket-lang.org/users
