FPConf 2017. Interview with Alexander Vershilov

Hello!

We continue to talk about Haskell with FPConf 2017 speakers.

Pavel Argentov asked a few questions from Senior Software Engeneer at Tweag I / O to Alexander Vershilov , a programmer who has been promoting Haskell in the industry for 10 years.

')
- What project are you working on now? What is its feature.

- This is a web service that can be simply described as “Excel on steroids”. It allows the use of arbitrary languages ​​for calculations - Python, R and some more.

- Are the procedural objects accessible to the user created in these languages?

- User can use his libraries; in formulas inside cells, you can put, for example, code on Python: objects implemented in this way can be used directly in the “Excel” table. They can also be accessed from procedures in another language - for example, R.

- You are a Haskell developer. What is the location of Haskell in this whole story?

- Central :). The server itself is written in Haskell. It accounts for all the industrial workload associated with queries, all the logic of dependency graphs and execution. The remaining languages ​​are represented by user procedures that do local calculations and return a result.

- Will you reveal any features of the server-side implementation?

- On FPConf, I will talk in detail about the architecture of this entire solution. I will try to tell you how, what and why it was done.

- It is now easy to google cases of successful use of Haskell as a language for creating tools for analyzing and verifying code, tools for massive calculations; in your case, Haskell is used as a language for loaded server components. I would like to expand this topic a bit. What are the winning points, or vice versa, the problems of such a practical use of Haskell?

- In Haskell, a somewhat paradoxical situation has now developed, where, on the one hand, there is already an excellent runtime system suitable for solving practical problems, on the other hand, problems like the idiotic default GC settings are visible - they need to be rewritten whenever you need to do something it works. There are good libraries, but the standard library is terrible. There is no common understanding about the style of writing code. There are many libraries and many methods that are not brought to such a state that you can say: “This is the best!” Or: “Here are two good options, we will choose the most suitable.” It often turns out that if a project is being done that does not need maximum efficiency, then all is well. However, as soon as the moments begin where it is necessary to squeeze the greatest performance out of the code, problems begin. Often you have to finish something, rewrite. The ecosystem as a whole is moving in the right direction, but in my opinion, not fast enough. There are competing options in trying to solve problems, but there is no acceptable overall solution.

There are problems “standard language”, for example, with laziness. Honestly, I would not even call it a problem. Until a certain point, you can write and not worry about laziness - it usually works. Sometimes, when something breaks, you have to sit down, debug, understand, but this is already a problem of a slightly different kind, it implies a deeper acquaintance with the language and its tools. There is a problem with GC: there is a lot of this in its mechanics, which leads to unnecessary delays when executing code ...

- So he does “stop the world” and ...?

- Yes, he does “stop the world” - and collects all that is possible. Then, if the task is to return the answer in the shortest amount of time, problems may begin. As I recall, the company Pusher (Pusher.com) even left Haskell, because they could not solve this problem. They needed a very short response time. In the end, they decided that it was easier to take another language that would provide what they needed by default.

- What did they take, if not a secret?

- In my opinion, Go.

- In recent years, Haskell has quite actively “fired”, suddenly becoming from a purely academic - quite a working tool. Naturally, interest in him was expressed in the fact that people began to write libraries. What are the features of the Haskell library world?

“Haskell is still a research-language where many people try to play with the solutions that they think are right for their problem. For example, we write a program in stream processing style. The program tries to work in constant memory and monitor resources - in this case we need a stream interface. A whole range of such libraries is available on the net. Unlike ecosystems that try to maintain one generally accepted solution, the Haskell ecosystem has many good solutions for many problems.

- What's in Haskell with library management systems?

- There are Cabal and Stack. I suspect that now the balance of popularity has shifted towards Stack, for various reasons. It developed much faster, its interface is simpler, and, in general, when it works, it works. The mechanics are such that if a project is described through a stack-file, then with a very high probability, the person who launches it will get something working.

- That is, isolation of dependencies is implemented in the best possible way, a sandbox is created, into which you can connect the necessary libraries and build the application?

- Yes. Basically, “cabal install” was also able to do it. But it was necessary to make more movements. And in general, everything was more complicated. It’s much easier for a beginner to teach two stack commands than to explain how cabal install works. The big plus of the stack is that it runs on top of Stackage — the original Hackage “slices”, within which the dependencies — programs and libraries — are compatible with each other.

If a person adds a package to Stackage, he, at a minimum, guarantees its collection with other components of the current stack. Otherwise the package will be excluded from the stack. It is always assumed that if the package is on the stack, then it is supported.

- Does the Haskell environment have documentation problems? What documentation is more common - good or mediocre?

- People are often unhappy with the documentation, and I agree with them. Usually the documentation is not very good. This happens because people rely too much on types - if you read the description, you can understand what is being done. Sometimes this is enough. However, there is a lack of a certain higher level of documentation - where it would be described how to start using the library, what are its main use cases. Basically, we find in the documentation a description of functions or data structures without a high level explanation. The documentation requires a special module - a tutorial, and only a few authors understand this.
When choosing a package, I look at the name of the author. After spending some time in the ecosystem and knowing certain people, I prefer the libraries of some authors to others. In general, the final solution to the issue with the documentation yet. Calling a short set of simple actions to find a library that solves the desired task in the specified area is not yet possible. For now, the best option is to ask people who have already solved the already mentioned problem.

