Ping 17/06/2022 .01


“Code bloat has become astronomical”

https://www.positech.co.uk/cliffsblog/2022/06/05/code-bloat-has-become-astronomical/

극공감. 그렇다고 의존성 포함하면 몇 기가나 되는 것들이, 하는 일을 보면 안습. …그렇다고 그런 방법들만을 고르는 안목이 엄청나게 힙한것도, 스스로에게 이익이 되는것도 아니고.

데스크탑에 작은 서브모니터 연결해놓은 rpi3b+이 rpi4보다 빠르지는 않을지 몰라도, micro-sd 버벅거림이랑 발열 때문에 버벅거리는건 훨씬 적다.

“rpi4은 빠르니까!“이라면서 나름대로 데탑/랩탑에서 쓰는 설정 그대로, openbox+lxpanel 정도 올려서 쓰고 있고, rpi3b+은 icewm 세팅하고 추가로 뭔가를 더 해놓지 않은 탓이 있을까 싶기도 하지만. …어차피 둘 다 엄청 가벼울거 같은데도.

Ping 15/06/2022 .01


비 내리는 화요일. ☔


jinja2 template include + cache? + file-time

재밌는걸 찾았다.

jinja2을 사용하면서, 하위 include으로 내려갈수록, file을 생성해줘도, 그냥 touch을 해줘서 파일시간을 갱신해줘야 template cache을 무시하는거 같아.

그래서,

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
// gulpfile.js:

const buildTask = series(cleanTask, esbuildTask, injectTask, touchInjectedTask);

function watchTask() {
  watch("./js/**/*.js", buildTask);
}

exports.watch = watchTask;
exports.build = buildTask;
exports.clean = cleanTask;

…대략 잘 동작하고, webpack보다 엄청나게 빠르다 ㅎㅎ.

"모두를 위한 algebraic effects!" ...정말루?


뭐 대충 다음과 같은 글들:

https://www.eff-lang.org/handlers-tutorial.pdf

https://www.microsoft.com/en-us/research/wp-content/uploads/2016/08/algeff-tr-2016-v2.pdf

…그리고 몇 개의 구현체, 포스팅들: (아직은 별루인거 같은데)

https://hackage.haskell.org/package/fused-effects

https://github.com/dry-rb/dry-effects

https://github.com/digital-fabric/affect

https://github.com/macabeus/js-proposal-algebraic-effects

https://github.com/nythrox/effects.js

https://www.janestreet.com/tech-talks/effective-programming/

https://github.com/ocaml-multicore/effects-examples

https://overreacted.io/algebraic-effects-for-the-rest-of-us/

…음… 분명히 한국말으로 번역도 해놓았고, 심지어 js버젼으로 설명/예시도 있는데 나는 전혀 모르겠다 싶었음.

오히려 dry-rb, affect이 더 명확하기는 한거 같아.

가장 실용적으로 접근한 예는, ocaml-multicore에서 활용한 것들 같아 보인다.

분명히 장점을 볼 수 있을거 같은 개념 같다.

왜냐하면,

  1. 지금의 monad을 이용한 효과와 사용처의 분리 방식을 생각해보면,
  2. 하나의 monad context에서는, 한가지 타입의 monad만을 표현가능.
    1. 그래서 여러개의 monad context을 위해 monad transformer 같은것들으로 stacking하여 사용.
    2. (…그때 그때 Haskell do-notation등에 따라 분리해서 표현)
    3. 좋은점이라면 좋은점일수도 있겠지만.
  3. 그런데, aeffects을 이용한다면,
    1. 굳이 그렇게 복잡하게 나누지 않아도 괜찮고,
    2. monad처럼 사용처에서 그 효과의 내용을 분리하기도 좋아 보여.

당연히 그렇기 때문에, 원래의 모나드에서 같는 장점을 그대로 잃지 않으면서, 더 평범하게 적어나가기 좋을거 같다. (…일반적인 imperative programming language에서 I/O/async/await, Maybe등이 동시에 나오거나, …처럼)