The Future of Haskell Tooling
Haskell tooling, particularly editor and IDE integration has been sorely lacking for years. This talk will be a broad overview of the state of Haskell tooling, and the challenges faced by it. It will be derived from the experience of working on two summer of code projects trying to improve Haskell tooling.
For tooling users, we will discuss different Haskell tools available today(intero, haskell-ide-engine, ghcid etc.), their differences and trade-offs with respect to build tool support(stack, cabal, new-build, nix, make etc.), editor integration, features, limitations and speed.
We will go over the approach taken by haskell-ide-engine and the Language Server Protocol in order to solve these problems. Then we will discuss the new .hie file format designed to make information about Haskell source collected by GHC more accessible to tooling and users.
Finally, for budding tooling writers, we will discuss the various approaches to writing programs that extract information from and manipulate Haskell source, and their pros and cons:
- The GHC API
- Via ghc-mod and haskell-ide-engine
- GHC source plugins
- .hie files
Outline/structure of the Session
- Introduction to haskell-ide-engine and the Language Server Protocol with a brief demonstration - 5 minutes
- Discussion of the architecture of haskell-ide-engine and what it brings to the table in terms of solving the Haskell tooling problem - 5 minutes
- Introduction to .hie files - a new, build tool independent way to get information out of GHC - 5 minutes
- Comparison of various approaches to write new Haskell tooling in 2018 - 5 minutes
- Questions - Remaining time, if any
For people who wish to use Haskell tooling, this talk offers a broad understanding of all the different moving pieces that go into making their tools work(or alternatively, why trying to set up reliable Haskell tooling usually results in pulling your hair out)
For people who wish to write new Haskell tooling or contribute to existing tools, an introduction to what you need to know, from an overview of all the different approaches that exist to getting information about haskell source, to how users will finally end up interacting with your tool.
People who have been frustrated by Haskell editor tooling
Basic experience working with Haskell and haskell tooling.
schedule Submitted 5 months ago
People who liked this proposal, also liked:
Michael Snoyman - Functional Programming for the Long HaulMichael SnoymanVice President of EngineeringFP Complete
schedule 6 months agoSold Out!
How do you decide whether a programming language is worth using or not? By necessity, such decisions are usually based on assessments that can be made relatively quickly: the ease of using the language, how productive you feel in the first week, and so on. Unfortunately, this tells us very little about the costs involved in continuing to maintain a project past that initial phase. And in reality, the vast majority of time spent on most projects is spent in those later phases.
I'm going to claim, based on my own experience and analysis of language features, that functional programming in general, and Haskell in particular, are well suited for improving this long tail of projects. We need languages and programming techniques that allow broad codebase refactorings, significant requirements changes, improving performance in hotspots of the code, and reduced debug time. I believe Haskell checks these boxes.
Saurabh Nanda - "Refresh-driven" development with Haskell & ElmSaurabh NandaFounderVacation Labs
schedule 5 months agoSold Out!
We sorely missed the rapid "refresh-based" feedback loop available in Rails (and other dynamically typed web frameworks), while writing Haskell. Change your code, hit save, and refresh your browser!
In this talk we will share a few tips on how we finally hit productivity nirvana with ghcid and automated code-gen.
Best of both worlds -- rock-solid type-safety AND being able to reload code with every change.
Harendra Kumar - High Performance HaskellHarendra KumarEngineerComposewell Technologies Private Limited
schedule 5 months agoSold Out!
Haskell can and does perform as well as C, sometimes even better. However,
writing high performance software in Haskell is often challenging especially
because performance is sensitive to strictness, inlining and specialization.
This talk focuses on how to write high performance code using Haskell. It is
derived from practical experience writing high performance Haskell libraries. We
will go over some of the experiences from optimizing the "unicode-transforms"
library whose performance rivals the best C library for unicode normalization.
From more recent past, we will go over some learnings from optimizing and
benchmarking "streamly", a high performance concurrent streaming library. We
will discuss systematic approach towards performances improvement, pitfalls and
the tools of the trade.
Michael Snoyman - Applied Haskell WorkshopMichael SnoymanVice President of EngineeringFP Complete
schedule 6 months agoSold Out!
This full day workshop will focus on applying Haskell to normal, everyday programming. We'll be focusing on getting comfortable with common tasks, libraries, and paradigms, including:
- Understanding strictness, laziness, and evaluation
- Data structures
- Structuring applications
- Concurrency and mutability
- Library recommendations
By the end of the workshop, you should feel confident in working on production Haskell codebases. While we obviously cannot cover all topics in Haskell in one day, the goal is to empower attendees with sufficient knowledge to continue developing their Haskell skillset through writing real applications.
Harendra Kumar - Streamly: Declarative Concurrency and Dataflow Programming in HaskellHarendra KumarEngineerComposewell Technologies Private Limited
schedule 3 months agoSold Out!
Streamly is a Haskell library that marries monadic streaming and concurrency
providing an elegant way of doing declarative concurrent dataflow programming.
The Haskell ecosystem has some fine streaming libraries like pipes and conduit.
However, these libraries are inherently serial and provide no support for
concurrency within the streaming framework. Streamly is the first ever haskell
streaming library that defines and implements concurrency semantics within
a monadic streaming framework.
The streaming API of Streamly is surprisingly simple, it is almost the same as
standard Haskell lists, therefore, programmers do not need to learn a new DSL.
By using specific concurrency-style combinators, streams can be generated,
merged, chained, mapped, zipped, and consumed concurrently. Imagine your
program as a pipeline of queues composed in a combination of serial and
parallel configurations, and you can easily control which of these queues to
run concurrently and at what rate. The degree of concurrency is auto scaled
based on the feedback from the stream consumer, or based on a programmer
specified rate limit. Moreover, Streamly does not trade performance with high
level declarative concurrency, it provides excellent non-concurrent and