Hacker News Reader

Comment by samsquire | Hacker News Reader

I would rather inherit someone's stateful JavaScript or Java than a complicated codebase by a seasoned Clojure, Haskell, Scala developer.

I stand a better chance understanding the sequential code than a complicated recursive (edit: nested) monad. Depending how it was written.

I can probably understand Kafka pipeline's or a functional map, reduce pipeline.

My parser for my programming language which I'm building is a recursive Pratt parser but it's written in Java.

I want to understand functional programming better. I am interested in software transactional memory and parallelism. I am aware Erlang and Go use message passing but only Erlang is functional.

In theory functional code can be parallelised due to immutability but you need some kind of communication to indicate transference of values. Imagine a pipeline where you need to share a value to a few other threads. I'm aware Haskell has software transactional memory

View on HN

> I would rather inherit someone's stateful JavaScript or Java than a complicated codebase by a seasoned Clojure, Haskell, Scala developer.

Isn't that simply because you're a Java developer (as I understand from the rest of your post)?

Agree. The first version of the example (the one using only `map`) is way easier to understand and maintain than the rigmarole the author ended up with (writing their own functors, pipes, peakerror and what not). It's like the author didn't find the first version "complex" enough, so they had to make it more complicated for the sake of "functional programming".

Also all "functional" programs have their state somewhere.. just usually much stricter isolated and manipulated - so no difference in statefulness.

> I would rather inherit someone's stateful JavaScript or Java than a complicated codebase by a seasoned Clojure, Haskell, Scala developer. I stand a better chance understanding the sequential code than a complicated recursive monad. Depending how it was written.

True, but you add here the "complicated" attribute deliberately .. usually it is the other way round. The functional approach code is simpler to read and reason ( and usually not with much recursive monoids), while the believed sequential program has so many "concurrent" paths (even if there is no real concurrency, but just in the many hidden ways how the super distributed statefulness is manipulated).. not?

Your comment is very useful to me.

It spurned a chain of events that you might find interesting.

I am interested in parallel software and multithreading, so that's the kind of software I enjoy writing.

The branches of a single threaded software can think of potential future interleavings.

Your post inspired me to think of programs as "circular" or not. That is, they return to a steady state and can function properly no matter how many times they run and whether or not the execution is interrupted at any point.

A program that is interrupted can leave the program state in an invalid state that cannot be recovered.

So I started writing a parser to parse an assignment language. I plan to track object identities membership over time and see if objects get stuck in processing - they stop moving.

  program {
      available = {};
      assigned = {};
      main {
        program = programs {
           current_available = program.available {
                available += (current_available, 1);
                assigned - current_available;
            }
            item = program.requests {
                available (=) item {
                    program.answers += item;
                    available - item;
                    assigned + (item, 1);
                }
            }
        }
      }
    }

  program {
      requests = [];
      requests += (add, 1);
      main {
        item = answers {
            new_requests = [(add, 1)];
            available += (item, 1);
            new_request = new_requests {
                requests += new_request;
            }
          
        }
      
        answers -= answers;
      }
  }

Functional programmers are just as likely to make overly complicated code the same as a developer in a conventional language.

I'd rather inherit a complicated Java program than a complicated Scala program. But I'd take a well written Scala program over a well written Java program any day of the week.

Is there even such a thing as a “recursive monad”? That sounds made up.

No there is no such thing as a recursive monad. A monad is a type for which strictly defined operations are provided. It can’t be recursive by definition.

But hey, any strawman in the storm to make FP look bad.

Reply on news.ycombinator.com