Update sotu.md

[agocorona]

I added MFlow and hplayground to the mentions.

MFlow is the only web framework that uses haskell abstractions such is monad, applicatives, alternatives to create navigations and single page applications that are composable. The only web framework where navigations can compose and where formlets exhibit dynamic behaviours among other unique features. I think that this package is worth to mention.

hplayground is the same EDSL for page composition used in MFlow , but compiled with the Haste compiler and running client side instead of in the server.. hplaygroud is the only client side framework where widgets are composable with monadic, applicative and alternative combinators. There is no mention of FRP frameworks for Haste and hplayground is the most developed, with demos, tutorials, an a basic IDE

[Gabriella439]

I would like to see two more things before adding this so that new users trying this out don't get frustrated:

• Add more examples. The Haddocks for the MFlow package don't have any examples so new users will get lost figuring out how all the pieces fit together.
• Spend some time to figure out what the version bounds for your package should be (at least lower bounds if possible) to increase the likelihood of a successful compile for people not using stack. The more version bounds you provide the more informative cabal will be when it fails and the less likely it will try some silly combination of some really old and broken packages.

I'm mainly trying to improve the new-user experience in the Haskell ecosystem.

However, I love the idea behind the MFlow package. I love the idea of algebraic operations and abstracting away the details of page flow and session state. I think the package needs a lot more polish, better documentation, and more organization, but the above two issues are my main concerns.

[agocorona]

Gabriel,

Thanks.

The doc and examples are in MFlow.Forms:

http://hackage.haskell.org/package/MFlow-0.4.5.11/docs/MFlow-Forms.html

2015-09-02 19:28 GMT+02:00 Gabriel Gonzalez notifications@github.com:

I would like to see two more things before adding this so that new users
trying this out don't get frustrated:

• Add more examples. The Haddocks for the MFlow package don't have any
  examples so new users will get lost figuring out how all the pieces fit
  together.
• Spend some time to figure out what the version bounds for your
  package should be (at least lower bounds if possible) to increase the
  likelihood of a successful compile for people not using stack. The
  more version bounds you provide the more informative cabal will be
  when it fails and the less likely it will try some silly combination of
  some really old and broken packages.

I'm mainly trying to improve the new-user experience in the Haskell
ecosystem.

However, I love the idea behind the MFlow package. I love the idea of
algebraic operations and abstracting away the details of page flow and
session state. I think the package needs a lot more polish, better
documentation, and more organization, but the above two issues are my main
concerns.

—
Reply to this email directly or view it on GitHub
#51 (comment).

Alberto.

[GetContented]

Hi, I'm going to go through the initial part of your documentation and explain the problems with it, coming from the perspective of a beginner.
I'm going to do this in a very harsh way. If you'd like to, you can just ignore this criticism. However, it's positive criticism. I'm doing this for YOU. Not for me. My aim here is to point out how difficult understanding your framework is so you can improve it. I am in no way trying to offend you. You're of course, free to take offense. Please don't.

MFlow run stateful server processes. This version is the first stateful web framework that is as RESTful as a web framework can be.

What does "MFlow runs stateful server processes" mean? I don't understand it. Haskell & the GHC runtime runs stateful server processes. MFlow may be a server. Is that what this is an attempt to express here? Every computation is a stateful process, so there's little information in this.

"as RESTful as a web framework can be" doesn't mean anything much. A web framework either embraces REST, or it doesn't. There aren't really degrees of this, besides which this statement contains little actual information.

The routes are expressed as normal, monadic Haskell code in the FlowM monad. Local links point to alternative routes within this monadic computation just like a textual menu in a console application. Any GET page is directly reachable by means of a RESTful URL.

This is the second statement in the documentation, and it's talking about "normal monadic code". This is a massive barrier to understanding for new people, which I assume are the ones it's being written for. The terms aren't being defined: What are "routes" here? are we supposed to just know this? "local links" - does this mean hypertext links in to the web site one is creating when one is authoring the web app, as the developer? What are "alternative routes"?

What is a "textual menu in a console application", and why does it apply here? What is a GET page? GET is an HTTP method, not a page. The language is confused, and there is little information contained here.

At any moment the flow can respond to the back button or to any RESTful path that the user may paste in the navigation bar. If the procedure is waiting for another different page, the FlowM monad backtrack until the path partially match . From this position the execution goes forward until the rest of the path match. This way the statelessness is optional. However, it is possible to store a session state, which may backtrack or not when the navigation goes back and forth. It is up to the programmer.

What is "the flow" here? Why "at any moment"? It's unnecessary to say this. Modern OS & Web Browsers are generally event driven, so one doesn't need to say this. What is "the procedure"? "another different page" - different to what?

What does "the FlowM monad backtrack until the path partially match" mean? It's unintelligible, as is the rest of this paragraph. It doesn't explain why statelessness is optional.

All the flow of requests and responses are coded by the programmer in a single procedure. Although single request-response flows are possible. Therefore, the code is more understandable. It is not continuation based. It uses a log for thread state persistence and backtracking for handling the back button. Back button state synchronization is supported out-of-the-box

What is a procedure? "Although single request-response flows are possible." <- this is not a correct sentence. Then "Therefore, the code is more understandable" doesn't follow on from the previous sentence. The rest of this sentence is vague and inexpressive.

I'm going to stop here because the rest of the documentation has similar problems.

My aim here isn't to bash your documentation, but rather to express the problems with it. It's not achieving the aims it sets out to achieve: to educate and elucidate.

[agocorona]

Thanks GetContented.

Thanks a lot. Let me see that I like criticism when it is done in that way. I love sincere people very much.

