…posted something really nasty about Ron Jeffries. I deleted it and asked him to moderate it.

My advice to him below is followed by his original comment underneath. I was amazed by it, and luckily, Ron is away, I think, so he won’t see it.

One to watch, I’m afraid.

Codeslinger - how would you feel if someone wrote about you like that? Even if you are correct, this barrage of insults makes you look like an immature jerk, and raises the question, how much do you know about this stuff, anyway?

Regardless, we don’t tolerate personal attacks on this forum. Moderate your comment or don’t make it.

I suggest you can get the same points across more effectively and less offensively, using the Socratic approach of asking dumb questions. He would start by saying “please forgive me asking, because I’m not an expert on this, but what happens if you put in + to start with?” And so on. Doing it the “please explain…” way is devastatingly effective, without the need to be nasty.

I’ve copied and pasted your original post below so you don’t lose the points you were making.

I’m doing this for your benefit, because I’m hoping you didn’t set out to be a deliberate jerk.

------------------- original comment -----------

A short essay going by the name

. . . . . PLUS THE PLUS PROBLEM . . . . .

in which I claim that Ron Jeffries:

  • uses lousy TDD
  • to create a bad calculator
  • should better be using BDD
  • excuses lack of design because of focus on tests
  • weighs in with his „authority“ to make it look good

Perhaps he’s doing this deliberately to show more interesting problems up front, but, alas, he then fails to step back and solve some basic ones.

Let me ask you:

  • What happens when you press + on a freshly started calculator?
  • What happens if you press + two times in a row in midst of a calculation?
  • Without looking at the code!

These are random questions, I’ve chosen them (and the headline) simply because the word PLUS appears several times in Ron’s article and it got stuck somehow.

Let me say that I’m not going to answer the above questions. I cannot answer them without looking at the code and even then it might take some time.

Let’s dive into the article

Ron is a proponent of TDD. He’s not saying so at the very beginning, which is perhaps a good thing, because he ignores the rule of „tiny steps“ and immediately dives in with a test where he wants to calculate “13*3=”.

What should he do true to TDD? Maybe turn the calculator on test that it shows “0”. At least that’s what I would expect from a common calculator. Oh, Ron’s calculator shows nothing? So be it, then test for an empty string. Why is Ron doing this? Well, it makes typing “13” into the caculator easier. If there’s already a “0” in the display you’ll have a special case.

Back to “13*3=” and how Ron is going to solve it. He’s got no program, so there will be a runtime error by Lua (good), then he creates a calculator skeleton that runs but fails its test (good).

In order to make the test pass, Ron changes the press function to accept everything.


I know that we’re not going to invent a key pad to protect the doors of Fort Knox, but at least a calculator that we can depend on. Ron’s claim seems to be that by further testing he will eliminate all bugs. I’m in doubt. Instead of allowing wanted functionality he allows everything and goes on to further single out some special cases. Yes, I know, in his article he thinks about limiting the display input to numbers, but when is he going to actually do this?

At this moment I can point you back to my original questions. Why is it difficult to answer them? Because Ron allows many things, then tries to limit the collateral damage. You don’t know what the calculator as a whole can do, you know that it’s got some special cases where it’s got some loosely defined functionality. It’s not the lack of tests that denies a clear answer (even if some kinds of test can definitely help), it’s the lack of “design”.

Tests and more tests

Ron writes some more tests. Ron gets annoyed by the underpowered test functions and combines them to make them more readable. Wow. Or less messy. The term “behavior” is lying around in the article, that’s the B of BDD. Why isn’t Ron using BDD then?

Time to explain.

TDD is - despite its name - not about tests. It’s about writing a specification and proving that the software fulfills it. The tests are the means to go this way. To avoid this confusion the term was changed to BDD, which essentially does the same and at the same time tries to get back your attention to another property of the underlying tests.

BDD proposes that you name your tests by describing the behavior.

function turning_on_the_calc_shows_nothing()
    local c = Calculator()
    -- A ronculator does not show 0. No no no. Don't you dare!

This is a test that I understand.

function no_leading_zeroes()
    local c = Calculator()
    -- single 0 is OK
    c:check("0", "0")
    -- no "00" in the display!
    c:check("0", "0")
