pka

  fib :: Int -> Int
  fib n
    | n <= 1    = 1
    | otherwise = x ‘par‘ (y ‘pseq‘ x + y + 1)
    where
      x = fib (n-1)
      y = fib (n-2)

[1] http://simonmar.github.io/bib/papers/strategies.pdf

[2] http://hackage.haskell.org/package/parallel-3.2.2.0/docs/Con...

> list.select { |x| x.foo > 10 }.map { |x| x.bar }

Where's `bind` or `join` in that example?

OO is very much about state, and that's the fundamental difference between non-FP languages and FP.

    a1 = object.f(b);
    a2 = object.f(b);

It also doesn't matter if your language implements OO in terms of message passing (Smalltalk, Erlang) or method calling (Java, C#, ...).

> Or you change the game and just use PureScript. Or ReasonML, or Elm, or even ClojureScript.

> If you want to see actual dynamic typing and how it can shine, use ClojureScript. If you want to see actual static typing and how it can kick ass, use PureScript.

1. Overriden methods have access to the internal state of the parent class, which is almost universally a bad idea.

2. Since functions are values, you can freely mix and match different view configurations without having to create a subclass for every permutation.

React begs to differ.

> or ontologies that directly mirror real-world objects.

Such as?

    nsTableView ::
      { renderCell :: a -> NSView   -- this is the function that renders a cell given an `a`
      , header     :: NSView
      , footer     :: NSView
      }
      -> [a]
      -> NSTableView a

React calls this pattern higher order components iirc.

I think many people do think that, with a twist; specifically, when presented with a higher level language they'd argue "it's just a tool", while a lower level language would be "the wrong tool for the job".

I.e, for a hypothetical Ruby programmer, Haskell = "just a tool", C = "the wrong tool".

Slap a 10x (or even 100x) fine on companies whose data breaches are discovered independently and covering stuff up won't look like such a good idea anymore.

I'm not saying I argue for the opposite, but that is very definitive statement in need of a very strong argument to be taken seriously.

> What does that even mean?

Things that we don't even know how to talk about yet, like consciousness.

Even if consciousness is just an emergent phenomenon, this still doesn't explain the subjective experience of consciousness. Subjective experience might be irreducible, but it might not. We don't know yet.

From what I understand, you're claiming that we can't explain higher levels of emergence in terms of lower levels. But that's not true, and your example of hardware/software is the prime example of that. We can explain or model every level of abstraction perfectly in terms of the preceding, lower level of abstraction, until we get to the quantum mechanical properties of the substrate your software is running on.

Whether it's practical to talk about the rules of chess in terms of QM is another matter - it's not - but I'd maybe argue that's because we're not intelligent enough to hold enough information at once in our brains, not because of some inherent impossibility of doing so.

One of the most cited qualities of languages like Haskell are their "refactorability" - i.e. one can routinely rip out the guts of a 100KLOC codebase and replace fundamental data structures and functionality in order to implement new features in a couple of hours, no problem whatsoever.

In Rails, I'd do everything in my power to not touch any "important" code if I can get away with it, because no matter how good the test suite, it's still a test suite. It shows the existence of bugs, it doesn't prove their absence. Many people claim that's not a problem in practice, but I personally tend to avoid more fundamental code changes in dynamic codebases precisely because of that fact.

To drive that point home, I'd trust a Haskell codebase without a test suite more than a Rails codebase with an average to good test suite.

Also, it seems to me that "moving fast" is directly at odds with the topic at hand, upgrading Rails. If Rails allowed one to move fast, then surely upgrading Rails shouldn't take a year and a half, even in a big codebase?

> Spec driven design seems to offer some of the benefits of static typing with the flexibility of dynamism.

Definitely, though it's not a replacement for types. Also, the probably more important thing here is that Clojure is functional, making a whole class of bugs stemming from mutability and OOP impossible.

If you're planning to go down the Clojure/spec route, you might want to check out Ghostwheel [0], a lightweight DSL which seems to be gaining a lot of traction lately.

[0] https://github.com/gnl/ghostwheel

Whether emergence can explain everything is another matter though, and I think that's where "irreducibility" might come into play.

You may accuse me of shifting the goalposts, but do notice I said modern above. I'm not up-to-date with Java anymore, but iirc Play [0] would be worth checking out.

