[Haskell-cafe] XText vs DSL in Haskell in mission critical software
jo at durchholz.org
Wed Nov 28 06:05:41 UTC 2018
Am 27.11.18 um 23:21 schrieb Puck:
> Hello all,
> how can I convince my bosses to use existing functional languages for
> specifying the future embedded softwares from the company instead of
> using Xtext or other things that firm under the name "model driven
"Model-driven" is actually fine. It's not defined by tools but by the
BTW Xtext is a toolchain for creating a DSL parser. It can be used for
model-driven development, in the same sense that a coding toolchain can
be used for model-driven development.
So I suspect various people misunderstood what "model-driven" actually
> how can I convince my bosses
You do NOT try to convince them unless you already have a standing of
providing feedback that they consider useful. Without that, you'd have a
hard time convincing anybody, even over small things.
You also do NOT try to convince them if they already have spent
considerable time thinking about their approach; you'd be demanding that
they throw away everything they already invested in the strategy. In
that case, you simply take a look at what they're doing.
You understand what constraints they are operating under, take these
constraints seriously (otherwise they'll just dismiss your feedback as
"interesting but irrelevant to the problems I'm currently solving"), and
present your approach as helping them overcome limitations - which means
you also need to understand the pros and cons of the toolchain that they
are currently aiming for.
> Why they do not use plain Haskell, LiquidHaskell and Coq?
> Neither can I imagine, that Haskell or Coq is so hard to learn, neither
> can I imagine that they want the developers to dive through handwritten
> Java extensions for their tool, that can only be analyzed with
> Java-tools and cannot be proven.
You are underestimating the raw cost of learning a new ecosystem.
Haskell - the language - is in fact easy to learn. Any experienced
programmer can learn a programming language within a few weeks.
Learning to use that language *competently* takes months, and learning
it well enough to make architectural decision takes years.
Integrating a new programmer into an existing project is hard enough.
The consensus is that a new hire will be a net loss in the first six
months: Contributes very little, but keeps colleagues off their own work
because they have to explain stuff to him: Project conventions,
architecture and details of the existing codebase, project goals (what's
important and what isn't), procedures (git branching conventions, issue
tracking, definition of Done, etc. etc. etc.)
Learning a new language on top of all that means that a new programmer
will take at least two years until she is productive. A programmer costs
roughly 50% more than his wages, so even a cheap one at 60k/year will
cost the company 200k and a delay of two years; if time to market is a
consideration, that's an absolute killer.
Oh, and two years means that some competitor will simply outpace your
company, if such a competitor with an experienced team already exists.
You *might* have a chance to argue against the language-experience
barrier if they are 150% confident that the company project exists for
longer than two years.
They also need to be 150% confident that what you say is true. If you
have hard, experience-backed proof that Haskell (or whatever) is giving
them faster results, AND they will have to hire programmers anyway, AND
you can tell them where to find Haskell programmers, then they will listen.
If any of this isn't given: Don't damage your reputation by building an
impression of a daydream who doesn't know what he's talking about. Use
the experience as a learning opportunity. See what works and what
doesn't. See what people can do and what they cannot do.
One more thing: If Haskell is *that* much better than Xtext, you should
be able to produce better results by coding the stuff in Haskell in your
If you succeed, you'll be able to prove that the alternate approach is
better (but you should be very cautious about taking that proof to your
bosses - by the time you can do that, they will have invested too much
in their approach and would lose a lot of money if they switch).
If you fail, you have learned something about what kinds of roadblock
exist even with better tools.
> Is XText, for example, really so good?
> Is a Haskell-DSL as a counterpart, not very much fewer dependent on
> other things, and very much easier to maintain?
I don't think that anything Java-based is so much better than Haskell.
However, Java has a great library ecosystem. It has been amazing me at
what's available since Maven became a standard repository format; the
latest amazement was what they delivered with Apache Kafka (I'm working
in a company that processes millions of externally-provided records per
day, where near-realtime is one of the important priorities; stuff like
Kafka is what grabs our attention).
And libraries are what makes an ecosystem viable. Language properties
decide what kind of ecosystem starts to exist, but sometimes it's
surprisingly trivial properties that have an impact. For Java, I think
three decisions were crucial: The decision to have a universal binary
format (the JVM bytecode) so compiler variation does not block code
reuse (as it has happened in C++); the decision to use DNS domain names
as library qualifiers so it's clear who's responsible for placing
modules where in the namespace (this is an ongoing problem in almost all
languages); the decision to have strict compatibility requirements on
implementations, so the code will have identical semantics on all
platforms (and they kept improving on that over the first ten years).
I'm not sure how good Haskell is in these areas.
I have seen some pretty impressive library work in Haskell, so it isn't
bad, but the JVM ecosystem is really, really good. You may find that
while you can solve problems faster in Haskell, less readymade solutions
are available. Doesn't make Java any better, of course (the language
itself is pretty meh, it's the Cobol of today: too limited and too
verbose to be fun to work with); but the quality of the language itself
is just one of several important factors for developer efficiacy.
Just my 2c.
More information about the Haskell-Cafe