Frustrations of Wikitext from a Software Dev

If that widget did not exist, BASIC Anywhere Machine would cease to work.

You’ll get to where you want to be much quicker if you lose your expectations. A small amount of the baggage you carry might be useful, but much of it you need to toss.

That worked for me. It will work for you. Be as water, not as rock.

Aside: documentation and the community refer to the language of TiddlyWiki as “WikiText”. I loathe that moniker. I much prefer “TwScript”. To me, “WikiText” is the markdown language of TiddlyWiki, that makes things bold/underline/italic/etc.

Loads of words tossed around that aren’t necessarily universally appealing from a semantics/cognitive perspective.

For what it’s worth, tiddlywiki didn’t invent the term wikitext, mediawiki did: Help:Wikitext - Wikipedia

Yeah, that’s largely what I consider to be WikiText. The other parts of what folk call TiddlyWiki’s “WikiText” I don’t call WikiText. I call TwScript and TwQL, Pragmas, and Controls (i.e. the GUI objects like buttons etc.).

Something like that. The categories help with my understanding of TiddlyWiki.

3 Likes

Side note: It is easy to say “someone ought to” but… someone ought to make an introductory writeup about these things, specifically addressing developers. I’m personally not qualified to do it (I’m not a developer) but from this discussion it seems that many developers (most? just a few?) come with a different frame of reference and false assumptions.

Consider that sw developers are, potentially, among the most important people we can get as community members.

1 Like

Where I was wrong about macros, is because the macros in TW don’t exist as preprocessor macros, but are something more live. I feel kind of dumb for not realizing that. I do notice, that for the most part that one sentence was the only thing actually addressed.

I’m not sure anybody mentioned it in this thread: Probably in the very next update to TW there will be new mechanisms that make macros much more similar to functions.

1 Like

Oh heck no, I don’t see it as you being wrong.

More lead astray by both from-experience-preconception of “macro” and documentation that isn’t quite as clear as it could be. (That’s the nature of documentation: not an easy thing to do.)

That’s the problem with words. They often already have a meaning in a certain context. To reuse the same words to mean something else in a different context, that gets confusing.

Like the word “widget”. Totally throws me off my game. So I don’t use that word anymore.

Instead: “GUI Controls” (or “Controls” for short) and TwScript. I need my tidy groupings…

1 Like

macros & recursion are what I meant, but you make good points.

Is it the same way the JS Macros work?

I think macros were probably misnamed in TW5. The idea was to match the usage in Excel, Word etc., but I think it has probably given rise to more confusion for developers familiar with macro preprocessors in programming languages.

5 Likes

Now I really wish I spoke Chinese! Many of these topics are things I still struggle with.

Using google translate, it’s like a Chinese version of grok. Though the plugin development page is better than any English one lol

1 Like

I think several of us recognize this. We just haven’t figured out how to get beyond it.

And it is improving. But I’m hoping to capture the learning experience well enough that I might be able to smooth the way for other developers trying to learn.

Easier said than done, even if well-supplied with Zen and Taoist koans. :wink:

But I’m working on it!

Zen, Taoist Koans, Yoda…:

  • Do or do not. There is no try.
  • You must unlearn what you have learned.
  • Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.
  • The greatest teacher, failure is.

Giggles aside:

Before attempting to create solutions to problems in TiddlyWiki, it is very good to get familiar with each piece individually. Understand how each piece behaves.

I’ve had better luck knowing the inventory of pieces via the documentation, and then tossing the documentation aside when understanding those pieces and how they behave.

Also, better to not relate the pieces and the words in the documentation to nothing you’ve seen/experienced before. No preconceived notions or expectations. Total naivete except for very generic analytical and problem-solving skills.

Often, documentation is like the game of everybody in a circle, whispering into the ear of the next person some story. By the time the end of the circle is reached, the final story doesn’t quite match up right with the beginning story.

2 Likes

