Ep 110: Contextify!

Functional Design in Clojure

Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones에서 제공하는 콘텐츠입니다. 에피소드, 그래픽, 팟캐스트 설명을 포함한 모든 팟캐스트 콘텐츠는 Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones 또는 해당 팟캐스트 플랫폼 파트너가 직접 업로드하고 제공합니다. 누군가가 귀하의 허락 없이 귀하의 저작물을 사용하고 있다고 생각되는 경우 여기에 설명된 절차를 따르실 수 있습니다 https://ko.player.fm/legal.

2y ago 23:22

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to [email protected], or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "gathering debugging context". Our downloads fail at random, but our dead program won't give us any answers.

We just need to fill out our support ticket and say, "Hey! Fix your service!" It couldn't possibly be our code!
So there is an error happening, but what happened just before that error?
It is dead. There's no way to ask it any questions. It will not give us any answers.
The only way to know what the program was doing, is to know what the program was doing. If you're trying to figure out what the program was doing by reverse engineeringing it, you're going to get it wrong.
I love hiding side effects with macros! That's one of my favorite things to do in Clojure! It makes me feel like I'm using Scala again!
We don't want the I/O function to do any thinking of any kind. It's a grunt. We fully specify the bits it needs to know. It's 100% a boring outcome of what we passed into it.
Those I/O functions end up being ruthlessly simple. They're often just one line!
We remove the thinking, so we remove the information. It's not because we don't like pure functions. We put them in a place where we can have all the information in one place.
We're getting to the point where our let block is getting really long really—maybe too long. We're really letting ourself go!

72 subscribers

published 2y ago

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to [email protected], or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "gathering debugging context". Our downloads fail at random, but our dead program won't give us any answers.

We just need to fill out our support ticket and say, "Hey! Fix your service!" It couldn't possibly be our code!
So there is an error happening, but what happened just before that error?
It is dead. There's no way to ask it any questions. It will not give us any answers.
The only way to know what the program was doing, is to know what the program was doing. If you're trying to figure out what the program was doing by reverse engineeringing it, you're going to get it wrong.
I love hiding side effects with macros! That's one of my favorite things to do in Clojure! It makes me feel like I'm using Scala again!
We don't want the I/O function to do any thinking of any kind. It's a grunt. We fully specify the bits it needs to know. It's 100% a boring outcome of what we passed into it.
Those I/O functions end up being ruthlessly simple. They're often just one line!
We remove the thinking, so we remove the information. It's not because we don't like pure functions. We put them in a place where we can have all the information in one place.
We're getting to the point where our let block is getting really long really—maybe too long. We're really letting ourself go!

플레이어 FM은 웹에서 고품질 팟캐스트를 검색하여 지금 바로 즐길 수 있도록 합니다. 최고의 팟캐스트 앱이며 Android, iPhone 및 웹에서도 작동합니다. 장치 간 구독 동기화를 위해 가입하세요.