As you may know, I am leaving Microsoft Research at the end of November. Time for something new! I am going to start a new role as Engineering Fellow at Epic Games in December.
Epic is doing all sorts of interesting things – not just games but other virtual reality stuff suchf as special effects for films, design visualisation, architecture, and so on. I will be working with my long-time colleague Lennart Augustsson and a team of others, on Verse. Verse is a new programming language that Epic is designing for their games, and in due course for the metaverse (e.g. listen to Tim Sweeney’s SigGraph 2019 talk). I also expect to work with Dan Piponi on data-centre-scale transactional memory. And probably more.
Epic is also happy for me to spend a substantial amount of time on education, on functional programming research, and Haskell and GHC in particular. I think this is extremely generous, and it means that I will continue to be pretty active in these areas.
Simon
PS: In fact Epic is looking for more people who know about programming language implementation (implementing Verse), and/or formal verification (reasoning about Verse). If you’d be interested, drop me a line.
@simonpj I’m interested in working on this, but don’t know your email to drop you a line. Mine is alok.singh@berkeley.edu. My background is mathematical, especially geometry, with some experience in automated theorem proving as well. Building a language for VR seems a natural next step.
In September of 1987 a meeting was held at the conference on Functional Programming Languages and Computer Architecture in Portland, Oregon, to discuss an unfortunate situation in the functional programming community: there had come into being more than a dozen non-strict, purely functional programming languages, all similar in expressive power and semantic underpinnings. There was a strong consensus at this meeting that more widespread use of this class of functional languages was being hampered by the lack of a common language. […]
Languages that contributed to this lazy Tower of Babel include:
Miranda
Lazy ML
Orwell
Alfl
Id
Clean
Ponder
Daisy
With the notable exception of Miranda (see Section 3.8), all of these were essentially single-site languages, and each individually lacked critical mass in terms of language-design effort, implementations, and users. […]
• Purity is more important than, and quite independent of, laziness
• The next ML will be pure, with effects only via monads. The next Haskell will be strict, but still pure.
• […]
Can the Haskell community now relax, confident that programmers everywhere have a reasonable understanding of “non-strict, purely functional programming languages” ?
Let’s see: have any new non-strict languages made their way into widespread use…so far, the only one I’ve been able to find is R. Assuming [!!!] this isn’t just a lack of knowledge or resources on my part…does one new (since the advent of Haskell) non-strict language count as success for “the Haskell project” ? If that’s the view of the majority of the Haskell community, then these remarks of mine are redundant, therefore I can delete them.
But if it isn’t:
[…] This paper provides further evidence that lazy evaluation is too important to be relegated to second-class citizenship. It is perhaps the most powerful glue functional programmers possess. One should not obstruct access to such a vital tool.
…and the siren call of pervasive imperativity is still just as beguiling:
A long time ago we had an effect system and we made pure the default (since we didn’t want people accidentally leaving it out due to sloth) and we made the impure specifier a very small and reasonable keyword: io. It was still a heavy complexity bill (required a full extra dimension of subtyping, parametricity, etc.) and still had people breaking the rule with unsafe, which meant that the putative benefits like “can do compile time evaluation” or “can spread on a GPU” weren’t there anyways. And people couldn’t do simple things like “put a printf in here for logging” (much like in [Haskell]).
Eventually people just took to making everything io, at which point it was a noise word and we decided to remove it (along with pred, which just meant pure, bool, and tracked by the typestate layer).
• How do you know if some operation is lazy or strict?
• Developers must choose the appropriate algorithm depending on their data and the call’s context
• It is difficult to reason about performance with laziness
• Parallelism and laziness interact poorly
• Stack traces are not available (fixed yet?)
• Lazy IO can also cause surprises
What’s the alternative?
• Strict by default
• Opt-in laziness.
In recent years we’ve seen all major PLC brands start to include the full set of IEC-61131-3 languages, and the most popular alternative to ladder logic is structured text. Now that it’s available, there are a lot of newer automation programmers who only ever knew imperative programming and never took the time to learn ladder logic properly, and they just start writing all of their logic in structured text. That’s why we’re seeing automation programming slowly shift away from the functional language (ladder) towards the imperative language (structured text).
Now I’m not suggesting that structured text is bad. I prefer to have more tools at my disposal, and there are definitely times when structured text is the correct choice for automation programming. However, I’d like to point out that the history of computer science has been a progressive shift away from Fortran-like imperative languages towards Lisp-like functional languages. At the same time, we’re seeing automation programming move in the opposite direction, and I think alarm bells should be going off.
APIs that interact with the outside world are unpredictable and make it difficult to test and simulate code paths in our apps. Existing solutions to this problem are verbose and complicated, so let’s explore a simpler solution by embracing singletons and global mutation […]
(page 34 of 35)
The rationale is good, but unfortunately Haskell is not a good starting point, for four reasons:
(1) eager should be the default instead of lazy (nonstrict),
(2) it does not have functional concurrency,
(3) it is not distributed, and
(4) you often want to hide an impure implementation so it looks pure from the outside