- And if you pay attention to the number of stars in the project on the githaba?

- I did not pay attention ... I did not notice a clear correlation between asterisks and the quality of the code. Not everyone in the community likes to put an asterisk if they think the package is good. Personally, I never do that. For some reason. For me, the asterisk is a mark of the library as simply interesting.

- Another amateurish question. What is Haskell's demanding math training programmer? Does it scare people away? Or the understanding that Haskell, like all normal languages, solves and does not create problems, wins - and a person is able to enter the language without significant problems?

- I entered Haskell, having zero knowledge in category theory, some programming knowledge and experience in PHP. That is, in principle, if you do not fear and understand a few simple things - why do you need a type checker, why is he a friend, not an enemy, and so on - many “horrors” disappear by themselves. There is no need for particularly advanced knowledge in mathematics, although they help to read the documentation of some packages.

When you write a simple program, it is not always necessary to climb into the mathematical maze of documentation. By the time it is needed, some necessary knowledge has already been accumulated by itself, or there is already at least an intuitive understanding of the necessary things. The main thing is not to be afraid. But if we assume that the programming language should be such that nothing new is ever needed, then of course, problems may arise with Haskell.

- People are now pragmatic, they immediately ask what problem this tool will solve. What typical problem can a pure functional language solve for a programmer?

- Complex issue. Anyway, any language will solve any problem. What attracts me to FP languages ​​is that it is much easier to build universal abstractions in them. The peculiarity is that if we compare compose programming patterns, there is a facade in ordinary language, in FP it is a function, here the builder is in FP again a function. Almost everything comes down to the design of functions. More or less simple functions are blocks for building complex programs. Functions are very well packaged. It is very easy to write utility modules that are suitable for everything you need. If the language is clean, we have a clear separation of functions and effects - it helps to write the program not as a set of hacks, but as a system of functions with a clear division of responsibility.

- It as if forces the programmer to think properly, I guess correctly?

- On the one hand, yes, it makes you think properly. And on the other ... I just could not write the same complex programs in many other languages.

A big plus of Haskell is that there is a type system. It helps us protect ourselves from mistakes and other troubles. The better the type system, the more convenient the refactoring is: if we want to change something and violate the type match, it will be immediately detected. On the other hand, there is no problem arising in languages ​​with more powerful type systems, when, when making changes, it may be necessary to significantly change the program, since the evidence of properties was built on it. In this sense, Haskell is at a local minimum: ease of refactoring with a fairly expressive type system.

- Despite the slimness and severity of the language, an experienced developer always, if he tries, will be able to "shoot himself in the foot." What would you mark as Haskell problems for experienced developers?

- The biggest problem is tulling. When you write a project, you need to profile it, turn on the debugger. Those utilities that are available in the Haskell ecosystem are rather at the development stage. In this, we are still behind progress, and the speed of development of debugging tools leaves much to be desired.

- How good is Haskell in parallel or competitive solutions?

- From my point of view, everything is fine here. All projects we run use concurrency. The available RTS is simply superb. There are different libraries that allow you to parallelize the calculations. Even in normal code, execution can be parallelized very cheaply - literally in one combinator, one effect.

- The conference will be attended by people who not only code, but also hire coders. They plan projects, they are businessmen. They will evaluate the risks ...

- There are risks. Big risks - if you recruit a team of new people who yesterday programmed in an imperative language - and suddenly they are given Haskell. Then there will be problems. But if the team has several people with experience - for example, for five people, two experienced Haskellists - then the situation changes dramatically. All library search problems disappear because experienced developers know the risks of using different libraries. Moreover, there are many companies that can advise, do code auditing and “proof of concept”, or simply suggest how to solve architectural problems. Such circumstances can significantly facilitate the work at the initial stage.

- For which business solutions Haskell is most suitable and for which - not so much?

- There are tasks in which additional guarantees of the correctness of the code are needed, because the wrong code is expressed in specific monetary losses. In these cases, due to Haskell, you can get a significant gain. There are many examples of companies that worked with finance and understood that they want more guarantees of development efficiency. In such cases, Haskell makes sense. Further, there are various infrastructure solutions. For example, you need to run many services on Amazon, configure their dependencies, one thing and another. It is often easier to write concise DSL in Haskell than to write a lot of code in a language that does not help at all.

- This DSL will be read for the person who set the task?

- Yes, plus types.

Haskell is also useful where you need to generate code, write DSL, your compilers. On Haskell, you can generate C, Python, Java for use in complex multilingual solutions.
But where not to go to a firm that is not Haskell-oriented, is where there are ready-made big solutions in other languages. To rewrite Haskell with a system on Erlang or Spark is not the best idea.

- What are Haskell’s requirements for management literacy?

- The ability to listen to responsible programmers. The manager may not have enough experience analyzing functional programming. The industry has already accumulated experience and books in the field of more familiar languages ​​- how to design and plan correctly, how many times the programmers call deadlines, tons of volumes are written. In the field of functional programming, this amount of material has not yet been accumulated. Accordingly, it is necessary to be able to properly speak with those who better understand this - or carefully understand it yourself. And soberly assess their knowledge.

Interesting? Learn more from Alexander will be on December 2 at FPConf , come!