Programming In F# Like A Stupid Person

Programming should be fun. All you need is a good set of values, some skill, and the right attitude. F# is the most fun I’ve had in a programming language in years. This essay series is about that: having fun. Most books and essays are about writing awesome code. There’s not a lot of material about writing code aweseomely. The code you’ll find here has bugs! Just like your code. Can you find them? If you’re looking for the final version of the code, you can find it in the project’s GitHub page. You can find the story of how all of this started on the series index page.

I program in F# like a stupid person, and I’m okay with that.

Ignorant people don’t know something. There’s no shame in being ignorant. Stupid people don’t want to know. Or they know and purposely ignore what they know. Nobody wants to be stupid.

I do. I have my own way of coding in F# that is not the accepted way, and I’m okay with that.

When people describe all the problems they have with microservices, I ask them: are you defaulting to text streams? Is your code more than 100LOC? Is your executable the same as a pure functional method?

Most of the time the answer is “no”, so I know they’re not doing true microservices. They’re probably using some kind of library hooked into a message queue or relational database. They’ve bought a buzzword, not a concept.

Vasily Kirichenko was kind enough to factor out my options problem. I got a tweet: “This is what all idiomatic F# looks like”

Make it look like this?

That’s wonderful, and it looks gorgeous, but I’m much more interested in workflow than I am beauty. Would my workflow have evolved towards this? Probably not, as I was demonstrating using types across projects to handle dataflow. But it might have. Beats me. I’m not going to get worked up about whether my code looks idiomatic or not or way or another. (I love his code, though. Nice!)

I am able to look at it and reason about it. Sweet.

Why would I evolve towards strong-typing around the incoming data? Am I adding complexity that’s not warranted? Why? To me? That’s a cool question to ask.

But as far as looking at a sample piece of code, even if it were in a different style the question would still remain: could I look at it and reason about it? Same question would be true in C++, or Haskell. That’s my only criteria for beauty. How am I able to engage with it?

I have big variable names. I use temporary variables in my code. Why? Because I am forgetful. Big names help me remember, reason about code when I’m coming in cold. Sometimes they go away. Sometimes not. I don’t worry about it one way or the other.

Please understand, I’m not saying anybody else is wrong. There are a damned ton of better programmers in F# than I am. That’s neat. I love the fact that I have things to learn from them.

I read about various F# concepts. I get out my IDE and play around with them. I learn new things. I don’t always use them, but I learn. It is enjoyable.

I read books like the excellent “Domain Modeling Made Functional” by Scott Wlaschin, a book I consider to be one of the most important programming books in the last few years, and play around with the ideas in my code. Looks like the Model-Driven Development guys are back in action! Woot! Fun times ahead, especially for coders in F#.

I have fun. I play. I learn. I enjoy myself.

I was talking to a friend about Domain Modeling, event storming, and the rest of it a couple of weeks ago. He told me he loved the idea and it was the only way he wanted to code — but how to prevent the Average Joe programmer he worked with from screwing things up?

This did not sound like fun, playing, learning, or enjoying yourself.

I hate to say it, but as a programmer who’s coded in a dozen different languages, in all kinds of situations, programming actually bores the hell out of me. “So much of it is wiring things up” one non-coder observed, and they were right. For whatever reason, the tech community seems insistent on developing coding situations where there’s a lot of grinding. I’ve seen people build and deploy thousands of lines of code to get something 3 lines of code can do. And that’s not unusual. That’s actually the norm. Hell, I might have been doing it in my example code showing off options. Or not. I’m not sure — but I want to know.

What does interest me is the people part of that. Why do we create such overblown systems? Why are some things more popular than others? What new concepts are entering the community that might get traction over the coming years?

When I saw the first cross-compiler, F# to Javascript, I knew we were on-board for quite a ride with this language!

When I code in F#, I don’t put on my mathematics hat. I don’t put on my architects hat, and I’m not building a giant model railroad. I am not looking for some aesthetic of perfection, clean, or nice.

I put on my explorer’s hat. My party hat. We’re going to have a blast, guys! Look at all of what we can do! Let’s go learn stuff!

When I get out F# and start coding, it’s a happy time. An adventure awaits! I code in F# because coding in F# makes me a better and happier programmer.

I program in F# like a stupid person, and I’m okay with that.


Follow the author on Twitter

July 19, 2018

2 responses to Programming In F# Like A Stupid Person

  1. All good, just remember the reader of the code. That could be your future self, or somebody else [such as a reader of a blog that sees your code].

    • admin said:

      It’s a good point.

      One of the things I’m doing on-purpose is not cleaning anything up as I go along. Instead, I’m just typing a few lines in, then blogging.

      That makes it messy. Frankly it makes me look like a moron. But I’m okay with that. I’ve gotten used to it after all these years (grin).

      So there is some purposeful hard-to-read stuff in the code. I’ll try to do better in future essays — maybe find a better balance. I don’t need to bore folks with every refactor. It’s probably more important to explain why I put things in one place or the other.

Leave a Reply

Your email address will not be published. Required fields are marked *