> This is a problem you want to have because you have skin in the game.

I'm saying that this is a problem you don't have to have at all.

> Back to you - you didn't address my question - if you were to launch a product idea, what static stack would you pick?

In the context of SPAs, I'd choose some of the Purescript React libraries and some generic Haskell REST/Websocket server, like Warp/Servant (this is a stack I've used in production).

For a standard web app, I'd go with Yesod [0], which is a somewhat Rails-like framework, but it fully leverages the advantages of static types, i.e. it turns things like dead links, trying to inject user input into a DB query without escaping it first, invalid queries (i.e. querying a person by product id), and many more into compile-time type errors.

> I'm not saying you're categorically wrong, but you haven't presented any science to support your dismissive tone.

Still, to claim that the context of the current thread at least doesn't suggest that Rails is a maintenance nightmare would be disingenuous at best.

> Pick the right tool for the job.

That's what we're discussing here, right? I can't see when Rails would ever be the "right tool" for anything (except for the one use case I alluded to above) but that's obviously subjective, rendering that phrase utterly meaningless.

[0] https://www.playframework.com

[1] https://www.yesodweb.com

> The project originally began with 1 full-time engineer and a small army of volunteers. We grew that team to 4 full-time engineers plus the volunteers.

They had four full-time people working on upgrading Rails at some point!

Again, even if "rapid prototyping" was a thing in Rails (i.e. rapid as opposed to what?) you start paying back the price tenfold once your project becomes moderately complex, test coverage or not.

So if your question is specifically "What's a good stack for a blog I'll never touch again or maintain with X and Y integration, tomorrow", then ok, cool, Rails.

I could take a big, unmaintained 10 years old Haskell codebase and upgrade it to the newest compiler and libraries in a couple of days, at most (and it would most likely work on the first try after it compiles).

So, spending a year and a half on a major version upgrade of your web framework is "productive" how exactly?

I mean, whatever time you think you've saved by using Rails during the initial prototyping phase (and I don't think even that's true), you'll more than pay for in maintenance costs.

[0] https://twitter.com/pkamenarsky/status/961666713900249088?s=...

If you want proper static typing though, ReasonML might be a good choice. Static, compiles to js and native, super easy to learn, and there’s an experimental Lisp frontend with Clojure-like syntax if you can’t live without paredit.

[1] https://github.com/gnl/ghostwheel

No, I don’t, and when I happen upon somebody who is competent in Haskell and still prefers Clojure/Erlang/whatever then genuinely interesting conversations tend to happen.

This is not the case here though.

And I don’t need to. I (and anyone proficient in Haskell, really) can infer your competence with somewhat reasonable confidence based on your comments, like this one.

People who’ve just read LYAH are able to contribute to production codebases already, no problem, but they still may not have even understood basic concepts, such as functors or monads (this is firsthand experience from work), let alone monad transformers, arrows or lenses - which I consider to be a good thing. Based on your comments (and not only this thread here), this is where I’d place you in terms of competency, but of course you are more than welcome to correct me.

I’ve done no such thing.

> You can't even acknowledge that your preferred approach to dealing with side effects has any drawbacks to it.

It does, probably not the drawbacks you think of though (“conceptual overhead of types”?).

Generally, you seem to be awfully incompetent in a language you claim to have used for a year. That’s not a bad thing, but you don’t present your arguments with a big fat disclaimer stating that. If you did, I think there would be much less tension in these kind of discussions.

That's an interesting thing to say, seeing how representative figures of (specifically) the Clojure community get really defensive really quickly once somebody questions the effectiveness of dynamic typing - which I specifically didn't do.

> He outright dismisses that any valid alternatives are possible

I was merely dismissing your incorrect claim about logging in Haskell. And yes, not taking advantage of the type system when you are already programming in a language with a type system amounts to #yoloing it, in my opinion. Doing the same in other languages is fine, since you don't have another option really.

Many would consider that a feature, but if you want to #yolo it anyway, like in most other languages, just use trace in prod and call it a day.

For future reference, this isn’t a good argument for trolling Haskellers.

That was your original, nonsensical, point (emphasis mine).

> My point is that tests and runtime contracts provide sufficient guarantees in practice.

That's your revised point (which I don't care much about discussing), after moving the goalposts sufficiently.