← Graph

Should the tooling or language change to support these workflows?

question 3 connections

Audience member suggests that since Ruby's inheritance/module/super mechanics didn't help and Nick moved to a functional approach, maybe the tooling — or the language itself (e.g. Haskell, Elixir) — should change. Nick answers: Ruby wins on community and conferences (Haskell conferences would be half-empty); he discussed it with José Valim, and even Elixir's pipe operator only handles linear flow, so the moment you need multiple outputs per step you end up with something close to Trailblazer's step DSL. Monads would solve it but he's not a math professor. He still feels welcome in Ruby despite criticizing it.

answer_summary
Ruby's community makes it worth staying; no other mainstream language has this activity/multi-output abstraction without monads, even Elixir ends up needing a step-DSL-like construct.
question Should the tooling or language change to support these workflows?
about
Elixir tool
Question raises Elixir as a possible alternative; Nick answers via Elixir's pipe operator limits.
question Should the tooling or language change to support these workflows?
about
Ruby tool
Asks whether Ruby is the right language for this style of programming.
question Should the tooling or language change to support these workflows?
asked_at
Asked during the Q&A after the talk.

Provenance