Hello wonderful all!
Let us introduce to you our next incredible speaker Ivan Gromakovskii, he is a Haskell software developer and team lead at Serokell with 6 years of experience in Haskell.
For people who work in Haskell, what Library do you desperately want someone to write?
Generally I think that all commonly needed (for a wide range of problems) libraries already exist and are quite good. When I need something that I can't find in existing libraries, usually it's either something too specific to my problem (e. g. a library to interact with some specific service) or some functionality missing in an existing library. At the same time we can't say that Haskell is the best language choice to write all software one could possibly imagine. It's really good for certain problems (many of them), but it doesn't need to be a language for everything and it's completely ok that for different problems different languages are more suitable. For example, if you need to do scientific computing (interpolation, optimization, matrices), you will likely choose Python which has NumPy and SciPy which are really nice and used by a lot of people. I think Haskell could also be a good choice for scientific computing, the language itself provides a good basis, but there are no libraries as cool and popular as NumPy. So I want someone to write a library that would make Haskell as great for scientific computing as Python is nowadays.
What would be your favourite piece of Haskell-branded clothing?
Funny that you ask, Serokell is actually working on a line of clothing with several very cool FP-themed prints. It will be quite hard to beat those for me.
What I Wish I’d Known When Learning Haskell?
For example, I wish I'd known about the async package, it would help me properly manage threads in my applications.
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 am generally not a fan of frontend/UI development, I prefer to develop backend servers, command line tools, libraries, etc. That said, I've been working on full-stack applications (frontend+backend) lately and our default preference for frontend is TypeScript and React. We were considering Haskell (e. g. Miso, Obelisk) for frontend development in the last project, but we decided to minimize the risks and use a more battle-tested approach (i. e. TypeScript and React). If Haskell becomes more suitable, mature and popular for production frontend development, I'll be happy to work on a project where Haskell is used on frontend.
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?
If we talk about the websites, I prefer Hackage because it loads faster. But I use Stackage snapshots and include stack.yaml in all projects, so I use Stackage website as well to see what versions are included in what snapshots. If we talk about tools, I prefer cabal to stack and use cabal.project.freeze files generated from stack.yaml.
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 don't code as a hobby, at least regularly. I think there is enough programming in my life as part of my job. Also I usually like what I do at my job and since I have free working schedule I can code (not as a hobby) at any time. I may rarely code something for myself just because I want.
If you wanted to convince someone to use Haskell, what would you say?
When I was new to Haskell one of the first things I noticed and liked was its clarity, meaning that Haskell code is usually short but at the same time not hard to understand. Many things that seem complex in other languages are just 1 or 2 lines of code in Haskell. In other languages there are many "programming patterns", but in Haskell they mostly boil down to function application. Another selling point is Haskell type system that allows to catch a lot of bugs in compile-time. However, this point may be dangerous since it decreases motivation to write tests and even run your programs to check their correctness. The first point is dangerous as well beacuse it makes Haskell programmers lazy, but it doesn't matter if I just want to convince someone to use it.
If you could change one thing about Haskell, what would it be?
There are several things and of course it's hard to choose only one. But for example I would really love to decrease redundancy in the world of Haskell libraries. If you develop a medium-sized application, you may quickly get 200-300 or even more transitive dependencies. The sad story is that some of them use different approaches for the same problems. For example, some libraries may use a custom prelude and we have a plenty of them. There are 3 type classes that allow us to use catch function in a monad other than IO: MonadCatch, MonadBaseControl and MonadUnliftIO. All 3 are defined in different packages that don't depend on each other, so ideally you would use only one of them, but in your application you'll most likely end up depending on all 3 for historical reasons. Another example is lens and microlens, you are very likely to depend on both. There is redundancy in less popular libraries as well, for example pretty-terminal and colourista are very similar. Just to be clear: I don't mean to blame people who develop all these libraries and it's good that we have a choice. I am talking about the perfect world where each problem has a single globally accepted solution that everyone likes. Such an issue exists for historical reasons: there is X that everyone uses, but not everyone likes, then someone creates Y as an alternative to X and we have both X and Y in use.
Ivan will be performing on the 10th of September at 11.45 CEST about Exceptions and concurrency! You should definitely join Ivan and don't forget about Q&A in SpatialChat.
FREE Register to attend
Check out our Website
Learn the whole Schedule
Join us on Twitter
Top comments (0)