What is Hackers' Pub?

Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.

0
0
0
0
0
0
0
0
0

XiNiHa shared the below article:

Monads: Beyond Simple Analogies—Reflections on Functional Programming Paradigms

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool.

The Elegant Power of Monads in Haskell

It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem.

The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated:

  • You can write code once that works across many contexts (Maybe, [], IO, State, etc.)
  • Generic functions like sequence, mapM, and others become available across all monadic types
  • The same patterns and mental models apply consistently across different computational contexts

For example, a simple conditional function like this works beautifully in any monadic context:

whenM :: Monad m => m Bool -> m () -> m ()
whenM condition action = do
  result <- condition
  if result then action else return ()

Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse.

OCaml's Different Approach

Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design:

Structural Differences

OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient:

(* OCaml monad implementation requires more boilerplate *)
module type MONAD = sig
  type 'a t
  val return : 'a -> 'a t
  val bind : 'a t -> ('a -> 'b t) -> 'b t
end

module OptionMonad : MONAD with type 'a t = 'a option = struct
  type 'a t = 'a option
  let return x = Some x
  let bind m f = match m with
    | None -> None
    | Some x -> f x
end

OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive:

-- Haskell's elegant do notation
userInfo = do
  name <- getLine
  age <- readLn
  return (name, age)

Compared to the more verbose OCaml equivalent:

let user_info =
  get_line >>= fun name ->
  read_ln >>= fun age ->
  return (name, age)

The readability difference becomes even more pronounced in more complex monadic operations.

Philosophical Differences

Beyond syntax, the languages differ in their fundamental approach to effects:

  • Haskell is purely functional, making monads essential for managing effects in a principled way
  • OCaml permits direct side effects, often making monadic abstractions optional

This allows OCaml programmers to write more direct code when appropriate:

(* Direct style in OCaml *)
let get_user_info () =
  print_string "Name: ";
  let name = read_line () in
  print_string "Age: ";
  let age = int_of_string (read_line ()) in
  (name, age)

OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring:

  • Direct use of option and result types
  • Module-level abstractions through functors
  • Continuation-passing style when needed

While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides.

Reflections on Language Design

These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system.

Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts.

OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount.

After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience.

What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

Read more →
0
0
0
0
0
0
Moreal @moreal@silicon.moe
Quiet public
Shared by bgl gwyng

gif2webp.com/

어느 디자인 포트폴리오 회사에서 GIF 지원을 중단하고 WebP 만을 사용하게 강제하면서, 주변 지인이 CLI로 변환하는 불편을 겪고 있었기 때문에 간단한 웹 앱을 만들었습니다. 이전에 동작은 만들었었는데 테마나 스타일링이나 조금 덧 붙여서 공개했습니다.

서버에 GIF 파일을 보내고 다시 받는 대신, 브라우저에서 변환하여 다운받을 수 있습니다.

github.com/moreal/gif2webp.com

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
ruru@:succubus: @ruru@mi.ruruke.moe
Public

