So these people can talk

I like this because it had moments of uncomfortableness. I’m just the other side of this where I like FP more than I like OO, but I’ve come to the same conclusion. Hybrid OO and FP is the future, most languages are embracing it, but the communities are somehow still ideologically separated. Until that gap is closed there will be much pain for all of the work poured in to fill the gaps between these two approaches.

To nit pick, his consistent criticism of FP is that it exposes internal data structures which makes it brittle to maintain and extend, but I think that’s looking at FP like procedural programming, which it is similar to if you throw out immutability and the focus on tightly scoped pipeline steps instead of modeling layers. The data as an interface is entirely more flexible than an object interface and can provide verifiable guarantees and versioning, just look at Clojure spec! I don’t understand this ‘object in the large’ obsession as anything less than system level thinking. Yes, you can draw a box around these data structures and consider their interface as a static part of the program. But calling them ‘classical’ objects and calling back to Alan Kay’s definition thinly hides the fact that ‘modern’ objects are dead, but long live OO!

Really enjoying this more than I expected. It’s a fun mash-up of Demolition Man, Dollhouse, and the Expanse.

Everyone talks about simple, dumb, easy to understand, short, could be learned by a junior, code. But the examples of such are so sparse as to be self-evident that they only could illustrate one side of the story.

I know what motivates these posts, and most mention as a side effect and not the primary cause of needlessly complex code. It’s learning a new programming feature. When you first learn something you see it everywhere. Objects! Objects everywhere for OO! Function composition! Functions everywhere for pure FP! Events! Events everywhere for FRP or ES! I did this not long ago, and it took quite a few features for me to cool off on each successive one.

I think doing this is a necessary step in learning the limits of the technology. The features’ tradeoffs aren’t taught this way in school (as least not in my classes), so it’s only natural to find that you’ve pushed it too far and then pull back. The problem is then that the code written in the push too far range tends to stick around and motivates someone who’s long past that stage to find this code and exclaim! “This code abuses some feature to make this code too complicated! Write dumb code!”

What this really does is discourage people who haven’t used this feature before from learning new features and to discourage others from using features they haven’t had the time to learn and test the limits.

I think if more full-time engineers thought of themselves as full time consultants trying to deliver value with technical skill it would really change how businesses organize and reward engineering effort.

In some places it’s a race for the bottom as the engineering skill is so low as to be fungible, which causes further downward growth and eventually a cost spiral to just manage the sprawl of small amounts of value added by each additional contributor.

I’ll love these lists because they are a fun mental checklist of things that I can pat myself on the back about or say “oh ya I need to get better at that”. But they are really missing the next step as to why the negative of any of these are done and explaining how that came to be and what specifically can be done to address it.

Everyone is in a different situation and each of these points are context sensitive, so it’s hard to know if you’re doing all the low impact points and missing the ones that completely change your world view. By having such a long list I think it lulls many people into thinking they are ‘good enough’ and not assuming that they still have far to go.

This has been an open tab that I haven’t quite finished for months, but I finally got around to it. Most business talk is so high level that could pass for poetry, but with every new piece I read I start to put more of the nuances together. The big picture and the takeaways are blindingly obvious as you read them, but I didn’t appreciate the level of organizational effort required to make something so general until I started to try to describe strategy myself!

I used to ascribe some meaning to all of the CS and engineering knowledge I accumulated, but now when I explain these concepts I don’t shy away from calling them arbitrary incantations.

To understand why modern technology works you have to learn decades worth of accumulated knowledge. The core principles that enable computer technology to exist are as far away from applied engineering practice as the evolution of philosophy to physics.

While the content was cool, all of this stuff still exists or is better presented on Wikipedia. I really hated the left justified text with the textured background picture.

Good things come to those who wait I guess?

I was always planning on buying SC2 when all 3 campaigns came out, but I fell so behind after the initial release I never even knew when the last one came out. I said I’d buy it when they released a battle pack for all 3 at once for a discount, which never happened.

Now there’s these new co-op campaigns and moba style stuff, worth checking out. I restarted GW2 to find that it also has a free to play part, so I guess everything is going that direction.