Chris Allen

What languages have you worked with before, with static types?

If it's something like Java, C, C++, etc, then I can see your point, but if you pick any of the languages with type inference (like Elm, Haskell, PureScript, OCaml, F#, etc), then you rarely actually have to write types.

Working with the type system is a different way of working. It's more beneficial to see the compiler as a helping friend, instead of an adversary that is just there to complain.

Some interesting reads might be:

- http://elm-lang.org/blog/compilers-as-assistants

- https://matthew.brecknell.net/post/hole-driven-haskell/

- http://bitemyapp.com/posts/2017-09-23-please-stop-using-typed-holes.html

Personally, I honestly hate every time I don't have a time system to rely on. I don't make any false pretenses that I have the whole program in my head 100% of the time. I don't want to have to think about things that a computer can solve for me, hence I like my compiler to do as much work as possible.

As for unit testing, a type system is never supposed to remove the need for unit testing, and if you see anyone promote a language because of this, they are probably (hopefully) over simplifying. What it does do though, is significantly cut down the need for certain types of tests, since you can model so much more logic via types (ADTs, Union types, etc), and get it checked by the compiler.

As an aside: I simply do not believe you've never run into a type error, unless you've only written projects…

I went through most of the Hutton book but I already had an elementary background in the language. Then some of the recommended CIS194 course. (3-6 months spent studying total.) Finally I decided upon a project that was right in one of Haskell's strong points: parsing/compilation [0]. Everything was a Google search: how to start a Haskell project with Nix? How parse command-line arguments? How to write a parser for a calculator? What the hell does this compiler error mean??!! Find the answer and get straight back to it. I would still consider myself intermediate, and not proficient, at the language.

While it is one person's opinion (albeit well explained) I strongly appreciated Chris Allen's efforts to evaluate existing learning material (prior to co-writing his book) as well as recommending a learning path [2]. Ultimately there is multitudinous material to study. For the textbook-like route, choose something that seems sensible and commit, leaving only when it appears to no longer be fulfilling the purpose. Juggling too many artifacts is like interrupting programmers.

I don't use VS Code but again, my elementary knowledge of the language, plus sufficiency with GHCi, meant I could stay within my Vim comfort zone. If anyone has a good single resource for configuring Vim for Haskell I'd love to see it?

[0] State of the Haskell ecosystem https://github.com/Gabriel439/post-rfc/blob/master/sotu.md
[1] Functional Education https://bitemyapp.com/blog/functional-education/…

I identify with, and am seeking for myself, a lot of things described here.

That said, the author is speaking from an intensely privileged point of view. Referring to selling one's time as a programmer as 'whoring' caused me to cringe.

I have strong aversion to growth for growth's sake now that I've lived and worked in Silicon Valley and the startups that go with it (I was CTO at a nutrition startup).

Things I've done recently:

1. Quit my job and went back to being an independent consultant. Looking to start a product company in the gap time between contracts.

2. Exercising more, in my case, 6 times a week minimum as well.

The real question is whether or not I'll be able to make something that bears revenue fruit or not. I've had small bits of success here and there before but nothing substantial or lasting. Current side project is just me scratching an itch, no real revenue potential.

I've been reading a lot in an attempt to learn as much as I can and prepare myself to be able to make something profitable. Mostly marketing and sales books, about to do another read-through of Patio11's stuff again.

Can anyone tell me what the aspiring micro-ISV/self-employed entrepreneur really needs to know in order to get ramen profitable? I know I need to build and experiment quickly - what else?

Edit:

My book log: http://bitemyapp.com/post/book-log-1/

I agree with orangethirty's "start selling". I just need to hoof it and do it. Not about to stop reading though :)

For me it's mostly about codebase scaling, refactoring and maintainability. Clojure is liberating and exciting when you're writing a tiny little project, but it's a whole other experience when you need to refactor dozens of files because you changed the format of the data being passed around, or you're changing an internal API that's called from a hundred different places.

You better have perfect code coverage, or you'll have no clue why and where something broke (the sink/source problem) or perhaps you won't even find out for a while because that scenario wasn't sufficiently tested and it slips into production. Having a compiler nag you about type inconsistencies is incredibly helpful in these scenarios.

The other big one is working with large blobs of data. Our product has a large analytics component to it, and massaging giant, deeply nested maps representing a certain compendium of statistics is really tough without the compiler spotting you. None of this is an issue when you have to satisfy a certain type, the compiler will basically give you a checklist of things to fix when you change something.

With Haskell you're getting all of the benefits of Clojure (expressiveness, leverage etc), plus the really useful addition of types and enforced purity on top.

Here's another clojurian's experience with switching to Haskell: http://bitemyapp.com/posts/2014-04-29-meditations-on-learning-haskell.html

Oh poop. I'm the ezl from the github repo where that source lives. Was hoping we'd have more time to fix it before being embarassed.

HNOH was intended to be a quick weekend project (famous last words). We didn't quite make it in the weekend, so we just let it hang out in his half complete state.

rguzman, smalter, and I have been meaning to put some love into it, but we've been slammed working on what we think will be our real startup, http://www.leasely.com, so we've not really carved out the time.

Its broken and buggy, the calendar features don't work right, and there are issues with creating/canceling recurring office hours. We'd LOVE for this to be used in real life, but its not in a state we can really say we're super proud of yet. We want anyone who wants to be involved to get involved, so if you have hours to donate, please get in touch.

The heavy lifting was done by HN users: rguzman, deuterium, C Allen from NYC (github.com/bitemyapp/, http://bitemyapp.com), and a few others.

So we f-ed up, there are still bugs, and its been on the backburner since we're trying to work on leasely but now we've been embarassed into fixing the bugs so we will.

[edit: linked to C Allen's github and personal page]

If only it could do this…

f :: YourTestInput -> CorrectAndPerformantAdventOfCodeSolution
f = _

---

Seriously though, even after writing Haskell primarily for years, I've never done hole-driven development and I'm still not sure what I'm missing. I tried once — granted, that was a long time ago — but I didn't get it. This post[0] suggests I'm not alone in thinking this.

I'm glad Wingman exists and I think branding it nicely like this is the right thing to do, but I think I need to see more concrete examples to really see the magic. Probably something like Gary Bernhardt's Destroy All Software screencast series. It's one thing for someone to tell you that vim is fast, but it's another thing entirely watching the tool come to life in the hands of an expert. I imagine it's a similar thing for Wingman — I still have this mental block where I'm picturing the tool conjuring up an undefined for each hole, which is exactly what the documentation suggests the tool doesn't do. I would love to see someone use Wingman to quickly hammer out an Advent of Code puzzle, or even something more real-world like an Esqueleto query (but is that even possible?)

[0]: https://bitemyapp.com/blog/please-stop-using-typed-holes/