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