Skip to content
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

Plans for part 3 #245

Closed
Fabs opened this issue Feb 14, 2016 · 36 comments
Closed

Plans for part 3 #245

Fabs opened this issue Feb 14, 2016 · 36 comments

Comments

@Fabs
Copy link

Fabs commented Feb 14, 2016

First, the book is awesome. So awesome I am wondering, are there are plans for part 3? :).

Or Else, if there are good resources someone can point about the topics on part 3 (comonads, f-algebras, free monads, yoneda).

@bcowgill
Copy link

I agree, the book is very good. A mix of theory with real world examples has finally got me interested in functional programming. I was hoping this was a teaser edition and I could buy the rest of the book right now.

@safareli
Copy link

Category Theory for Programmers

@gyzerok
Copy link
Contributor

gyzerok commented Apr 28, 2016

@DrBoolean it's been a long time since chapter 10 had landed. Are you interested in continue this book?

@DrBoolean
Copy link

Hello!

First of all, I am still interested in continuing the book and I really appreciate the patience and support.

There are a few things that have been holding me up:

  1. I left my own consulting company and took a "real" job. That dramatically reduced the amount of time I've had to work on side-projects.
  2. Es2015 outdated this book almost immediately after I released it. I no longer want to continue in es5. It's a bit of a predicament. One solution I can think of is to make @christiantakle 's fork the master branch and have an old es5 version that might be continued if anyone cares.

I'm hoping to carve out time this summer to really get into traversable, transformers, folds, monoids, and other stuff that really gets this style across the finish line.

@ChetHarrison
Copy link

I think with 20 volunteers we could update all the examples pretty quick.

@Fabs
Copy link
Author

Fabs commented May 2, 2016

Thanks @DrBoolean. I would be more then happy to be part of this es2015 updating taskforce, so count me in :).

@ChetHarrison
Copy link

I'm in

@christiantakle
Copy link
Contributor

@Fabs, @ChetHarrison Hi I have this branch: #235

I've apparently deleted it. Let me reify it so it can be the base.

The changes are mostly done, there are small syntactic changes needed. The most important part is making code runnable and fixing the assignment code.

@ChetHarrison
Copy link

@christiantakle good point we should see if others have made any progress on this. Perhaps post a checklist of pages or parts that people can volunteer for so we aren't stepping on eachother's toes.

@ChetHarrison
Copy link

@christiantakle wow so all you need is a code review?

@christiantakle
Copy link
Contributor

christiantakle commented May 2, 2016

@ChetHarrison #273 is now alive. I will go over my changes and update the description appropriately.

A code review/style review will be nice. I still need to update some of the surrounding code e.g. reader assignments.

I kinda slacked on the PR since there wasn't that much feedback so didn't know where to take it. I guess its a good idea to at least target all the features that current are in node version 6.

Aside

I really don't understand why the object methods require return e.g

let calc0 = { add(x,y)  { return x+y } }  -- Return statement :(
let calc1 = { add: (x,y) => x+y }         -- Expression :)

@ChetHarrison
Copy link

Yes I would say calc1 is the way to go.

@christiantakle
Copy link
Contributor

My issue is that it kinda make a worse solution look a bit prettier, see 1c92acd#diff-cea4600a73acf1f021dfce01227a34f6R66

I think it might be better for teaching purposes to use the method statements and maybe add a super small chapter on statements vs expressions.

I had a discussion on if vs the ternary operator a couple of years back and I didn't have a good argument for why I preferred the latter. I guess it is arguably harder to read in some cases compared to if. However the beauty of a functional style makes it easy to circumvent.

let when = (b,t,f) => b? t : f;

Aside

I actually did this nifty Fizzbuzz example last week by using the fact that (Monoid String). I do exploit a boolean circuit though e.g. "" => False

const
  whenDivisibleBy = (x,t,f) => n => n % x == 0? t : f,
  fizz            = whenDivisibleBy(3,"Fizz",""),
  buzz            = whenDivisibleBy(5,"Buzz",""),
  fizzBuzz        = n => fizz(n) + buzz(n) || String(n);

@ChetHarrison
Copy link

@christiantakle I'll see if I can take a look tomorrow. Yo @DrBoolean do you have a JSCS config or preference for this repo? That would be the easiest way to enforce style.

@christiantakle
Copy link
Contributor

christiantakle commented May 2, 2016

@ChetHarrison Cool, I'm London based so will go to sleep nice. It will be very nice with some feedback so I can finish/polish the PR.

Update: Last thing, I want to update almost everything about the assignments which currently is an incomplete frankenstein.

