On Jan 6, 2016, at 2:01 PM, JCG <griffin...@gmail.com> wrote: > >> I will say this as the first Racketeer and Typed Racketeer: if you just want >> to program in an explicitly-statically typed language (possibly with >> inference), you might wish to broaden your scope of search. There are other >> expressively typed languages that come with good libraries. Most of these >> languages are much more mature than TR and probably more reliable and stable >> (in this sense). >> >> I am not sending you away. I am a scientist-designer who wants >> user-developers to be highly informed. > > I'm looking for a middle ground between Python and C++, the two basic > language tools in use at the office. I like typing fast with my fingers and > typing loose with my data, until it passes 100 lines of Python, the point at > which my opinion flips 180 degrees. After 100 lines, my option is to go to > C++ or put another tool in the mix. Here are my constraints for a potential > middle ground tool: > > 1) It must run on command-line non-X11 Linux, (and OSX as well if possible) > 2) It must have a reasonable FFI to use our proprietary C++ libraries and > allow foreign controlled data structures. There are pointers to substantial > C++ side heap allocations requiring execution of C++ destructors at disposal > time. > 3) The nature of our library calls is that a language permitting optional > named arguments > is almost a requirement to harness the capabilities of our library. > 4) It must be considerably more productive than C++, otherwise it's C++ > 5) I've had enough uncaught flaws in Python that I'm now convinced that I > need types. > 6) It needs pattern matching, otherwise I'm back to C++, flex and bison or I > have to figure out Stroustrup's Mach 7 which does not yet seem settled. > 7) A reasonable size, polite, and intelligent group driving the technology. > > My preferences include: > > 1) reasonably fast executables > 2) Lightweight threads > 3) Reasonable ability to use multiple cores safely. > 4) Reliable environment generating reliable JavaScript
Hmph. > 5) Immutability of data > 6) Weighted more towards functions than objects > > > So, two things come to mind, Racket and SBCL because I've used them before, > and the ML family - Haskell, OCaml, and Scala. Having tried Scala, I like > the language but the associated environmental baggage appeared heavy and > brittle from build dependencies. Both Haskell and OCaml seem quite plausible. > Having types potentially in Racket keeps it in the running. > > Anyway, Racket floated first to the top because I reimplemented a network > service that really needed pattern matching to combat the growing complexity > of patterns. I grabbed a familar (untyped) Racket and made a prototype. > Unfortunately, the prototype worked so well that I'm using it now for real. This makes you the normal Racket developer and (as I have said) an ideal candidate for TR. > Nevetheless, it has the smell of something that might be easier to maintain > long-term with compiler-checked type annotations. Typed Racket has improved > or at least my utilization of it considerably since I looked at it about 4 > years back. Likewise, the places module which had previously been for me > ungrokkable and lethargic was now easy and fast enough. > > While those MLs are definitely still in mind, I'm going to get more > comfortable with Typed Racket first. Great. Keep pushing, we'll keep improving -- Matthias -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
