Then I needed to ingest RSS feeds. So I found a library that handled that for me. Except that library uses another type for URLs. Uh oh. What should I do? I could change my URL type to be a wrapper type around both types, or write code to convert between the types. I chose to convert. Now I'm writing code to shuffle between the types where this RSS parsing module is used.

Then I needed to make HTTP requests. So I pulled in a library to handle HTTP requests. Of course, that library uses another type for URLs (from another library it depends on). Great. Now I have 3 types for a URL.

Then I needed to parse XML... and you know where this story is going.

So now my codebase has many different URL types.

The type-a-holics will say: "This is actually good! Each implementation of the URL type might have slightly different constraints, and the type system makes this all explicit. You should be grateful you spend half of your development time fiddling with types. The fact that `unpack . decodeUtf8` is littered around your codebase isn't code smell, it's the splendor of a type system that's saving you from yourself. You should learn to love the fact that you have to deal with String, Text, and ByteString and 4 URL types to fetch and parse an RSS feed. Otherwise your software would be full of bugs! Silly developer."

One day I finally woke up from this type nonsense. There's integers, rationals, strings, lists, and maps. The end.

A functional language with a simple set of structural types would be the sweet spot for me. Clojure is probably the closest to this.

... What people are suggesting is to take money from some productive enterprises and put it towards other productive enterprises such as education, medicine, public infrastructure, etc. Enterprises which have more benefits beyond simply increasing the bank account of entrepreneurs and fund managers.

1 = I’ve done this before

2 = Someone else in the organization has done this before

3 = Someone outside the organization has done this before.

4 = Nobody has done this before

1 and 2 can be quickly estimated by referring to past work.

3 and 4 must be broken down into small tasks that are estimated.

And when breaking things down into tasks to estimate, keep in mind coding is only around 1/4 of the work to produce software. There’s tests, documentation, revisions, planning, and communication.

It turns out we can probably solve this by building planetary chimneys 5km tall that move heat to the outer atmosphere.