haskman

Edit: I changed my response after I took the time to understand what you meant.

Concur has a very uniform programming model where you do everything by composing widgets. `elm` is a widget. `render` also is a widget. As such both can perform arbitrary async effects, and they take place inside event handlers, or inside lifecycle methods like componentWillMount. Concur takes care of managing that for you.

So to log all actions to the console, you can add a logging call to `elm`.

    elm render update = go
      where go st = do
          action <- render st
          liftEffect (log ("Action - " <> show action))
          go (update st action)

Meanwhile, the render function itself can be a widget which performs side effects -

    view = do
      evt <- button [onClick] [text "Click me"]
      liftEffect (log "Button was clicked")
      return evt

There are lots of examples of effects in the Concur repo - Take a look at some running examples here -

https://github.com/ajnsit/purescript-concur/blob/master/exam...

And running demo -

https://ajnsit.github.io/purescript-concur/

> Hum... No. Abstractions can hide anything.

Sure, I'm not going to argue the meaning of "state". You know what I mean. Hiding internal state is good for abstraction.

> Besides, your example get much of its gains by hiding the behavior of that 'if' statement than by hiding that 'buttonClicked' stores the button data.

The if statement is intrinsically linked to the boolean state. If your render function forgets its implicit state on every update, then it needs to painstakingly analyse an external state and recreate its internal state. That's a cost which can be avoided.

It might seem like that, but javascript generator semantics mean that execution pauses at the first yield, and awaits external input before it resumes computation.

