"Pain Points" learning/working with JavaScript

So, yeah, one of my goals with my library is to encapsulate the baneful aspects and make programming IF in Javascript a pleasant, almost English-like, experience. It would be helpful to me to hear (on this thread or in a PM) about pain points when working with Javascript.

1 Like

I guess we’ve thoroughly derailed the thread now so I’ll put my JS grievances here.

There’s the usual stuff people dislike, like really weird type coercion. But that stuff is pretty easily avoided, if inconvenient, IMO. And the fact that it’s weakly typed, but I find that more convenient than inconvenient. Values have types, not variables… works for me.

The pain points to me are that they keep piling new syntax onto the language to deal with old problems. Magical, non-lexical this? We’ll address it with new fat-arrow syntax. People want classes? Address it with new class syntax. Promises are a pain? Let’s add async/await. And coroutines are great too (they are), so we’ll add new syntax for that too (wait, why?). And everyone needs template strings, right? It just feels like new syntax overload.

A lot of this stuff could have been done with existing syntax, is all I’m saying. IMO Lua is a fairly similar language that got almost all this stuff right… implicit type coercion, but not too crazy. Coroutines, without special syntax. No pre-existing members in the basic “object” construction. Prototype based inheritance with no need for classes; can whip up a decent class implementation in about 10 LOC.

I don’t think any of that stuff should affect a decent JS library, really.

On a side note, I think you guys are on the right track with the graph stuff. In my own pet project, keeping the entire game state in what’s essentially a tuplestore made it super easy to save and load games (~13 LOC each for save/load functions). And as far as I can tell, pretty much all the game logic can be done by querying the tuplestore and inserting/removing tuples.

1 Like

My reason for wanting to learn JS is that the newest version of AXMA Story Maker is pure JS and can take advantage of it. Unfortunately, none of the original “rustic Twine” style syntax with variables and counters and all that good interactive fiction-y stuff I understand works the same, so I’m currently perched on the 6.1 outcropping like it’s WordStar for me. (WordStar was a word processor back in the day that people used well-past obsolescence since they had the keystroke syntax so ingrained in their heads they couldn’t bear to adjust to anything else.)

Also, AXMA is maintained by Russian developers and there currently is no documentation in English for the JS version. Probably if I buckled down and started perusing W3 JS tutorials or similar it would make more sense, but I’m more interested in learning the specific flavor ASM uses rather than absorbing a giant two-inch thick manual of stuff I might otherwise not really need.

Anytime anyone has ever tried to explain JS, I get hung up on the spindly brackets and what exactly a function is and how it fits into the other thing and interacts and…square pegs round holes…


This is interesting. Does this mean natural language programming is good, because it got you into programming when you otherwise wouldn’t have? Or is it bad, because getting comfortable with it kept you from learning more traditional languages?

This is sort of what I was wondering in the original thread, WRT whether it’s a good idea to start students out with natural language programming.

I guess no matter what you start out with, though, you’ll be “spoiled” by the good things and not really want to deal with other languages that don’t have those things. Maybe that means we start everyone off with something completely awful like COBOL, then they appreciate everything else?

1 Like

I started some kind of Khan Academy thing on Javascript, and I got to some point where there was some exercise that I think was supposed to be obvious and I couldn’t figure out, and then I stopped working on it.

One thing is that by that time I had put an hour or two into it, at least, and I couldn’t do anything yet. Had no idea about basic things like “If I write this code down somewhere what do I do with it that will make it do a thing,” let alone being able to actually do any thing that was interesting in any way. One nice thing about Inform and other DSLs is that you can type a couple of sentences, hit “Run,” and you have something you can do commands to. (One of the unfortunate things about the Inform 7 docs is that you don’t actually get the first codeable example until 3.1, though.) Though that may not be feasible for things that aren’t general purpose languages–still, I think it’d be good for teaching programming to get the learner to Creating A Thing That Does A Thing ASAP.

Anyhow, I used to do some BASIC and then Pascal and learned some LISP and maybe another language or two back in my youth, and I don’t think it’s super hard for me to learn if I’m motivated, but Inform 7 did a much better job of getting me into it than anything else I’ve tried lately, so I think I’m a point for natural language programming helping me get into programming rather than keeping me from learning other languages?

OK, now I really want to try teaching you JavaScript. :wink:

