Would love to hear any comments. Does anyone think is a good idea having a programming language/environment composed of these parts?

Sure! Does it matter to you that it seems like an environment designed specifically for turn-based games seems to be baked into its assumptions? Or would you bring more of the OS glue into the description? FWIW, I enjoyed Krouse's episode on state charts, which I think you'd find interesting if you haven't heard it: https://futureofcoding.org/episodes/025

I am very interested in the subject of minimal notation to implement a particular set of problems, and have studied TicTacToe in depth. I suggest you look at my Beads version. It is a graphical version not merely a disembodied logic system, with your same logic fused with the need to subdivide the screen into subregions, size the letters, draw messages announcing whose turn it is. These are the realities of an actual implementation. Way too easy just to skip over the graphic parts. In most of my products the drawing section of the code exceeds the logic section, which is actually the easy part. Note that the term "row", "diagonal" "column", would have to be explained to the computer more specifically. In my spec i call for the winning 3 in a row(s) to be highlighted (note that it is possible to have 2 winning paths at once). I would wager a reasonable sum that my implementation is within 20% of the theoretical minimum. Here is a link to the code and the spec: https://github.com/magicmouse/beads-examples/tree/master/Example%20-%20Tic-Tac-Toe Since TicTacToe is only a problem of perhaps only 500 words, the difference between implementations in various languages is fairly small, although you would be surprised at how tricky making it fit on portrait and landscape screens nicely is in many languages. Since CSS and HTML are crippled languages and have no IF statements it makes it hard to do in vanilla JS. Fixed coordinates are so 1980's, so expect that your implementation has to contend with display aspect ratios sensibly. But even with these requirements, most languages can do this problem pretty well. I would be curious to see someone else's implementation of the same spec. Too often people change the program, so you can't do an apples-to-apples comparison. Chess is a more challenging case, as it is around 1500 words to implement, about 3 times the length of TTT. You could add to the tictactoe problem an extra feature that you want the proportion of possible futures of win/draw/lose for each possible move on a turn. there are only 9! possible games, and since the first move can only be one of 3 types, it is really 3 x 8! which is not a big number. That is a fascinating wrinkle to the game that takes this from a trivial program to something even harder than chess. And speaking of chess, there is a maniac programmer named Toledo who has the shortest chess program possible, an insanely devious and compact implementation that is baffling.

I also took a mostly declarative approach with my TicTacToe. Take a look at http://tiny.cc/z3hxdz. It's just over 316 words by MS Word's count and 103 lines. I'm still designing the language, so no implementation yet.

Then it's fun to add AI.

Makes sense to me, @Daniel Garcia. It's certainly following in some big footsteps, so it's unlikely to have fundamental issues. For example, I am hazily reminded of some Eve prototypes that had similar structure. Your diagram would benefit from tastefully naming some nodes in the graph to make it more digestible. (This idea is from Pane.)

@Dan Swirsky I believe you have a bug in your drawing code, the dividing lines of the tictactoe grid are usually thinner than the cell size, you have them computed at the same width of 0.167, which would look odd: Local.numWidthOfGrid = (Local.numColumn * .167) + ((Local.numColumn – 1) * .167). The grid lines should be thinner. Also, the test for a winning move should not be repeated in the code. The tracking for an object seems somewhat disconnected from the drawing; that could raise problems as the programs get larger.

yeah @alltom this is just a rough idea, I’m not sure of what are the limitations of it. Do you have in the top of your mind programs that might be really hard to write with these constructs?

You already have the names! I just meant you could have two nodes called

endGameScreen

so you don't have those arrows going back from right to left.

@Edward de Jong / Beads Project That's certainly the biggest drawback of designing a language and writing programs using it before there's an implementation that can run it. You can't easily catch bugs.

@Dan Swirsky I also think that prefixing the data type of each variable name is wasteful. In the original Win32 programming days, when Simonyi's "hungarian notation" was the rage in the windows programming world, one would prefix with one or 2 letters to hint at the data type. But nowadays with strongly typed languages, having to repeat the data type over and over is a clumsy approach. Some languages are taking the approach of trying to infer the type from the usage, but there's nothing wrong with having the user declare the type somewhere at the top.

@Edward de Jong / Beads Project I should mention that I am concurrently designing for my PL a structure editor for tablets where the on-screen keyboard is only used when first assigning a name to an object definition (names of attributes/properties are predefined) and when entering literal values. Also, since the object type is specified when defining an object, the prefix is automatically added. Thus, there is no keyboard entry penalty for prefixing. Furthermore, as my PL will come with its own IDE, the programmer will have the option to hide such prefixes if he's terribly offended. In any event, I find that it increases readability, so I'm not convinced that the final verdict on prefix typing has been issued, just as it hasn't for static vs. dynamic typing, oo vs. fp, etc.