Anyone else try to do a lazy AND evaluation for chapter 12 and have it fail? I did fC(gC(function(){success,failure};),failure); but the desired answer checked gC even if fC already failed..
I'm not sure that makes sense?
41–50 of 60 posts
Anyone else try to do a lazy AND evaluation for chapter 12 and have it fail? I did fC(gC(function(){success,failure};),failure); but the desired answer checked gC even if fC already failed..
I'm not sure that makes sense?
Wow, I love the flow! Except JSLint. JSLint barfs all over otherwise valid JavaScript and provides really unhelpful error messages. For a minute, I thought that I forgot how to write valid JavaScript.... Hate! Hate! Hate! You're teaching folks to program, not write syntactically pure JS. But drop that and the experience is great.
(Creator here) Ha, yeah JSLint really provokes strong emotions. Before I added in JSLint, if you misplaced one semicolon or forgot a parentheses, none of the tests would run and it would just say "program failed". That was incredibly frustrating to me. I figured that if I was getting frustrated, and I was the creator of the tests, then random users would be REALLY frustrated. So I added in JSLint. Now you get line an…
I created a successful bothC function that looks more like the simplified version of seqC, calling fC first. But when I switch to calling gC first, I get the following failures. Am I missing something, or is this a bug in the unit test?
PASSED No JSLint errors
PASSED bothC(S, S, A, B) === undefined
PASSED output === "SSA"
PASSED bothC(S, F, A, B) === undefined
FAILED output === "SSASFB"
PASSED bothC(F, S, A, B) === undefined
FAILED output === "SSASFBFSB"
PASSED bothC(F, F, A, B) === undefined
FAILED output === "SSASFBFSBFFB"Wow, I love the flow! Except JSLint. JSLint barfs all over otherwise valid JavaScript and provides really unhelpful error messages. For a minute, I thought that I forgot how to write valid JavaScript.... Hate! Hate! Hate! You're teaching folks to program, not write syntactically pure JS. But drop that and the experience is great.
(Creator here) Ha, yeah JSLint really provokes strong emotions. Before I added in JSLint, if you misplaced one semicolon or forgot a parentheses, none of the tests would run and it would just say "program failed". That was incredibly frustrating to me. I figured that if I was getting frustrated, and I was the creator of the tests, then random users would be REALLY frustrated. So I added in JSLint. Now you get line an…
My C++ brain must be getting too old -- head is swimming :( From all the talk, these must be very useful, but I don't understand why? Why not just use an object?
(Also, you can use enclosed variables inside of map/fold constructs, which would be hard to express via objects.)
Anyone else try to do a lazy AND evaluation for chapter 12 and have it fail? I did fC(gC(function(){success,failure};),failure); but the desired answer checked gC even if fC already failed..
My first attempt was about the same, until I realized I missed a requirement: > Your function bothC should call both fC and gC no matter what What happens in your code if fC fails?
Wow, I love the flow! Except JSLint. JSLint barfs all over otherwise valid JavaScript and provides really unhelpful error messages. For a minute, I thought that I forgot how to write valid JavaScript.... Hate! Hate! Hate! You're teaching folks to program, not write syntactically pure JS. But drop that and the experience is great.
(Creator here) Ha, yeah JSLint really provokes strong emotions. Before I added in JSLint, if you misplaced one semicolon or forgot a parentheses, none of the tests would run and it would just say "program failed". That was incredibly frustrating to me. I figured that if I was getting frustrated, and I was the creator of the tests, then random users would be REALLY frustrated. So I added in JSLint. Now you get line an…
var f = function () { return 0 }
To understand the importance of closures it might be interesting to look at this poster[1]. Look at the node in the top left that says "Functional programming". Every paradigm that descends from that node depends on closures. THAT's how important they are.