On Racket, CL, limits, programmers...
I've found that most stuff can be done in Racket, and, though I have
used CL when required by two consulting clients' prior implementation
choices, I'm not aware that CL has any key advantages over Racket. (Not
bashing CL; it's a nice platform, with an unusually smart developer
community. And, earlier in Racket's development, CL was noticeably more
proven and mature for industrial use. I just have few complaints about
being married Racket today, and there's no temptation to philander with CL.)
Regarding using Racket primarily, with backup options... A long time
ago, I noted a few other Lisp/Scheme variants (Gambit-C, Kawa, Chicken)
to keep ready as backup options, for particular technical properties
that I might need, as well as making sure I could fall back to C if I
needed to. So far, I haven't had to use any of my backup options.
Main situations in which Racket sometimes isn't suitable, I think
usually a CL implementation wouldn't work either:
* Browser-side AJAX-y apps, both underlying browser stuff and layered
frameworks/libraries. Developing for this is largely about cursing
frequently -- every time you're reminded that people who have little
idea what they're doing have now determined the platforms that everyone
must build upon. Not only are the platforms bad, but way in which most
developers now think about software development is a step backwards from
what it was before: institutionalizing a mixture of clerical bureaucracy
and cargo-cult kludging methodology.
* iOS and Android phone/tablet apps. No Lispy platform for this I've
yet seen is satisfactory, but I see no technical barrier to a good such
platform, unlike for browser apps. And one promising note for the
future is that you *could* bypass most of the layered browser platform
dumbness. (At the same time, business-wise and politics-wise, doing
apps other than HTML5 Offline usually pushes you into using the
proprietary app stores for most non-intranet purposes, and the app
stores tend to be abused in practice. The monopoly abuse isn't entirely
cyclical in computing industry history, there is some variation in form
and dynamics, but there are recurring patterns you can see coming a mile
away each time, and a lot of them are now standard practice/aspirations
for companies.)
* 3D action games. I haven't yet tried this one yet with Racket, and it
*might* be doable even with the current stock VM, but I anticipate GC
pauses being an issue to get past. I'm not going to write a 3D game
engine in CL, neither, and, realistically, I'd probably end up doing the
performance/realtime-sensitive parts in C or C++ (or something that
compiles to C/C++, or to LLVM), plus whatever is appropriate to offload
to the GPU.
* Some embedded systems, and some "embedded" application extension
languages. I'm conflating these two related but distinct things, just
to quickly acknowledge them. John Carmack recently reported putting a
small Scheme on an embedded system, while keeping Racket on the
workstation. I recently found that Racket for some apps will actually
work on particular home OpenWrt devices. Much older versions of Racket
(older PLT Scheme) were more suitable for "embedding" (linking into a
C/C++ app, to be called by the C/C++ code) as an extension language,
though today I would put Racket in a separate process with some kind of
simple IPC channel, or start with a Racket process and have Racket FFI
the C/C++ bits. I'd say the Racket suitability question on these is
case-by-case.
* The rare long-running heavy number-crunching. Racket has been
improving in this regard, such as with the Typed Racket optimizing and
the unchecked native integer/float operations. But sometimes you'll
still just need heavily-optimized C, hand-tuned assembler,
GPU/FPGA/ASIC, cluster/supercomputer. Or old Fortran 77 routines
written by ancient aliens, that everyone is afraid to modify. (Some CL
implementations have optimization hint affordances, but not enough to
make me go from Racket to CL, rather than from Racket to the
previously-listed.)
* Seamless threads to multiple host cores/processors. You have to think
a lot harder to work around this.
That said, most of the performance problems I see in apps using
languages/platforms of any kind are not due to the language/platform,
but failures of the programmers. Offhand, I'll group these programmer
failures into three kinds: poor algorithmic time and space complexity,
poor understanding of the language execution model, poor understanding
of systems/resources external to the language execution model. No
developer is ever perfect and omniscient, but we all keep learning and
growing over time (perhaps stunted, if we go to the kind of dotcom where
developers are sometimes called "rock stars", including the connotation
of management expecting developers to be drug-fueled). I'm comfortable
asserting that developers' skill development (and sobriety!) is the key
to a lot of runtime performance problems that get blamed on particular
languages.
Neil V.
--
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.
