Console 34
Koans, Waves, and Pi
There is a new Console Discord server! Come join me, and previous Console interviewees, in the Console Discord. The first 10 people to use this invite code will get free lifetime access to the server.
pi-webcam
pi-webcam is automation to configure a Raspberry Pi as a USB OTG webcam.
language: Ansible, stars: 769, watchers: 28, forks: 35, issues: 12
last commit: December 17, 2020, first commit: September 23, 2020
ihp
IHP is a modern “batteries-included” Web Framework, built on top of Haskell and Nix.
language: Haskell, stars: 1625, watchers: 41, forks: 83, issues: 81
last commit: December 29, 2020, first commit: December 03, 2017
https://twitter.com/_marcscholten
lisp-koans
list-koans is a language learning exercise in the same vein as the ruby koans, python koans and others, open-sourced by Google.
language: Common Lisp, stars: 2756, watchers: 140, forks: 516, issues: 2
last commit: December 21, 2020, first commit: May 24, 2013
https://functional.cafe/@phoe/ & https://twitter.com/JonathanGodbou1
wave
H2O Wave is a software stack for building beautiful, low-latency, realtime, browser-based applications and dashboards entirely in Python without using HTML, Javascript, or CSS.
language: Python, stars: 2206, watchers: 132, forks: 83, issues: 155
last commit: January 01, 2021, first commit: May 16, 2020
https://twitter.com/CrunchingData
PineTime
The PineTime is a free and open source smartwatch capable of running custom-built open operating systems. Some of the notable features include a heart rate monitor, a week-long battery as well as a capacitive touch IPS display that is legible in direct sunlight. It is a fully community driven side-project, which means that it will ultimately be up to the developers and end-users to determine when they deem the PineTime ready to ship.
language: C, stars: 274, watchers: 38, forks: 138, issues: 43
last commit: January 02, 2021, first commit: November 17, 2019
Help Wanted
If you’re interested in posting a help wanted ad for your project, send an email to console.substack@gmail.com
An Interview With Marc Scholten of IHP
What is your background?
I started programming in 2010. In the first years of doing software development I was mainly working in the PHP space. I’ve been part of the Propel ORM core team back then. After a couple of years I moved more into the Rails ecosystem.
Rails showed me that many of the trends in the PHP ecosystem, like overuse of design patterns, services containers, making everything more flexible than it needs to be, favouring data mapper over active record, doesn’t really help you build a good scalable software architecture. In the end no method or class is doing anything specific, it’s all just needless abstraction in the name of single responsibility principle. Rails showed me a better way.
In 2015 I’ve started working with React and building more complex frontends. Mainly together with Rails in the backend. Around that time I also started using Nix and Haskell.
Four years ago, in 2016, I founded digitally induced. Our engineers assist our customers moving into the digital space with digital product development and comprehensive technical expertise.
In 2017 we already started working on our own custom Haskell framework. Initially, it was just to get live reloading (which was the hot new thing in the React world back then) working in Haskell. We already wanted to open source it in 2018, but then I got quite busy with building the company :). At the beginning of this year we decided it was time to get it out, then in June we finally released IHP onto the world.
The di-team has grown to consist of 6 people in between. And we now set out to use IHP To Drive The Adoption Of Haskell In The Software World.
What made you transition into Haskell from Javascript?
Haskell initially got me interested because it was a whole different paradigm. I didn’t know anything about functional programming back then, so this naturally got me curious to learn.
What's an opinion you have that most people don't agree with?
Programming languages vary in power. There’s a great post by pg about this.
What’s your most controversial programming opinion?
Docker is the wrong solution to the right problem. The value is in software distribution, and there are better tools for that (even vagrant was better).
What would you say is wrong with Docker, and what is a better approach to these problems?
Docker has two problems:
- It's slow because of large images and an inefficient approach to building images.
- In development, it usually runs inside a VM when using macOS. This has bad effects on the developer experience because now you're basically dealing with two systems.
If you have lot's of different dependencies nix is always a good choice.
Otherwise, follow the most simple approach:
If you have a stack, like a typical PHP stack, you'll get a lot of the same benefits of docker by writing a small script that makes sure that the right version of your PHP tools are installed via e.g. brew. Basically, moving the instructions out of your Dockerfile into a shell script that calls the different package managers you're using. And then starts the, e.g., mysql/postgres server and the PHP server. Also add direnv to the mix.
The goal should be to have fast feedback loops in your development processes. This is very hard to archive with docker.
What is one app on your phone that you can’t live without that you think others should know about?
If you could dictate that everyone in the world should read one book, what would it be?
I’d not dictate any book to avoid violating individual liberty. But here’s a couple books I found insightful:
The Design of Everyday Things (Software is to be used by humans, so good design is an important facet of good software products)
The Innovator's Dilemma
Blue Ocean Strategy
Crossing the Chasm
If I gave you $10 million to invest in one thing right now, where would you put it?
digitally induced
Anything in particular you’d use the money for at digitally induced?
New features already have diminishing returns for IHP. The biggest leverage is in making the documentation better and helping more people to learn about IHP.
We also need dedicated teams working on IHP Cloud and IHP Casts at some point. This could then be accelerated by a lot with the funding.
What resources do you use to stay up to date on software engineering?
I mostly read hacker news.
How do you separate good project ideas from bad ones?
A good project solves a real valuable problem in a better way for at least one real person. There also needs to be a clear way for distribution, otherwise there’s likely no adoption of the solution.
Why was IHP started?
IHP was initially just an experiment to get live reloading into Haskell apps. Then it turned out that the result was pretty fun to use to build apps with. We started using it internally for our own projects and smaller client projects.
Are there any overarching goals of IHP that drive design or implementation?
We want to drive the adoption of Haskell in the software world. There’s a big trend in the software world of adopting more functional programming techniques (see e.g. recent Java releases). We’re also seeing growing usage of type systems again (see recent PHP releases, Typescript, Flow by FB). Haskell sits at the end of this trendline and I think it’s time for Haskell to gain more widespread adoption.
For that we designed IHP for non-Haskellers to use. All other Haskell frameworks are usually designed for people who are experts in Haskell. IHP is for the developers who like FP-techniques and also want type-safety, but don’t know about Haskell yet.
For those not in the Haskell ecosystem, what are some of these existing web frameworks?
Take a look at servant. It uses a lot of advanced Haskell type system magic to build very stable APIs. This is pretty good when you're already familiar with type families and are able to decipher Haskell's complex type error messages when things go wrong. This is not the right tool for starting out.
Take a look at e.g. the "Basics" section of the Yesod framework. Yesod is Haskell’s biggest web framework and many of the IHP components we're using (e.g. WAI, Warp, a lot of middlewares) have been developed by the Yesod team. Compare this to our “Getting Started”. You will see that Yesod doesn't really explain how to do real world CRUD work (what a lot of web development is about). It tells you all the technical details, but after reading the whole page you still cannot make an HTML form be saved to the database. If you're a Haskell expert, the technical details will be enough for you to get started. If you're just starting out, you will feel like you're not going anywhere and rethink your choice of picking Haskell.
What trade-offs have been made in IHP as a consequence of the above goals?
We sometimes drop type-safety at certain points to simplify the framework API. E.g. in early versions of IHP we had different types for un-persisted records and for persisted records. We had a `data NewProject` that didn’t have an id field, because the id is only set after it’s been inserted into the database.
While this catches a few edge case bugs, it really confuses developers. So we removed it. Most apps will never have any bugs because of this problem, but most apps we built have been affected by more complex type signatures because of this.
What is the most challenging problem that’s been solved in IHP, so far?
Early on we had a complicated issue with the IHP import structure. In Haskell, you cannot have import cycles, so when module A depends on module B, module B cannot depend on module A or on any module that depends on module A.
Here’s the concrete problem: Let’s say we have a project that consists of Posts and Comments.
Inside the Comments-Controller to render the new comment form we need to import the New Comment View from Web.View.Comments.New.
That View wants to display a link to the lists of all Posts. For generating the path to that route it needs to be aware of the routing configuration. So we import Web.Routes.
The Web.Routes module needs to know about the controllers so it imports all the Controllers. Including Web.Controller.Comments.
So we go this:
Web.Controller.Comments -> Web.View.Comments.New -> Web.Routes -> Web.Controller.Comments
We have hit a cycle in our imports.
It took us quite a while to rethink this to avoid this from happening. The solution is to make routing definitions independent from the action implementation, so that the Web.Routes module does not need to import the controllers.
We added a new Web.FrontController which imports all the controllers and the Web.Routes and then only when a route is added to the router via parseRoute, we expect the action implementation to be available.
Solving this problem took multiple iterations and weeks of thinking about possible solutions. The module structure of IHP is really under-appreciated because now it just works.
What is your typical approach to debugging issues filed in the IHP repo?
I start by creating a new IHP project where I try to reproduce the issue.
What is the main source of revenue for IHP?
IHP is already monetized with services like IHP Cloud and IHP Casts. Both are already generating revenue. Compared to the rest of digitally induced it’s still tiny, but we’re getting there :-)
The services business of digitally induced is the main part of what we’re doing. We help other companies build digital products.
I’m very excited about growing this next year. With IHP we can build software much faster in higher quality than other companies. Additionally, we have access to a very unique talent pool of developers who want to work with IHP and Haskell in production. This is great for our customers, who can have a shorter time to market, and great for our engineers, who can work with the most exciting technology.
If you plan to continue developing IHP, where do you see the project heading next?
We have exciting plans for IHP next year :)
At the beginning of the year we plan to do the first stable V1 release.
IHP will soon be the biggest web framework in the Haskell space (around Q1 - Q2). This will be another major milestone. The IHP Merch Store and a new IHP Hub is also in the pipeline.
I’m also optimistic that we might be able to do a IHP conference at the end of 2021, after the pandemic is over.
So there’s a lot of things to be excited about :-)
Like what you saw here? Why not share it?
Or, better yet, share Console!
Also, don’t forget to subscribe to get a list of new open-source projects curated by an Amazon software engineer directly in your email every week.