Also, the framework I described is only partially "hypothetical". [Concur-js](https://github.com/ajnsit/concur-js) gives you almost the same syntax and semantics. So you can try it out yourself :)

Of course you need to understand how the framework works. But that's a fixed cost vs. having to understand a program from scratch everytime when your framework is not clear or powerful enough.

Would you also say using "goto" is easier because it's a simple jump, vs. having to understand how while/for loops work?

Testing could be much easier for the implicit state version. I've not defined it, but you are assuming things about how the render function or the implicit state behaves.

In my hypothetical implicit state framework - A widget is composed of a sequence of steps, each of which is an independent widget. So it's easy to write invariant properties for each step -

For (text "String") it's guaranteed that the widget never returns a value or raises an event. i.e. the type is

    forall a. Widget a.

So the issue of calling render a third time never arises.

> I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with.

Actually in practice that's much less of an issue when using typed FP. I've found that it's easy to modify parts of code which you do understand the implementation of, while still being able to use the interface of other potentially more complex parts. Of course YMMV.

> Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you.

I have heard this sentiment earlier, and I believe that there is a better middle ground. Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill.

> Also a little surprised you mentioned do notation; it's just syntax sugar after all :)

Oh it's less of an issue, but syntax does matter a lot. I find that Monads become intractable for new devs without do-notation.

> You can move faster without type checking but a lot of times that just means letting code with silly bugs through that you're going to find @ runtime.

Oh yeah absolutely. And also, FP and immutability makes everything much easier to understand. Getting new devs making changes to 50k lines of JS is much much much worse than with a Haskell/Purescript/Elm project of similar complexity.

I understand what you are saying, but - the whole point of abstractions is to "hide state". For example, what is nicer to write/read? Pseudocode -

    // Stateful
    state = {buttonClicked: false}
    render() {
      if(!state.buttonClicked) {
        return button({text: "Click Me", onClick: {state.buttonClicked=true}})
      } else {
        return text("Thanks!")
      }
    }

vs.

    // Implicit state
    render() {
      yield button({text: "Click Me", onClick})
      yield text("Thanks!")
    }

Coming in from the other (Functional Programming) side, Elm can be restrictive (no typeclasses, do notation etc.). But it does walk a fine balance, and I love that there's a popular-ish language that is exploring the ease-of-use design space.

Flux/Redux were inspired by The Elm Architecture. I don't know if there was something similar before Elm popularised this style of building user interfaces.

Concur was first written in Haskell, so it's got the Functional Programming part down :) The other interesting part was TEA, which is hard to simplify further, but I think Concur's model manages to do that while simultaneously being more powerful.

Edit: I don't know what gave you the impression that I don't like types. I love types! I wish JS had more of them. I write Haskell/Purescript (and Javascript) in my day job.

Shameless plug - I'm trying to improve upon Elm and React's programming model with my Concur UI framework. Its programming model is a bit unusual, it uses Monads to sequence widgets in time, but it is designed to be extremely simple to use, and you don't need to actually understand Monads to use it. An advantage is that it's not artificially restricted like Elm, and allows you to use advanced Functional Programming tricks when you can and want to.

It is available for [Haskell](https://github.com/ajnsit/concur), [Purescript](https://github.com/ajnsit/purescript-concur), and [Javascript](https://github.com/ajnsit/concur-js) (so no need to learn a new language), and also allows using external React components. The Javascript version uses Async Generators as a substitute for Monads.

With Concur, you can implement the entirety of Elm architecture with a few lines of idiomatic code.

Purescript or Haskell -

    elm render update = go
      where go st = do
          action <- render st
          go (update st action)

Or in JS -

    function elm(render, update){
      var go = async function*(st) {
        action = yield* render(st);
        yield* go(update(st, action));
      };
      return go;
    }

Interesting! As another point in the design space - I wrote a JS UI library (based on React) that uses async generators for state transitions. https://github.com/ajnsit/concur-js

If you want something that's (really) easy to get started with, and yet won't artificially constrain you from using your functional programming tricks as you evolve, I recommend trying out Concur [Haskell version](https://github.com/ajnsit/concur) or [Purescript version](https://github.com/ajnsit/purescript-concur). I wrote an initial introduction which also compares it with elm - https://github.com/ajnsit/concur-documentation/blob/master/R....

S&P Global | Full-Time Onsite | US - New York, Boston, Denver. India - Gurgaon

S&P Global is hiring functional programmers at various levels and locations in US and India.

We are the Analytics Product Development Team, a relatively small group of developers focused on building next generation financial models and applications that leverage S&P's world-class data sets. Last year we launched a re-imagined Portfolio Analytics product that helps investment managers of all types measure the efficacy of their investment strategies and identify areas of risk in their equity portfolios. Put your FP skills to use as we move on to multiple asset classes, intraday analytics, and strategy modeling.

Functional Programming has a relatively long history here at S&P Global. We build our back-end data calculation engine using purely-functional Scala in 2008 and have been building new models and expanding it ever since. We created Ermine, a Haskell-like language featuring row types that can run on the JVM. Ermine drives our templating, reporting, and database access, adding type-safety to user-generated layouts. The new Portfolio Analytics is a single page web application that makes extensive use of PureScript. All of this co-exists in a diverse tech ecosystem that includes the JVM, .NET, and SQL Server.

We have a few open positions, so we are looking for developers with varying levels of experience. Ideal candidates have FP experience, but we'd still like to talk with you if you are just getting started with FP and are looking to grow. Please email resumes or questions to smcfarland@spglobal.com.

S&P Global | Full-Time | US - New York, Boston, Denver. India - Gurgaon

S&P Global is hiring functional programmers at various levels and locations in US and India. No Remote.

We are the Analytics Product Development Team, a relatively small group of developers focused on building next generation financial models and applications that leverage S&P's world-class data sets. Last year we launched a re-imagined Portfolio Analytics product that helps investment managers of all types measure the efficacy of their investment strategies and identify areas of risk in their equity portfolios. Put your FP skills to use as we move on to multiple asset classes, intraday analytics, and strategy modeling.

Functional Programming has a relatively long history here at S&P Global. We build our back-end data calculation engine using purely-functional Scala in 2008 and have been building new models and expanding it ever since. We created Ermine, a Haskell-like language featuring row types that can run on the JVM. Ermine drives our templating, reporting, and database access, adding type-safety to user-generated layouts. The new Portfolio Analytics is a single page web application that makes extensive use of PureScript. All of this co-exists in a diverse tech ecosystem that includes the JVM, .NET, and SQL Server.

We have a few open positions, so we are looking for developers with varying levels of experience. Ideal candidates have FP experience, but we'd still like to talk with you if you are just getting started with FP and are looking to grow. Please email resumes or questions to smcfarland@spglobal.com.

Gurgaon candidates, please email anupam_jain@spglobal.com and apply here -https://spgi.wd5.myworkdayjobs.com/SPGI_Careers/job/Gurgaon-....

That's strange. Vim and tmux work fine for me on MacOS.

That was amazing! Especially the machinery of the second part where the DNA strand is replicated backwards!

Agreed, that was very strange. Right click "Copy video link". Leads me to - https://www.youtube.com/watch?v=Gy5m091fOTU

I recently launched http://geohangout.com. The entire backend service is written in Haskell (Yesod).

I recently named my android app and website through them. It was quite a straightforward and pleasant experience.