One email per week, 5 links.
Do you want to keep up to date with the latest trends of software development and technology?
But keeping up to date with all the blogs, podcasts, and articles is time consuming so why not let someone else curate the content for you?
With our weekly newsletter you will get 5 top stories hand-picked into your inbox every Monday with topic ranging from programming, software development practices, architecture, databases, and many others.
Escape the distractions of social media and own your focus. Check out the latest issue and subscribe!
this week's favorite
My point is not that type systems are bad or that the original essay is flawed. On the contrary, I thank the flying spaghetti monster almost every day for the type system in my day job (and that is only Java’s tepid concoction), and I think the “parse, don’t validate” essay is excellent. But the last two decades have seen such advances in type systems and the adoption of typeful programming patterns that we are in danger of thinking that type systems are the only way of achieving correctness in software construction.
Many years ago, I did a brief stint at Google. A lot has changed since then, but even that brief exposure to Google's internal developer tools left a lasting impression on me. In many ways, the dev tools inside Google are the most advanced in the world.
I have spent almost the entire last decade in a fairly specialized product company, building high performance I/O systems. I had the opportunity to see storage technology evolve rapidly and decisively. Talking about storage and its developments felt like preaching to the choir.
Continuing on in our series on exotic programming ideas, we’re going to explore the topic of effects. Weak forms of effect tagging are found in many mainstream programming languages, however the use of programming with whole effect systems that define syntax for defining and marking regions of effects in the surface syntax is still an open area in language design.
A perfect implementation of the wrong specification is worthless. By the same principle a beautifully crafted library with no documentation is also damn near worthless. If your software solves the wrong problem or nobody can figure out how to use it, there’s something very bad going on.