カスタム絵文字100連ガチャ
​:R364:​​:R243:​​:blobcatcomfy_spacepirate:​​:stone_II:​​:enchanted_moulinet:​​:akh_morn:​​:R477:​​:ruin_mastery:​​:heavy_shot:​​:R179:​​:bloodbath:​​:Archer:​​:queen_overdrive:​​:ablobcatpnd_no_gohome:​​:veraero_III:​​:amplifier:​​:ladonsbite:​​:kawaii3:​​:R305:​​:blobzaurusufiremid:​​:R288:​​:toxikon_II:​​:peculiar_light:​​:aethercharge:​​:reprisal:​​:R347:​​:combust_II:​​:blobzaurusumooch:​​:kasaneteto_firebreath:​​:enhanced_radiant_aegis:​​:R151:​​:ablobcat_ofton_oishi:​​:lightning_shot:​​:salmon:​​:toad_oil:​​:R468:​​:tux:​​:R390:​​:savage_claw:​​:blobcatcomfy_rabbit_dance:​​:astral_flow:​​:R354:​​:heated_split_shot:​​:exuviation:​​:aspect_mastery_IV:​​:R102:​​:R161:​​:zoe:​​:blobcatpnd_meltedrelax:​​:improvised_finish:​​:full_thrust:​​:crowned_collider:​​:venomous_bite:​​:ablobcatpnd_muzumuzu:​​:primal_rend:​​:increased_action_damage:​​:ablobcatpnd_ikaku:​​:hot_shot_mastery:​​:R343:​​:R136:​​:R124:​​:straight_shot:​​:R359:​​:summon_ifrit_II:​​:riddle_of_fire:​​:enhanced_summon_bahamut:​​:R335:​​:blobcatxd:​​:R473:​​:raiton:​​:flamethrower:​​:ablobcatpnd_icecream:​​:ablobcatpnd_throwing:​​:tatupu_odekake:​​:ablobcatpnd_kidnap:​​:technical_finish:​​:rage_of_halone_mastery:​​:manaward:​​:coerthan_torment:​​:closed_position:​​:celestial_opposition:​​:blobzaurusufirebegin:​​:malefic_mastery_IV:​​:blobbounce:​​:cover:​​:R177:​​:huton:​​:R147:​​:level_5_petrify:​​:ruin_mastery_IV:​​:ablobcatpnd_okusuri_nometane:​​:ink_jet:​​:blobbounce:​​:R327:​​:Conjurer:​​:blobcatcomfy_spacepirate:​​:curing_waltz:​​:resolution:​​:enhanced_deployment_tactics:​​:frog_legs:​


https://mi.ruruke.moe/play/a3uxixd4k6h600cu

0
0
0
0
0
0
0
0
0
0
0
0
geeknews_bot @geeknews_bot@sns.lemondouble.com
Public

GN⁺: 당신에겐 Redis가 필요하지 않을 수도 있습니다
------------------------------
- Redis는 기술 업계에서 가장 긍정적인 평판을 얻고 있는 기술 중 하나임
- 매우 잘 설계된 뛰어난 기술이고 자체에 결함이 있는 것은 아니지만, 항상 필요하진 않을 수 있음
- 10+년동안 3곳의 회사에서 같은 패턴을 봄:
- 문제가 발생하고 Redis가 적합해 보였지만, 실제로는 상황을 개선하지 못했거…
------------------------------
https://news.hada.io/topic?id=19665&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
0
0
0
0
0
vruz @vruz@mstdn.social
Public

This is the ual way.

## ual 1.3 spec
- P1: github.com/ha1tch/ual/blob/mai
- P2: github.com/ha1tch/ual/blob/mai

## Error Stack Mechanism
- github.com/ha1tch/ual/blob/mai

## Typed Stacks
- P1: github.com/ha1tch/ual/blob/mai
- P2: github.com/ha1tch/ual/blob/mai

## Ownership Mechanism
- github.com/ha1tch/ual/blob/mai

## Defer Stack Mechanism
- github.com/ha1tch/ual/blob/mai

## Stack Perspectives
- github.com/ha1tch/ual/blob/mai

## Concurrency Model
- P1: github.com/ha1tch/ual/blob/mai
- P2: github.com/ha1tch/ual/blob/mai

0
0
0
0
0
0
0
0
0
0
0
0
geeknews_bot @geeknews_bot@sns.lemondouble.com
Public
Shared by 洪 民憙 (Hong Minhee) :nonbinary:

하스켈과 OCaml의 모나드 접근 방식 비교
------------------------------
## Haskell의 모나드: 우아한 추상화
- 모나드는 단순히 Promise와 유사한 개념이 아닌 강력한 추상화 도구
- Monad 타입클래스를 통해 다양한 컨텍스트(Maybe, [], IO, State)에서 코드 재사용
- 제네릭 함수(예: sequence, mapM)가 모든 모나드에서 활용 가능
- do 표기법으로 가독성 높은…
------------------------------
https://news.hada.io/topic?id=19664&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
0
0
geeknews_bot @geeknews_bot@sns.lemondouble.com
Public