Besides my bad english and the evident lack of attention to the details, the obscurity of the documentation in the package is because it is made for haskellers who know the problems associated to continuation-based frameworks, so they know monads and so on. So it is made in a defensive way.

The documentation and examples for the users is somewhere else, here:

http://mflowdemo.herokuapp.com

https://www.fpcomplete.com/user/agocorona/MFlow-tutoria

It happens that now very few people know what is a continuation-based framework is. even many functional programmers don´t know what is it. I will remove all of this since it does not matter.

In the other side, for hardcore haskellers, there is a paper:

https://themonadreader.files.wordpress.com/2014/04/mflow.pdf

There would be many things more to say about the documentation. The main problem besides my awkward english is that MFlow is so different to any else's that either I have to enter in endless technicalities or I assume a context that most of the people don´t have or I use shorthand expressions like "GET pages".

In the other side, it challenges many assumptions and make experienced Web programmers uncomfortable.

[GetContented]

@agocorona

Ok, in that case it sounds like it's not a good fit for this document, as this document is clearly aimed at beginners and representing a comparison platform between Haskell and other languages (showing what shines, explaining the problems).

As to your other documentation, sorry to say but it felt like the same problems were at play in those documents, too. I don't particularly like giving people bad news, but it might just be that MFlow is not a good fit for beginners to Haskell. (And, even for non-beginners who haven't had the pain that MFlow is trying to solve - MFlow might need some PR work if you want to increase its popularity: make some videos of building functionally useful web apps quickly in ways that are impossible in other frameworks, for example).

You might be surprised about awareness of continuations based web frameworks. Seaside (for Smalltalk) is a great example of one; one that I'm pretty sure quite a lot of functional coders are aware of.

[agocorona]

i think that an application with three pages in a tweet is one of the best ways to show something that is impossible in other frameworks. That is on the front of http://mflowdemo.herokuapp.com

Yes, I talk about seaside in the documentation, but I can not be said that it is one of the most known frameworks. Even in smalltalk it is not the most popular.

If you have been sincere with me, let me be sincere with you: I said that MFlow makes experienced web programmers uncomfortable and a bit angry since it challenges their assumptions about what a web application is.

But I have the perception that MFlow also makes haskellers uncomfortable since it looks like a new chapter in the book of haskell to learn, instead of a chapter to write by themselves. I don't want to be pretentious here. This is just my perception.

In the other side I´m a disaster on marketing and organization and my wife say that I have a better relation with machines than with human beings. But If I could have the skills to popularize MFlow, I have no time, since constantly I have new ideas to develop and my blood is made of binary digits.

Unless there is some help, for the coming months MFlow will stay as it is, take it or leave it with all his documentation problems.

But I continue developing the underlying infrastructure, because I'm convinced that this is the future. There is a long way. MFlow is part of a new architecture. There is a new generation of web programmers and haskellers that will appreciate it

[GetContented]

@agocorona I don't doubt for a second that a new architecture is required... to a large degree, I've been trying to invent and implement it (though, you're at a massive advantage compared to me here in that you obviously understand Haskell much better than me).

The major problem, though, that I can see with this "new architecture" is the storage of code and change to this code. Code is, by and large, unevaluated data. End users don't want to know code to change their websites, and Designers shouldn't need to learn code to change code structure and take advantage of content reuse. This is a massive problem which most people simply aren't aware of, PARTICULARLY programmers. We're terrible at seeing this as a problem - probably because writing code is so easy for us.

RDBMS's just don't cut it.

Our business's app's editor is built using this "computed, cached data flowing" idea - but it's early days (www.getcontented.com.au is the front end of our web development system based around the editing of content). I still need an excellent backend storage solution - which I'm attempting to look around for as we speak.

[agocorona]

@GetContented

It may be not the perfect solution, but I´m happy to say that I though on the problem of separation of layout from logic. And I found a solution that I find satisfactory.

First, MFlow has fields with a default layout that are editable at runtime by designers. That is a kind of content management. The widgets are tField (without editing) and tFieldEd (with editing)

That is concerning pure content fields, but also forms and links generated by MFlow can be edited at runtime. There is a widget modifier edTemplate that permits designers to reshape the form fields, layout etc at run time.

The designers see the code generated by the application. As long as they don´t erase the application generated elements, they can add more content and layout. if they do, they can reset it by deleting all the content.

There are other widgets for that purpose: witerate and dField. They define an editable template with "holes" (`dField' s) that contain dynamic content that is managed directly by the application.

No other framework that I know has these features by the way, and I doubt that they may have, since they lack the foundation necessary for that.

[GetContented]

I think we mean different things by "separation of layout from logic". I mean it's in a different spot. There's just no way my designer will ever learn Haskell.

[agocorona]

No, the designer would not need to know haskell. The goal is to keep the designer away of the code and viceversa.

The designer enters in the application when his logic is fully developed and tested.

When he log in in the site, He would see just a page rendered in the browser with editable sections. Not a single bit of haskell code. He would edit the content and that's it.

This is a simple example. Uses tFieldEd
http://mflowdemo.herokuapp.com/noscript/templates/textedit

you need to enter with edituser/edituser to edit the content of the example

this other example is more complex, uses the other directives: edTemplate etc..

http://mflowdemo.herokuapp.com/noscript/templates/runtimetemplates

The code of the examples are at the bottom of each page.

The texts of the entire demo site have been edited with the same techniques. (As you can see I´m not a master of design). You can edit the texts of the site by logging with editor/editor . Maybe you need an extra refresh with F5. Heroku will reset the changes

I mean, it is not perfect. In the demo site, the separation is not perfect, since the demo program predefines a header, a menu on the left and a main section. the designer can not change that. But even that could have been defined by the designer if I put edTemplate and define dFields for all the page at the top level