On 27 Dec 2018, at 0:04, Neil Van Dyke wrote:
Jason Stewart wrote on 12/26/18 5:25 PM:
Even for blue-sky projects without any legacy lock-in, I don't fancy
our chances with the enterprise/MIS crowd. They tend to favor
straight-jacket languages, and for good reason!
Agreed. (A big-corporate exception being R&D and "startup-like"
units, not necessarily under MIS, like some might have in, e.g.,
fintech.)
For some guy running a two-man startup, something like Racket is a
super weapon. For a large organization--with any staff turnaround
at all--metaprogramming is cancer. They need a "paper trail" for
the next guy to follow.
Them's fightin' words. :) For a counterexample, consider a
programmer inheriting a project with an LALR or LR(1) parser written
voluminously by hand, and a programmer inheriting a project instead
using a parser generator DSL. The non-DSL-using code might never be
understood enough to find the bugs or extend it correctly. The new
programmer might not even recognize the model that the non-DSL-using
one is supposed to be implementing, nor stick to a documented model in
what changes they do. And then a third programmer comes along, and
then a fourth...
In an organization with good software engineering, judicious use of
DSLs, and having them well-documented, tested, and maintainable, seems
a win.
I think bigger barriers to enterprise adoption of Racket than "I heard
that 'metaprogramming' eats your babies" are:
(1) Wanting employees to be interchangeable cheap commodities.
(2) Wanting someone to blame/sue/consult if anything goes wrong.
I'm happy to let "the enterprise" wait to adopt Racket until after
everyone else has had years of success stories.
I think we agree that startups are a much more likely path for Racket
commercial uptake.
I've had some moderate success in established, non-Racket companies by
working around -- rather than taking on and trying to replace -- the
main language & toolchain. For the PHP shop where I work, I made a DSL
called Riposte [1] for testing HTTP APIs. It has become, in time, the de
facto tool for such things. Thanks to Riposte, all developers have
Racket installed on their workstations, even though I'm the only one who
knows Racket and can fix problems with the tool.
I made a tool (1) whose benefits to my boss and teammates are obvious,
(2) which is clearly hard to do in the main language, but (3) which
would not kill the main line of development if I were to go away. A boss
who respects his employee's skills and their need to "do his own thing"
while still helping the company may indeed welcome Racket, in limited
ways, on these grounds.
I might advocate for just making great tools/languages privately, then
trying to make the argument for them later. The opposite is trying to
get permission up-front to do something in Racket. That's less likely to
succeed, I think, than just making something great and explaining its
benefits, over time, at opportune moments. In my case, that meant
talking with co-workers about their work and asking: "How can we model
the proposed change in the API and be sure that we've really succeeded?"
The implied answer being: "Write a Riposte script." That's the moment
where it becomes clear that what I made has real benefits. I don't even
"push" Racket. I just introduce the DSL and show them how it helps them.
Jesse
[1]: https://riposte.in
--
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.