하스켈과 OCaml의 모나드 접근 방식 비교
------------------------------
## Haskell의 모나드: 우아한 추상화
- 모나드는 단순히 Promise와 유사한 개념이 아닌 강력한 추상화 도구
- Monad 타입클래스를 통해 다양한 컨텍스트(Maybe, [], IO, State)에서 코드 재사용
- 제네릭 함수(예: sequence, mapM)가 모든 모나드에서 활용 가능
- do 표기법으로 가독성 높은…
------------------------------
https://news.hada.io/topic?id=19664&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
0
0
0
0
0

洪 民憙 (Hong Minhee) shared the below article:

Monads: Beyond Simple Analogies—Reflections on Functional Programming Paradigms

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

While exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool.

The Elegant Power of Monads in Haskell

It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem.

The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated:

  • You can write code once that works across many contexts (Maybe, [], IO, State, etc.)
  • Generic functions like sequence, mapM, and others become available across all monadic types
  • The same patterns and mental models apply consistently across different computational contexts

For example, a simple conditional function like this works beautifully in any monadic context:

whenM :: Monad m => m Bool -> m () -> m ()
whenM condition action = do
  result <- condition
  if result then action else return ()

Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse.

OCaml's Different Approach

Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design:

Structural Differences

OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient:

(* OCaml monad implementation requires more boilerplate *)
module type MONAD = sig
  type 'a t
  val return : 'a -> 'a t
  val bind : 'a t -> ('a -> 'b t) -> 'b t
end

module OptionMonad : MONAD with type 'a t = 'a option = struct
  type 'a t = 'a option
  let return x = Some x
  let bind m f = match m with
    | None -> None
    | Some x -> f x
end

OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive:

-- Haskell's elegant do notation
userInfo = do
  name <- getLine
  age <- readLn
  return (name, age)

Compared to the more verbose OCaml equivalent:

let user_info =
  get_line >>= fun name ->
  read_ln >>= fun age ->
  return (name, age)

The readability difference becomes even more pronounced in more complex monadic operations.

Philosophical Differences

Beyond syntax, the languages differ in their fundamental approach to effects:

  • Haskell is purely functional, making monads essential for managing effects in a principled way
  • OCaml permits direct side effects, often making monadic abstractions optional

This allows OCaml programmers to write more direct code when appropriate:

(* Direct style in OCaml *)
let get_user_info () =
  print_string "Name: ";
  let name = read_line () in
  print_string "Age: ";
  let age = int_of_string (read_line ()) in
  (name, age)

OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring:

  • Direct use of option and result types
  • Module-level abstractions through functors
  • Continuation-passing style when needed

While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides.

Reflections on Language Design

These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system.

Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts.

OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount.

After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience.

What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?

Read more →
0
0
0
0
0
0
0
0
[랜선효도] 제주감귤🍊 @jejuorange.bsky.social@bsky.brid.gy
Public

3월 10일 임시 가격표입니다. 써니트는 최후의 최후 입고가 있을지도 모릅니다. 설국향은 조금 더 익기를 기다리는 중. 주문 : tinyurl.com/jejuorange7766 (구글폼) 문의 : open.kakao.com/o/snBLcewf (오픈카톡)

RE: https://bsky.app/profile/did:plc:a6qvfkbrohedqy3dt6k5mdv6/post/3ljkdpw5jhc2p

0
0
1
0
0
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
크랜베리 @Cranberry@mustard.blog
Public

한국에서 가장 쉽게 죽음을 선택할 수 있는 방법

1. 선풍기를 켜고 잔다...!
2. 백합꽃을 여러 송이 밀폐된 방에 놓고 잠을 잔다...!

3. 둘다 해보고 살아있음을 느끼며 쪽팔려 죽는다.

0
0
0
0
0
0