[Haskell-cafe] XText vs DSL in Haskell in mission critical software

[Joachim Durchholz]

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
> development".

"Model-driven" is actually fine. It's not defined by tools but by the 
approach.
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 
means.

 > 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 
free time.
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.
Regards,
Jo