This is something frustrating to me too.
I think the fact macros don’t behave like functions, is unintuitive and error-prone.
(And as GameDungeon, I am not thinking about something with the ability to run arbitrary JS code when I think of functions, I am just thinking about the way it deals with parameters and return value)

I also have difficulties with all the different ways to access variables or arguments or stuffs (&&, <>, __, …) and dealing with quotations, spaces, concatenation of string, etc…

There are probably good reasons for all of these, and probably a big part of my difficulties is that I still don’t grasp it well, but it is still, for me, unintuitive and error-prone (and also quite verbose), and the worst part of an otherwise amazing software.

Where tiddlywikis architecture is difficult for programmer’s to come to terms with, I believe it is much easier for non-programmer’s to come to terms with tiddlywiki than most program languages.

I sort of don’t believe it. I think dealing with wikitext/macro/widget, etc… is quite technical.

(This is just a feedback about how this part feel to me, I am not saying it should change, I really don’t understand it well enough to have any advice)

2 Likes

The problem is we all come to it with our own backgrounds, there are multiple entry points and perspectives. It is hard to imagine the naïve perspective and quantify the learning journey. But we can always help with documentation and improvements.

My key argument is as a programmer, Software Dev, you may have to “unlearn somethings” before you “learn others” :nerd_face: My procedural programming experience certainly caused some difficulties for me.

To me it seems there is divide here between “modern” (i.e. younger) programmers and older programmers. TiddlyWikis macro system is not so different to C/C++ #define preprocessor macros.

Case in point:

Like C #define macros, TiddlyWiki macros are not functions. Said another way, it’s usually a mistake to confuse similarity in syntax with intentions and purpose.

I’ve been hearing this anecdotally since I got more seriously involved with TW. I know of no hard evidence. But I mostly do believe it. I remember when Markdown was first starting to spread. Those who knew HTML seemed to have a harder time learning it than those who didn’t: “Where’s the nesting?!”

So I can easily believe that we programmers simply have more to unlearn. I would guess that part of it is that we have learned to expect great things from our tools, and we expect our tools to be flexible, but mostly in certain specific ways. TW may be flexible in others that we haven’t yet considered.

Unfortunately, this barely alleviates the frustration of not learning as fast as we would like.

Personally I have not had much trouble finding equivalents in wiki text for things I know in programming, some years ago I even wrote some documentation such as addressing sequence, iteration, selection and recursion in tiddlywiki.

  • Where I have had difficulty is accommodating various little quirks that complicate and break otherwise resonable assumptions.
  • Many of these have being improved with the evolution of tiddlywiki but I suspect still too many remain, for which I know understand, but will cause new users to stumble.

Just having a code highlighter that respected all html/tiddlywiki open and close tags would halve the syntax errors I have to deal with.

1 Like

In Tiddlywiki 5.3.0 this can be implemented using the recursive functions as below

\define m(n1:0 n2 sep:" ")
<<__n1__>><<__sep__>>
<$let n1={{{ [<__n1__>match[0]then[1]else<__n1__>] }}}>
  <$let n1={{{ [<n1>add<__n2__>] }}}>
    <$list filter="[<n1>subtract[1000]sign[]match[-1]]">
      <$macrocall $name=m n1=<<n1>> n2=<<__n1__>> sep=<<__sep__>> />
    </$list>
  </$let>
<$let>
\end

\function .fib(n1:0, n2) 
[<n1>match[0]then[1]else<n1>]:map[<currentTiddler>add<n2>]
:filter[<currentTiddler>subtract[1000]sign[]match[-1]]
:map[.fib<currentTiddler>,<n1>]
:else[<n1>]
\end

<<.fib>>

<<m>>

produces

987

0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987

The recursive function generates the last number of sequence, while the m macro by @pmario produces the whole sequence. I think the reduce and accumulator may help here, but I think the code gets more complex.

1 Like