Update readMe to use javascript. Resolves #1.

[mfowlewebs]

No description provided.

[sourcevault]

Does the livescript make the readme difficult to read ?

[mfowlewebs]

It definitely makes it more difficult to read. I personally find it significant. It also indicates an act of bad faith on the author, IMO, that they are not willing to help 99.99% of consumers figure out what their library does. People badmouthing libraries because the readme is coffeescript or cocoscript or whatever is a fairly normal developer experience, one that's easy to avoid. People are here to learn and use a library: let them, preferably without having to learn another language.

[sourcevault]

I am sorry you feel that way.

Github does make it slightly difficult to create multiple version and easy switching.

Having said that I do believe that ES5,ES6 does make the concepts harder to grasp. JavaScript is closer to C syntax wise and I am not sure anyone is advocating writing functional code in an Algo derived language.

Sometimes you need to invent new notation to explain a certain concept. A good example is the axioms of set, probability, calculus etc.

LiveScript is closer to haskell, and a lot of these concepts make a lot of sense using haskell notation.

Since I cannot write haskell in javascript ( easily at least for now ) I find LiveScript the closest solution.

I am sorry that you found it difficult to understand. I am currently rewriting it and will include a vanilla JS version, but keeping the default as livescript.

[mfowlewebs]

Was trying to fix

Sorry about that, I have been meaning to write a guide in vanilla JavaScript rather than the default one which is written in LiveScript :(

From #1 (comment) . Welp. This decision is bad. Your docs ought target the language, and I did exactly that.

Now that there's destructing in JS I see literally 0 ability for you to hold out from these changes yet you insist on intransigence. I don't understand what if any suggestions about haskell ness you could legitimately support.

But if you don't want to merge it fine, sure, whatever.

[sourcevault]

I am writing a newer a version of mostify based on what I learnt using it for the past month.

Your views on writing a guide using JavaScript is of major concern to me.

I am going to make the javascript version front and center.

However, I would still like the default to stay LiveScript.

My reasoning for this is simple :

• I find it easier to reason about functional code when I am using LiveScript, there may be many programmers who might be unfamiliar with LiveScript and that is why I want them to at least see LiveScript being used. When someone is using some new piece of technology - my first instinct is to not outright reject it. I would want to study it before having a opinion on it.
• LiveScript reduces code clutter, a major part of what makes it hard to program in JavaScript is :
  • brackets
  • no white space indentation
  • verbosity

I would accept your merge request if instead of deleting the livescript code in the readme, you created a separate set of doc that I could link to - so no need to worry.

However the other reason I am not accepting the merge request is I am changing the entire API and doc :(

Essentially I have been thinking of what it actually means to mostify a function.

It turns out that nodeStyle is a special case of a much more general way to convert non-stream based async functions, regardless of the API.

I am really excited to push the code, and share what I discovered, however for me - writing docs is the hardest part of programming.

I really appreciate your input regarding the docs, and yes I am at fault for not making the docs more easily accessible - LiveScript after all is a very obscure language - but I really want JavaScript programmers to see the value of better syntax for programming.

Thanks !