Yeah, I bounced off Lua pretty hard back around 2001 because of the 1-based arrays and the crippled string-matching and the way it sometimes collapses multiple return values. But I’ve been using it a lot lately and enjoying it a lot (partly due to the excellent design of https://love2d.org/, but mostly just due to Lua). It is so carefully and thoughtfully designed. I may not agree with all of their decisions, but I totally respect the amount of thought they put into them.

@bikibird I’m with @matt_weiner on the “have a system where people can get up and running super quickly” thing. If you can have a sandbox that people can try out in their browser, that can be a big win, especially if you can have some simple tutorial or prompts alongside to combat blank-page-syndrome.

So things like https://www.tryhaskell.org/ or the like. I tend to think that the content there is probably too math-y and abstract and ramps up too quickly for many people, but the presentation is great. And you don’t have to go to the length of recognizing when they’ve entered the final answer and moving on: in fact I think it’s better if you make them click a button or type nextLesson into the terminal or whatever. Then they have control over it and it doesn’t jump ahead with no way to get back if they get the right answer by mistake.

I have seen absolute beginners have trouble with fluent interfaces because they don’t have a clear grasp of what is in between the links of the chain. And the longer the chain the easier it is to lose track. So when writing tutorials for people with no coding experience whatsoever, I’d probably start by writing very short simple statements (like in the Plain English system), assigning a name to each result. Then ease in to the chaining. But I could easily be wrong about that: I don’t have much experience showing fluent interfaces to complete beginners.

This article, http://www.ifwiki.org/index.php/Inform_7_for_Programmers, was really helpful to me in understanding Inform7 from a programmer’s point of view.

I wonder if you just need to reverse engineer it to come up with “Javascript for IF authors”?

Your point about fluent interfaces is interesting. I’m a fan of them because of the way they can flatten out nested function calls and make code easier to read and understand.

Not that I’ve even started work on the IDE, but my vision is a graphical representation of the story graph (think Twine or Trizbort) coupled with a code window. You could add nodes to the graph with the mouse and this would show boilerplate code in the code window that you could edit. You could also create nodes by typing code in the window and submitting it to update the model. Everything will be browser based and you’ll be able to work in offline mode if you want.

Actually, there might be an “over the event horizon and back again” type moment: if the code one learns is so obscure that it has no analogue and you just have to straight learn it, that might actually be easier than bringing in preconceptions.

My dad took a course in COBOL when I was young and I went to the computer lab with him once, being interested in computers, and I remember being like what is this even FOR?

I think JS is decent but JS ecosystem is pure hell. If you don’t like plain JS, you can use preprocessors and libraries, write in Lua and compile that to JS… but somewhere down the line it collapses into installing 500 modules to make a button go “whoosh” on click and that’s a bit too crazy.

Hrm, ignore that. Now I think I was just trying to help people with a particularly badly-designed interface. I can’t remember what we were messing with, but it was nesting things like your lexicon.register.as so the object being passed around kept changing. Looking at, e.g., refly’s Cloak of Darkness example, I don’t think they would have had any trouble with something like that.

Edit: ah, man, I just realized how badly I phrased that. Not “nesting things (like yours) so” but “nesting (things like yours) so” It was taking things like your lexicon.register.at (which seems simple enough) and nesting those several deep, which got hard to follow.

Oi. This is why we don’t program in English. :stuck_out_tongue: Hmm. Are there natural languages that don’t allow for many ambiguities?

1 Like

Yes, yes it is. About a year ago, I wanted to upgrade my Javascript skills after having been away from it for several years. I thought I could shortcut things by learning to use some of the more popular libraries, but I discovered that learning the libraries were just about as difficult as learning Javascript properly and thoroughly.

A lot of these libraries exist to work around some missing functionality in Javascript. For example JQuery is pretty unnecessary these days as the DOM interface is now much more JQuery-like.

The other issue I had was that there was an awful lot of old code examples on the web that worked but, were overly complicated to make up for deficiencies in Javascript that existed at that time. Finding the simpler ES6 solutions was difficult and frustrating.

Hmm, I wonder if the formula for evaluating the friendliness of a given language is to compute the ratio of plain English keywords to punctuation?

I read between the lines and figured out what you meant. (i.e., I applied my personal biases to get the answer I wanted.)

Yeah, lexicon.register().as(), reads like a sentence and so I like it. It’s a way to provide named parameters. The other design choice I could have gone with was to supply to skip the .as() and pass in both parameters as members of an object: lexicon.register({lexeme:“ring”,definition:{your definition object here}}), which is also fairly clear in intention. The first flavor reads a little better, but writing a library in that style is a little more challenging than the second style.

It’s possible that the first style is more confusing because you are invoking two method calls to get one thing done. I waver back and forth on this.

Here my experience with JavaScript, in case it adds something.

Since we are talking about developing interactive fictions (and not something server-side with Node.js), I think it’s important also to have good notions of HTML and CSS since there are chances we will interact a lot with HTML elements on the page.

The first time I used JavaScript (2-3 years ago?) was with Vorple. Because it’s the Inform story that tells when to execute JavaScript commands, you don’t have to mess with the convoluted JS ecosystem (libraries, ES6 syntax, webpack and such…). You kind of have an easy playground (the Inform story). And since Vorple uses JQuery, it’s quite easy to interact with the webpage.

In a couple of days, I had an animated title, fading in and out between scenes… It was cool because you could directly have a concrete result, which you don’t if you learn JS in a “regular” way.

Today, while I’m far from being a profesionnal, I can mess with “advanced” things like the Node.js ecosystem, Electron, webpack, libraries such as Vue…

But keep in mind that I have a science background and that I had already used other languages (Python, HTML/CSS…) so it may not be as easy as I seem to imply.

But still, I think Vorple is a great entry point into the world of JavaScript if you already know Inform. I recommend to learn the basics of HTML, CSS and JavaScript (variables, functions, types…), to look inside Vorple extensions to see how it does some effects and search on the web how to do specific tasks related to your story with JQuery (shaking some words, fading elements, changing the background of the page…). Just write a game that’s only a pretext to make words fly on the screen!

Depends how “natural” you consider Lojban!

While we are at it, there’s also Ithkuil, which allow virtually no ambiguities. (But is a constructed language natural?) I don’t know how it would fare as a programming language, though. Likely not very well. :stuck_out_tongue: