This Tuesday I gave a talk at the fantastic (currently zoom only) Berlin Functional Programming Meetup about F#. I gave a brief introduction to the language, then showed how to download and analyze some historic weather data and serve this up as a small SPA web app. Below you can play the recording - have a look and let me know if you have any feedback.
I’ve used F# a lot in the last 3 years and for quite some time I wanted to collect a few good starting points to venture into F# in one place. I also wanted to collect some of those random things that I felt weren’t easily available anywhere because they fall through the cracks of the official language reference and library documentation. While writing this post I had two inspirations in my mind: Hillel Wayne’s post “Why Python is my Favorite Language” and Stephan Diel’s “What I Wish I Knew When Learning Haskell”. In the end I wound up collecting a high level view of the upsides and downsides of F#; a section about how to run/edit/debug F# code; and then a collection of small pieces of information that I think can easily confuse newcomers.
In the last few months, climate change has been discussed with renewed vigor in the media and on social networks. More and more people realize that we have a problem but a lot of the current focus doesn’t seem to be directed at the pragmatic goal we should be aiming for: mitigating climate change as far as possible.
The frontend programming podcast Working Draft interviewed me recently and we talked about Elm and F# . Hop over to the interview and let me know on twitter if you have any comments!
The field of software engineering is in a strange place today. A lot of the mainstream tools and concepts look less like deliberate choices made by intelligent people anticipating change and more like ad-hoc reuse of things some people were already familiar with, despite the problems this may cause at scale. Things I consider to be concrete examples of this are all the major programming languages (Java, C#, Python, C++ that don’t even have algebraic data types that are around since the 70ies), docker containers (where the usual way of constructing them leads to linear dependencies which lead to poor composability), YAML as a configuration format (with its many pitfalls and high complexity), Microservices as almost a default architecture choice - the list goes on. This is not to say that I don’t consider these things useful in certain situations - it just strikes me as odd that the majority of our industry sees little problem with the status quo of defaulting to these options and that there are so few attempt at improving things.