The lack of what Ron calls “design”

Ron excuses the lack of “design” because of the focus on tests. The design will evolve nearly automatically. I say that Ron is denying a structured approach. I don’t say that TDD is bad, it is sometimes badly explained and in Ron’s case applied lousily. And please look at what BDD has to say about TDD. I don’t say that you cannot start with a simple design like Ron does, but please stay sane.

What Ron is doing is flailing around code patch after code patch which is absolutely necessary because he bombed away a wall and now needs to put bricks into place to repair the damage. That’s why you still don’t know if the + key is doing the right thing at all times. Yes, Ron is aware that there are problems and even names some of them, but with his “bombing technique” and opening up an endless gap, don’t you think it is difficult to come up with ideas of all (ALL!) problems that you now have to catch?

I have some strong opinions:

  • Ron is not a good teacher.
  • Ron is not a good programmer (and his article is at a basic skill level).
  • Ron favors tests above thinking (and know you know why I’ve put “design” in quotes several times).
  • This is not the writing of a man who claims to have soooooo much experience in this field.

Well, Codeslinger was always rather rude in his comments. Hence his avatar name?
Anyway I agree with your feelings and decision here, lets keep this place a gentleman’s one.
[edit] and i would love to read a tense debate between Codeslinger and Ron, provided he can refactor his text the way you suggested.
After all, this is exactly his point: Behavior Driven Design… That was a pretty bad behavior here, and he should redesign his post to fit the expected behavior. Lol.

I think it’s time to close the “Codea calculator” discussion and stop the arguments going on. Ron got his point in on how he thinks a program should be written and Codeslinger got his comment in, along with whoever else commented. A comment could be made at the end of it as to the reason and any continuation in another discussion will be deleted.

I’ve been chatting with Ron, and explained that Codeslinger is probably an over excited teenager, and not to take it personally.

My preference would be to keep the discussion going (with a tight leash on Codeslinger) because it is really interesting, and we’re only really getting started - but I did tell Ron what you thought.

So he will ask you if he wants it closed. Let’s keep it open until then.

I’m going to bed, so please keep an eye out for Codeslinger, and feel free to delete anything unkind!

I replied to Ron and Ignatz in a PM just in case anyone else is following this here. While there was a lot of information given in the beginning of the discussion on the steps to write a large program, what’s happening now is a discussion on trying to convince each other who’s right. No new information on writing code is being offered. I’m accepting Ignatz suggestion on keeping the discussion going for now.

let’s wait and see Ron’s answers. Although i dislike Codeslinger’s manners, i see the basline of his points, and, although i love new perspectives, i think Ron’s strong paradigms should be challenged. I wonder if complex programs can really be created this way… That was the hell of a long process just to get a non-working calculator… With all respect due to Ron!

What it comes down to is a complex program can be created any way you want to take the time to do it. Is there a perfect way, no. Are some ways better than others, yes. Every program has it’s own way of being written. Ron expressed his opinion on the way he does it, Codeslinger is expressing his opinion. I’m expressing mine, not on how a program should be written, but that the discussion isn’t going anywhere but inviting arguments in a way. I don’t have a problem with it continuing, but when someone’s post has to be censured, then maybe it’s time to move on. I don’t think any of the new coders or even some the experienced one really care. If they do, one of the books Ron mentioned is in a free PDF format of 460+ pages that they can read. I’ll go along with the majority about the discussion. I just thought it was heading in the wrong direction.

I agree with your conclusions. Lets keep an eye on this, in case it degenerates!

@dave1707 - @Jmv38 and I and a couple of others are still getting good value from the discussion, and I’m with Jmv in thinking I could code a working calculator in half the time. But I want to understand the approach because it is so widely used. So there is lots to discuss.

I don’t want one whiny kid to kill the whole conversation.

I just wasn’t sure about the direction of the post. As long as all of you think there’s value to it, then I’ll forget about it. I just wasn’t getting anything out of it and didn’t know if others were either. I just felt there was an argument building there.

Getting back to the original subject of this thread, I think Codeslinger can learn to be more polite, but he will probably need more guidance, and we need to watch him.

It seems that quite a bit of the mod work here is helping teenagers develop some maturity.