-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Still going? Documentation #62
Comments
Hi Julian: 2015-06-06 4:35 GMT+02:00 JulianLeviston notifications@github.com:
Alberto. |
Hi Julian: Yes it is in active development of course. I'm going to fuse MFlow with transient and hplayground. See the roadmap: https://github.com/agocorona/MFlow/wiki/Roadmap If you can contribute in any way, you are welcome |
Been looking for projects in Haskell that provide similar solutions to Clojurescript projects like Reagent. None of them feel as simple. Feels like Haskell doesn't quite have the same set of tools for client-side dev that clojurescript has. Hplayground might provide the answer to that question, but it's quite tricky to fully understand what it is. The documentation seems quite opaque / difficult to understand. |
What do you think/know about the Eve project, and Functional Relational Programming? (note: NOT functional reactive programming). Seems quite interesting so far. Would be quite interested in building a platform that allows "programming" as modification of code from within code itself, but unsure: does Haskell allow this form of dynamic programming? There's often an extreme amount of pain involved in programming. It feels a bet like a "proper" programming platform would entail simply relating various "flows" of data together in a declarative "language". One gets rather bored of repeating oneself over and over with each new framework or programming paradigm or language. Re-expressing the same intent over and over is so cumbersome. Why is code not simply data types related to each other through functions? The names that Haskell seems to come up with for things seems to be so much dross, and anything but simple. Anyway, I'm incredibly interested. I'd like to cut out repeating the same thing over and over and over. |
Hi Julian . There are a lot of interfaces of haskell with react. That is what Reagent hplayground is different and it is more simple to use and program with it import Haste.HPlay.View main = runBody $ do fact 0= 1 http://tryplayg.herokuapp.com/try/fact.hs/edit The documentation is not good (I expect someone to help me on that), but there are a lot of examples to play with it in the above link. I think that it is pretty intuitive, like MFlow. Ant there is a tutorial for an example application that is very complete: https://www.airpair.com/haskell/posts/haskell-tutorial-introduction-to-web-apps How it works is tricky and simple at the same time.When an event arrives at a certain point, it executes the sentence affected by the event and the remaining of the sentences. Just like MFlow when receives a new request.
Alberto. |
Concerning to functional relational, I have never read about it. But I I think that reactive in general is an error. A reactive expression is a OOP does manually (by the programmer ) that selection of actions to perform My approach (implemented in MFlow, transient and hplayground) is different, 2015-06-06 13:25 GMT+02:00 JulianLeviston notifications@github.com:
Alberto. |
Yes, aware of the various Haskell interfaces with React, but none of them really connect in a similarly intuitive way that Reagent does (normal react isn't very good). Not particuliarly married to React, by the way, as a rendering engine, it just removes a lot of the incidental complexity of ensuring the DOM is synced up correctly with the code. There are some other ideas such as freagent which throws off the react shackles, using a spreadsheet-like setup of "cells" (called "atoms" in Clojure - they're software transactional memory chunks) and keeps the state synchronisation by using cursors (functional windows into a small section of a big pile of state stored in these atoms). This way of dealing with state seems quite neat, and STM is amazingly awesome. Effectively in reactive, everything keeps up to date whenever anything is changed. Events are driven through channels (which are message queues), and there is one-way data flow. All data is immutible because of clojure. This is the way the facebook team are slowly driving towards anyway, but the clojurescript people have a bit of a leg up on the JS people, I think. Now, functional relational is something else entirely... You can read about functional relational here: http://shaffner.us/cs/papers/tarpit.pdf though in general it seems "coding" is gluing a bunch of descriptions of data together, similarly to how Haskell declares a bunch of types, except that the descriptions of the data are glued with relations, which makes a lot of sense. Haskell doesn't really do that. For example, you have a list of customers, and you use a list of male customers, then you don't have to write a function, the male customers are a filtered view on the customers. The "male customers" "type" is defined in terms of the customers "type". It looks like a very beautiful way to program. Unfortunately there aren't any languages that use it... except maybe cascalog. I'd very much like something like that but with Haskell... because, while clojure is beautiful, I constantly find myself wishing for types and a typechecker (and clojure's core.typed syntax is not pleasant). Essentially, I'd like to create a flexible language to express various things in, that I never want to have to re-express again. Do note that Functional Relational is NOT Functional Reactive. ReactJS is primarily reactive. Your appraisal of reactive is interesting, but it's not the day to day experience of using Reagent or any of the other client side clojure(script) frameworks. Because clojure has core.async, (http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html) this separates component communication and allows for composability and one-way data flow. It seems a core.async is similar to what you're stipulating in your "EDSL for hard-working IT programmers" post. This is very good, and quite complex "under the hood" from what I understand. Your EDSL sounded like it was actually much simpler? The trouble with Clojure, though, are that it's not lazy enough: EVERYTHING is lazy and super-declarative in Haskell. The concurrency story is a little bothering, (very manual) but perhaps that's inevitable. It's also a little bothering that one can't modify programs as they're running in Haskell, or perhaps this is mistake. This would preclude live coding. Aside from all of this, it seems your code is only intuitive to a Haskeller, sadly. I'd like to talk more with you about it, and understand more and learn more, and perhaps contribute to some of the documentation if it's a good fit for what I'd like to do. So far all of the front-side Haskell stuff that I've noticed is about getting haskell to write Javascript and this is awful. Perhaps there's a better place than here that we could talk about this stuff ongoing? |
Sorry for the delay. I have been busy. Tomorrow I will ask you. 2015-06-06 16:05 GMT+02:00 JulianLeviston notifications@github.com:
Alberto. |
Finally I´m free to answer you: 2015-06-06 16:05 GMT+02:00 JulianLeviston notifications@github.com:
Yes it is somehow related with my article that you mention. both I watched the slides of a presentation of core.async and it solves some
For example, a <|> b return either the result of 'a' or the one of 'b'
Alberto. |
Well, my email address is "kvmjboAmfwjtupo/ofu" if you subtract 1 from each of the ASCII codes for the characters. Drop me a line and we can discuss further via email. My point was simply that Haskell is not very intuitive or easy to people who haven't studied it. Contrast this to Ruby or Python, which almost read like English a lot of the time. (I'm not making a case for or against anything here, it's simply an observation about what is "easy" to the average person who doesn't know any of these languages). |
Is this project still under active development? The documentation could deal with a lot of love for new people.
The text was updated successfully, but these errors were encountered: