DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 964,423 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Anastasia Khomyakova ❀ for Konfy

Posted on

"The Haskell ecosystem has really mature"β€” Thomas Tuegel

Hello Haskell Lovers!

Haskell Love is around the corner and we are happy to present you the interview of out next speaker - Thomas Tuegel.

Thomas Tuegel is a physicist-turned-software-engineer who has been passionately using Haskell for 13 years. He has worked on Haskell projects in a variety of domains, from build systems (Cabal) to numerical simulations to theorem provers.

For people who work in Haskell, what Library do you desperately want someone to write?

The Haskell ecosystem has really matured since I began using Haskell. When I started, it was still a challenge to find all of the high-quality general purpose libraries you would need. If you needed libraries for a specific domain on top of that, you usually needed to write your own. If anything domain-specific existed, it probably wasn't very mature. Now, we have really high-quality general purpose libraries. We also now have deep coverage
(high-quality libraries) in many domains, but I think we still lack the breadth of domain coverage that you would see in a more mainstream ecosystem. In broad terms, that's what I miss with Haskell.

If you had to pick one thing to include in the next Haskell Report, what would it be?

This is a difficult question to answer: it has been so long since the last updated report that almost any update would be welcome, but it has been so long that a considerable backlog of worthy candidates has accumulated. If I could pick only one addition, it would be MultiParamTypeClasses. This extension is so ubiquitous, and so obvious, that I can scarcely imagine writing Haskell without it. Honorable mentions go to FlexibleContexts, TypeFamilies, and TypeApplications.

What would, in your opinion, be a Haskell β€œkiller application”?

To me, a killer application is something that would make Haskell indispensible. For example, machine learning is a killer application for Python. This is tough to spot because it's usually something new; you can't very well move into an existing space and take it over as your "killer application". So, you have to look at where people are doing cutting edge work using Haskell that isn't about Haskell itself.
I think language implementation is already nearly a killer application for Haskell. It's not a new space, but it's one that Haskell has occupied for a long time. I think what would propel Haskell over the top here is something like a middleware for languages: you provide the syntax and some semantic rules and the
middleware provides a parser, interpreter, compiler, and so forth. Graal tries to provide this for the JVM, but I think Haskell provides the pieces you need to build something much more flexible.

What would be your favourite piece of Haskell-branded clothing?

Strangely, I don't actually own any Haskell-branded clothing. But
hypothetically, a Haskell sweater would be very on-brand for me.

What I Wish I’d Known When Learning Haskell?

I ignored monoids for too long when I was learning Haskell, but now I see them everywhere.

Once we were over the infamous Haskell learning curve, we began looking for functional programming, immutability, and types everywhere! Given that most modern applications are web apps, it is only a matter of time before we make the switch to typed-FP for front-end development. Would you write the front end in Haskell?

I would probably not start a typical web app frontend in Haskell today. This largely reflects my own aversion to technical risk: I am not aware of a production-ready Haskell to JavaScript compiler. I would not want to track performance across multiple browsers on multiple desktop and mobile platforms. I would want to take advantage of the enormous JavaScript ecosystem (not only libraries, but documentation!). These issues are not fatal to a Haskell frontend effort, but each represents a risk. Haskell on the backend is pretty boring, from a technical standpoint; Haskell on the frontend is too exciting for me.

State of Haskell Survey results in 2020 shows that the number of developers who use Hackage vs. Stackage is almost the same. Which one do you use, why?

I have used both Hackage and Stackage professionally. For my personal projects,I mainly use Hackage because I want to keep them continuously up-to-date.

96% of respondents of the State of Haskell Survey said they code as a hobby,do you? Is that for an open source project?

I do write code as a hobby, though much less than I used to. I maintain a few libraries and tools to suit my own needs. Outside of Haskell, I also work on Nixpkgs.

If you wanted to convince someone to use Haskell, what would you say?

Haskell reduces uncertainty in the software development process. I think there is a "happy path" to writing reliable, maintainable software in any language.
Risk enters because we stray from that path, unintentionally. Haskell gives us feedback to find the path, and tools to get back to it. Haskell has many features that set it apart from other languages, but giving the developer feedback might be Haskell's most unusual feature. It's certainly among the most useful.

If you could change one thing about Haskell, what would it be?

If I could change one thing about Haskell, I would replace Haskell's module system with the proposed LocalModules extension. Teams using Haskell really lack good tools for managing names. It's not so important when a project is small, but this type of organization is really critical once you have more code than you can comfortably read in an afternoon.

He will be performing on the 10th of September at 15.25 CEST at Happiness Track, and don't forget to join Thomas at his Q&A at SpatialChat

FREE Register to attend
Check out our Website
Learn the whole Schedule
Join us on Twitter

Top comments (0)

🌚 Life is too short to browse without dark mode