An introduction into Bacon

[laurilehmijoki]

Hello and thanks for Bacon, it is an awesome tool and I just love using it!

I've noticed that newcomers find it difficult to understand the basic concepts of Bacon. Thus I decided to spend a couple of hours in trying to write an introduction. It's here: https://github.com/laurilehmijoki/programming-with-bacon.

What do you think about the introduction? I'd like to get some feedback on it. Especially:

• What topics should be covered in it
• Are my reasonings sounds
• [your open feedback here]

Maybe the introductory article can turn into something that encourages new users to try Bacon.

[philipnilsson]

Hey @laurilehmijoki ,

I think the intro text at https://baconjs.github.io/ could possibly use an update that doesn't involve feng shui Bacon.

Unfortunately I think this text is not quite on point. (Thanks your enthusiasm about Bacon.js!, hope I don't sound too negative).

Everything is an event

Computer programming is best done via a rich set of solid abstractions, not by retrofitting your thinking to some watered down children's ontology like "everything is an object" and the like.

An introduction should focus on Bacon as one tool in the programmer's belt, by providing the abstraction of event streams. It's a library, not a framework.

Use simple components to construct complex programs

Value constructed by Bacon are event-streams. The operations in Bacon are about composing and combining such values. It's not about building complex /expressions/ per se (any programming language is about that), but rather complex denotations. It's about composing streams

Composing HTTP requests with single events are not the best example, since that can be accomplished by the simpler abstraction of future values (futures/promies).

Evaluate code only when the result is needed

This statement sounds more like marketing material than anything fundamental about Bacon. It's true that you have to subscribe to streams before anything happens I guess, but this is not a problem Bacon solves compared to e.g. futures/jQuery which also take callbacks.

I think the existing examples at https://baconjs.github.io/ are better, probably.

[laurilehmijoki]

Hi @philipnilsson

Thanks for taking the time to comment the text. I appreciate your feedback!

My aim is to write a text that sounds welcoming to programmers who don't have experience in functional programming. I'm trying to motivate such programmers to study Bacon.

Consequently, I would not start like this:

Computer programming is best done via a rich set of solid abstractions, not by retrofitting your thinking to some watered down children's ontology like "everything is an object" and the like.

The above sentence makes the imagined target audience of programmers-without-experience-in-fp feel bad about themselves, and that's not the best possible emotion to have when one is learning something.

I agree with you that the HTTP request example is not the best one. I'll try to think of a better one.

You are right: lazyness is not fundamental to Bacon. Maybe a chapter like "How does Bacon relate to other libraries" or "This is how Bacon relates to other programming paradigms" would be helpful.

A colleague of mine said that he was interested in Bacon but could not find a place where to get started. He is an experienced programmer who just happens not to have dived into the world of FP. He also said that he could not grasp the fundamentals from the examples on the Bacon's current website.

Hence, I'm still thinking that there is room for an easy-reading introduction into Bacon.

[phadej]

meta-comment

please read https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/

What I term the “monad tutorial fallacy,” then, consists in failing to recognize the critical role that struggling through fundamental details plays in the building of intuition.

This applies to Bacon, other FRP-inspired libraries, and FRP itself: IMHO, as sad as it is, you can't learn Bacon.js (and ideas behind it) in 15 minutes, and avoiding "struggling through the swamp" may be destructive for the overall learning process.

I hope that e.g. Functional Reactive Programming -book turns out to be good, so we can recommend it - as a guide to the middle of the swamp and back.

[philipnilsson]

@laurilehmijoki I agree that a friendly introduction is a good thing, and certainly shouldn't make people feel bad about themselves, but I do think we should not make claims like "everything is an event", as it's not true, nor relevant to the ideas of bacon.

I like that you want to focus on programming w/ Bacon as fun, as I think this is true. The easiest way to do that is by analogy w/ other functional concepts. A friendly introduction for programmers without FP experience is an interesting angle. I wrote a tutorial myself a long time ago which you can find at http://philipnilsson.github.io/badness/. It could probably be improved a lot, but might give you some ideas.

I took the Coursera course on reactive programming, which is a good resource. https://www.coursera.org/course/reactive. My experience from talking to people in that course makes me agree w/ @phadej that you typically learn these things best by committing to something like this course, and sticking with it for a bit, working through examples and getting your hands dirty.

[laurilehmijoki]

Thanks for the link, @phadej.

I like your Snake tutorial, @philipnilsson, thanks for sharing the link. The link to the Coursera course is also valuable.

Yes, without understanding what a monad is, one cannot fully comprehend Bacon.

Consequently, Bacon will remain a mystery to the programmer who will not take the time to learn the concepts behind functional programming.

I agree that we should not pass around claims that simply do not hold. With the "everything is an event" phrase I'm trying to create an anchor point that would invite the student to further study Bacon and FP. Is it a pedagogically good way to approach Bacon? Maybe, maybe not.

My concern is this: I've participated in multiple software projects where Bacon is a pervasive tool. I've seen how programmers who don't study things on their free time struggle to understand it. This has led me to attempt to write a tutorial for those who are not motivated to spend weeks of their free time to study functional programming.

I'm not sure that this attempt is worth the while – maybe we should just accept that one needs to invest in one's skills if one wants to build expressive and well-working software. In this case, we should make it clear to everyone that including Bacon in a software project means that the programmers need to take the time to study functional programming.

[phadej]

@laurilehmijoki I don't claim that you have to understand Monads to be productive with Bacon.js. But there are "issues" in Bacon.js, non-(FP)-experienced programmer could ask:

// Why this doesn't work?
stream.map(function (value) {
  console.log(value);
});

// or this?
stream.map(function (arr) {
  arr.push(1);
  return arr;
});

And those are hard to explain if you don't know anything about FP

---

My advice is to convince your colleagues that FP/FRP/Bacon.js -way will save you time and money in the long run. The real life projects will offer enough interesting examples and problems, so people will learn Bacon.js PBL-way. Just be present, to guide the learning process. The learning don't need to happen only on one's free time, I guess (hope) your employee understands that.

And write-up solutions to the interesting real-life problems for others to learn from.

[philipnilsson]

Juha has some cool interactive slides. Perhaps this could be adapted into some kinda problem-based interactive tutorial that newbies could take. If that's something you'd like to look into @laurilehmijoki I think it could be really sweet.

[raimohanska]

Actually there's also http://learn-bacon.herokuapp.com/

We might include some narrative between the exercises there to get a nice interactive tutorial. Now it's just questions and answers without any help.

[raimohanska]

Closing inactive issue. Not saying it's not important :)