@ChetHarrison
Copy link

@christiantakle I'm in California so we can chat tomorrow. I guess I can't say, "in the AM" cuz you don' t have that in the rest of the world.

I will go ternary over an if when logic is short. I would look into ramda's "ifElse" for branching and "converge" for passing the same unary arg to two funcs and then processing the result. Let's catch up tomorrow. I have a somewhat crazy schedule but should have a few moments I can check in.

@Fabs
Copy link
Author

Fabs commented May 3, 2016

I'm in Brazil (GMT -3), I have plans to take a look at the pull request tonight and see if I can contribute with something. I am ok if someone more involved with the project just come up with a proposal and I could pick something to do, but I will try to come up with ideas too.

@ChetHarrison
Copy link

@christiantakle My issue is that it kinda make a worse solution look a bit prettier arrow functions will make a lot of things look prettier but the point is still valid I think.

@ChetHarrison
Copy link

I have to run but will look at your code later today.

@fobos
Copy link
Contributor

fobos commented May 3, 2016

Guys @ChetHarrison @Fabs @christiantakle let's discuss ES6 details in @christiantakle #273 branch.

@stevensacks
Copy link

stevensacks commented May 16, 2016

@DrBoolean If it's not too much trouble, can you quickly explain what you mean by "Es2015 outdated this book almost immediately after I released it"? Do you mean your code examples or do you mean some of the concepts (or implementation of the concepts) you presented have changed?

@DrBoolean
Copy link

Just that fat arrows (with implicit return), const, and other niceties have altered the way I write js in general and invalidated some of the long winded code I compare against

@gyzerok
Copy link
Contributor

gyzerok commented May 16, 2016

We had a chance to do it at the beginning #83 😸

@ChetHarrison
Copy link

@DrBoolean I apologize last week got away from me. I will try and review @christiantakle s code this week. I think he has done all the updates and just wants a review.

@DrBoolean
Copy link

No rush at all. Thanks so much!

@ChetHarrison
Copy link

No, trust me, THANK YOU!

@ChetHarrison
Copy link

@christiantakle I am digging into your fork! I there are 2 paths we can take.

  1. I can fork and add my edits
  2. I can add issues with my thoughts on why it should be so

If option 1 is the way to go I think you may need to do a PR to trigger the "Issues" tab which your fork currently lacks.

lmk

@ChetHarrison
Copy link

whoah, sorry I swapped 1 and 2.

@ChetHarrison
Copy link

let's try that again

@christiantakle I am digging into your fork! I there are 2 paths we can take.

  1. I can fork and add my edits
  2. I can add issues to your fork with my thoughts on why it should be so

If option 1, I will edit your repo and PR.
If option 2, you may need to do a PR to trigger the "Issues" tab which your fork currently lacks.

@ChetHarrison
Copy link

ahh @fobos will move the issue to #273

@crusoexia
Copy link

Any updates for the part 3?

@viztor
Copy link

viztor commented Dec 4, 2017

Any update?

@Fabs
Copy link
Author

Fabs commented Dec 28, 2017

Something is happening this Xmas :-)

#357

@backspaces
Copy link

I'd love to read Mostly Adequate but es5 makes my heart ache! Is there an es6 version with arrow lambdas? And the "functional" JS map, reduce, filter etc? And Import/export? Etc?

I'm planning on converting agentscript to functional style. It started in coffeescript back in the day I felt JS was down right dangerous! It was converted to es6 then refactored from an "app" to a "model/view" split. FP would make it even sweeter!

I do care about performance. I often use typed arrays for both speed and storage (often 100,000 "agents" and "patches). I use webgl and D3 currently for Views. All async is Promise based, often using async functions. My interest in FP is the D3 architecture which seems sane but probably not "pure", not sure.

Organizing into a sane repo (witness D3's 30 repos!) is really important. Monorepos may be the right way to go?

I use no webpack, gulp, babel or any other task managers .. I Write and Run, only doing tasks like Rollup, uglify, etc on publishing to github and npm.

I don't want to be snotty, I realize there are too many "I"s above, but just want to be clear and wonder if FP is a good fit.

So is there an es6+ version of the book? Could we refactor so all the code is "live" or imported somehow? (Observable? That's likely OTT and Observable is likely not ready yet.) Or Literate Programming style?

Whew!

@backspaces
Copy link

Oops, just saw #361

Does this mean the book is now available es6ified?

@pete-murphy
Copy link
Contributor

https://mostly-adequate.gitbooks.io/mostly-adequate-guide/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests