Tinderbox Forum

Book recommendations for non-coders to understand Tinderbox code?

With 9.1 out, I am excited about the new capabilities to use/extend Tinderbox’s superpowers with functions, OSA: Javascript and Actionscript. However, being a non-coder, I often find myself stuck. The forum and of course, aTBRef and “The Tinderbox Way” are great, but I was curious to get the forum’s thoughts on some getting started books on “Coding for the non-Coder” that will help people like myself get started.

Understanding that one cannot learn coding from a book, nonetheless, for some, it is a good place to start in addition to learning by example.

It is not so much the “what” where I am getting stuck, rather more with the structure and which operators to use where. I do not think I am alone. Many here have a coding background and a WEALTH of experience I can certainly learn from.

Questions:
Which language is most similar to Tinderbox’s action code that would help me get started? Is there one?
I have heard from several forum members, if interested in OSA, then learning Javascript >> Actionscript would be the way to go. Is this a good start for a beginner book if I want to invest the time?

What would be one or two books that you would recommend and why?

I learn with examples, but a workbook or book as a guide is what I am looking for.
Thanks
Tom

1 Like

I don’t recommend books – the best way to learn to code is to code. Codeacademy, which is free with optional fee-based tiers, is the best deal and is all hands-on. It also has online documents available for reference.

The problem with most books are that they are usually organized by topic and can jump deep into concepts before you are ready for them. Coding books are good for reference – they suck at teaching practical method.

I’ve been writing code for decades, in multiple languages. Be aware that some elements of Tinderbox are “like C” (sort of), some elements are “like Javascript” (sort of), and some are specific to Tinderbox. But “what language is Tinderbox like” really doesn’t matter. Learning coding is not so much about learning syntax and form – it is about learning to think about problems and figuring out how to come up with logical steps to solve the problem.

For reference material – aTbRef is all you need. The entirety of Tinderbox’s action and export code is laid out there. But even if you memorize aTbRef you still need practice. Nothing replaces learn-by-doing when it comes to learning to code in any language. Just jump in and do it. If you fail (and you will over and over) then learn to walk through your logic to debug the code and figure out why it is not working. Ask questions – this entire forum is a mentorship, so use it – like. you already do.

Don’t waste your money on books. You can learn all of the Javascript language, or C+, or Pascal or whatever, as laid out in a book, and have no idea how to make things happen in that language or in Tinderbox. Don’t bother delving into “what language is Tinderbox like”, because it doesn’t matter. Tinderbox is Tinderbox – if that’s where you want to code, then learn its rules and methods by doing your experiments right within Tinderbox.

3 Likes

If a small group are interested in getting together and doing occasional zoom sessions where we take on a typical Tinderbox task (irrespective of the complication level, I’m just talking about typical things we non-coders might do for import/processing/export and so on of our content), and brainstorm/develop related problem-solving and approach skills, test each other, write snippets, share functions, and so on… I’m up for it.

3 Likes

If I could suggest a challenge. If you get a copy of the source Tinderbox document for aTbRef, and organize a group initiative to work through the export code in that document to see how and why it works, you will succeed in learning Tinderbox coding using a real-world example.

3 Likes

I’d also suggest that one simply studies and deconstructs the TBX files in all the videos. This should help. Now that action code support commenting, I’m adding more comments to the code.

What I have found helpful is to first ask and then answer these questions:

  1. “What exactly is it that I want done? What is the ultimate outcome needed? What do I want the output to look like?”
  2. “What data is needed to get that done?”
  3. “Where is that data in my file?” (Note: This is why I try to keep core data only in one place, easier to answer this question and not confuse Tinderbox).
  4. If the data is not in my file can I produce it from data that is in my file or do I need to create or go get new data?
  5. “What is the format of my data, e.g. list, set, dictionary, etc?”
  6. “Is the data in the right format that I need? If YES, great. If Not, how do I transform it?”
  7. “What do I need to do to create the output format I want” (this is where HTML and MD help?)"
2 Likes

I would second what @PaulWalters said. At the earliest possible stage, start writing toy code to do one thing, then add another thing, then another. This iterative approach is essential for learning and doing. Equally important, the debugging stage is always iterative, e.g. remove this line, add this bit of output, change this bit, until the bug goes away and you can zero in on the cause. For the same reason, it is useful to have some “sandbox” data that is simple to work on before you try to do something in earnest that might have consequences.

Syntax comes and goes, but the central ideas in procedural programming are constant and not particularly difficult.

Great suggestions by all; Here is my main meta takeaways so far:

Paul: Coding is really about Logical Thinking and Solving Problems. Learn by Example. Be concrete with your examples. Use ATBRef and ask the forum questions regularly when you get stuck. “Its all there” (love that quote btw)
Art: small group of Non-Coders for solving problems. Paul added: Start decoding export as a start.
MichaelB: Deconstructing sample Tinderbox files for example in the lessons would be helpful. Several starting question: What is it you want to do.
entropydave write toy (pseudo) code and start simply and add. Debug to learn. Understand why it works but also why it does not work.

To add to Paul’s suggestion: Export, Functions, Strings, Lists/Sets are bigger categories I will want to explore. What are common elements in each group. Where are my gaps. Which real world examples do i want to begin with?

Tom

1 Like