3 ms·

This sounds like a debugging nightmare. Is it not easier to name each intermediate result so you can inspect it in a debugger?

• Kache 5y ago
  In terms of debugging inconvenience for intermediate values, `->(x) | a | b | c` is the same as `c(b(a(x)))`. I find debugging /w a REPL using functional-esque code much easier. You can play around and exec/inspect lines/snippets at will without changing state & "breaking" the debug session.
  • lpapez 5y ago
    Agreed they are pretty much the same inconvenience level, but for me that level is too much either way. Maybe it's just my workflow, but I always preffered step-by-step debugging compared to REPL which is why I like to see many intermediate results being named.
• grapist420 5y ago
  when I hack it into python, it’s slightly annoying. when done properly, no, it’s no worse than f(a+g(b+c())), which is everywhere in code already. And debuggers / error messages should indicate what sub expression caused it, which would clean that up
• acdibble 5y ago
  Elixir includes IO.inspect[1], which prints a value and then returns it. It makes it easy to insert this function into a pipeline without disrupting the existing logic[2]. [1] https://hexdocs.pm/elixir/1.12/IO.html#inspect/2 https://hexdocs.pm/elixir/1.12/IO.html#inspect/2 [2] https://elixir-lang.org/getting-started/debugging.html https://elixir-lang.org/getting-started/debugging.html
• piaste 5y ago
  It's easier, but there are several considerations: - There's workarounds. Eg. in F# you can redefine the pipe operator in debug mode [0] so it can be stepped into and inspected. - I think some IDE plugins are also working on allowing pipeline contents to be automatically inspected. - And of course, there's the good old tee operator for printf debugging. FP style rarely mutates variables, so a few print statements are just as good as a live object inspector. As for why you actively wouldn't want to have those variables... much like comments, sometimes variable names add precious information and should be typed out, but sometimes they're just unnecessary noise, mental overhead, and scope pollution. E.g. compare: let suppliers = getSuppliers() let sortedSuppliers = sortBy getSupplierPriority suppliers let bestSupplier = first sortedSupplier to: let bestSupplier = getSuppliers() |> sortBy getSupplierPriority |> first [0] https://stackoverflow.com/a/4966892 https://stackoverflow.com/a/4966892