The 1970s saw the birth of many foundational algorithms and concepts in machine learning, with research focusing on decision tree algorithms, clustering, and ensemble methods. I believe one of the first decision tree algorithms was created in 1973, crazy how early it all started!
In the 80's I apprenticed under a greybeard programmer who gave me all the shitty network code to write, while he experimented with neural networks instead of writing "old school" error correction logic for said network code.
I'm grateful for his bikeshedding, because it made me a network programmer and led to a fine career building Internet service providers, but I'll never forget his frustration .. "the computer is simply not big enough, we need to build a bigger computer" .. I wonder where he is these days. Hopefully retired.
Ah, the memories of inputting listings from magazines and books like these, only to find that I’d have one character wrong and the whole thing would fail (and I didn’t know enough to fix it).
There was an article in 'The Rainbow' about the tic-tac-toe bead method of machine learning. For some reason, that particular method stuck in my head long after most other things I read in computer magazines of the time faded away. Maybe due to both the simplicity of tic-tac-toe and of the algorithm itself.
> As an aside, line 511 is entered when it fails to find matching values with the current game state for all 19 boards and flipped boards. It seems like it was originally intended to be a comment using the REM command like 511 REM REMEMBER THE TERMINATION OF THIS LOOP IS IMPOSSIBLE, but perhaps that part was omitted during editing, so it just starts with REMEMBER.
Actually, that line does start with "511 REM". There was no requirement for REM to be followed by a space.
So basically it has a table of all possible moves, and after losing a game, it deletes a move that led to the defeat? Then why not simply have a smaller table of moves right from the start, with losing moves already removed?
I would have previously agreed (that there is nothing quite like it these days) - but my son is now part of an online games coding club. They start off assembling ready made 'Scratch' instructions, and playing at tweaking them. In later lessons they then start to write their own Scratch recipes, before moving to Python libraries then writing Python directly.
So far I've been really impressed with the materials, then tutors and the games they've made.
For what he has learnt, and the support they also provide outside of the lessons, £50 a month feels pretty cheap.
Forgive me, but I don't think scratch is all that good - my son did it too. I never liked these super simplified approaches to computing because I don't think they are necessary. Scratch wouldnt be that useful in the 80s. BASIC, despite its flaws, was both simple and powerful. You could code in the same language as many pros from the get go.
"You can code in the same language as the pros" is a huge selling point. If you're a kid using a computer, you've seen off-the-shelf software and that's probably your inspiration. You want to be able to make standalone things that look and work like the ones you've used before, not "it only runs in this sandbox" toys. "Use the cool program I wrote, Dad" hits different when he can run it just like Excel and Firefox.
Yeah Scratch has a lot of limitations - but as an introduction to the concepts, it has been amazing. Watching him be able to build a game that he enjoyed on day one, then by maybe 6 lessons later to be using Python - has been great. I'm not a coder so it is not something I could help with (I play with Arduino etc. but I don't know python).
But getting the early simple lessons to explain how changing variables affects the game, and how to run things in sequence, has been really powerful for him.
You can learn a lot from Scratch, that's for sure. I'm not saying it's bad, it's actually a decent learning tool. But I think it's a step back from BASIC.
You could code a ton of fairly decent games, utilities and even full applications in BASIC. While that's theoretically possible in Scratch, it's a lot more cumbersome. Scratch feels more like a puzzle game than a real programming language. BASIC, especially the later, better dialects, could do it all. With 2 very understandable lines:
10 PRINT "glimshe rulez!"
20 GOTO 10
You could teach that the computer is under your command and you can ask it to do work for you nonstop. It teaches a bit of I/O, program sequence and loops. No stupid "main" functions, indentation nonsense, cryptic library includes or cumbersome drag-and-drop. The simplicity of the code above is one of the treasures of computing history. 90% or more of humanity can quickly understand these two lines and I super disagree with Dijkstra about BASIC.
It was at the same time a teaching tool and a professional programming language (although, arguably, not amazing at that).
Scratch is good for immediate feedback. I mentored some middle school students last year that learned Scratch in elementary. They've graduated to JavaScript and Python now. They built a bunch of simple—and super fun—games for a school project. Notepad.exe and a browser :)
Then you should check out Snap!, which is like Scratch without any of the limitations, essentially a visual programming language with the full power of Scheme.
>One of the coolest ways to learn programming I've ever seen is the Snap! visual programming language, which is written in JavaScript and runs in the browser. https://snap.berkeley.edu
>It's the culmination of years of work by Brian Harvey and Jens Mönig and other Smalltalk and education experts. It benefits from their experience and expert understanding about constructionist education, Smalltalk, Scratch, E-Toys, Lisp, Logo, Star Logo, and many other excellent systems.
>Snap! takes the best ideas, then freshly and coherently synthesizes them into a visual programming language that kids can use, but is also satisfying to professional programmers, with all the power of Scheme (lexical closures, special forms, macros, continuations, user defined functions and control structures), but deeply integrating and leveraging the web browser and the internet (JavaScript primitives, everything is a first class object, dynamically loaded extensions, etc).
>Alan Kay wrote some interesting stuff about some of the inspirations for "Tile-" and "Block-Based Programming", like "Thinkin' Things", in a discussion about the Snap! visual programming language!
https://snap.berkeley.edu
>From: Alan Kay Date: Thu, 3 May 2018 07:49:16 +0000 (UTC) Subject: Re: Blocky + Micropolis = Blockropolis! ;)
>Yes, all of these "blocks" editors sprouted from the original one I designed for Etoys* more than 20 years ago now -- most of the followup was by way of Jens Moenig -- who did SNAP. You can see Etoys demoed on the OLPC in my 2007 TED talk.
>I'd advise coming up with a special kid's oriented language for your SimCity/Metropolis system and then render it in "blocks".
>I'm also a huge fan of Snap!, which has all the advantages of Logo (Lisp without parenthesis) and Scratch / eToys / Squeak / App Inventor family of block based visual programming languages, but all the power of Scheme.
>If you know Scheme, then it's easy to think about Snap!: it's just Scheme with a visual block syntax, but with some functions renamed to make them easier to learn, plus all the stage and turtle graphics stuff from Scratch, running in a web browser!
>I didn't realize until watching in amazement as Jens Mönig used his own creation, that it also has full keyboard support, so you can create and edit programs without using the mouse!
>It's much easier to teach Scheme to kids by teaching them Snap!, because the user interface is so much better than a text editor.
No, that's not why. The comment you're replying to gave a different reason that it was done that way. That comment explained, twice, that it's not merely, or even primarily, to improve the game's playability; it was to serve as an executable demonstration of the matchbox learning algorithm.
The blog post explained that the game derived from Martin Gardner's popularization of Donald Michie's work on the algorithm.
The output of the program also outlines the algorithm, using a series of PRINT statements.
Finally, the explanatory text in the book also explains the algorithm, in somewhat more depth.
Like many of the games in the book, it had a didactic purpose. It's not about improving playability.
> Martin Gardner's popularization of Donald Michie's work on the algorithm.
I remember reading this, but for the life of me I can't recall what the title of the book was. ISTR it also had a chapter exploring multi-dimensional spaces, in particular the problem of packing hyperspheres into hypercubes.
this makes me want to rewrite the unbeatable tic tac toe algorithm I wrote back in high school so that instead of starting optimized it just walks through potential game states and eliminates them as it loses.
BTW David Ahl has placed all of his work, including this book, into the public domain https://blog.adafruit.com/2022/06/16/david-ahl-places-all-hi... and so we can link to the Hexapawn page in the original book https://dn790005.ca.archive.org/0/items/Basic_Computer_Games...
Unfortunately I do not know of an online source for the Korean edition that so inspired the original poster.
The 1970s saw the birth of many foundational algorithms and concepts in machine learning, with research focusing on decision tree algorithms, clustering, and ensemble methods. I believe one of the first decision tree algorithms was created in 1973, crazy how early it all started!
In the 80's I apprenticed under a greybeard programmer who gave me all the shitty network code to write, while he experimented with neural networks instead of writing "old school" error correction logic for said network code.
I'm grateful for his bikeshedding, because it made me a network programmer and led to a fine career building Internet service providers, but I'll never forget his frustration .. "the computer is simply not big enough, we need to build a bigger computer" .. I wonder where he is these days. Hopefully retired.
Ah, the memories of inputting listings from magazines and books like these, only to find that I’d have one character wrong and the whole thing would fail (and I didn’t know enough to fix it).
The vibe coding of its day! :D
I was a programmer a decade before my first Hello World!
Using Norton Utilities 1.0's hex editor to read and change save files for Moria :)
There was an article in 'The Rainbow' about the tic-tac-toe bead method of machine learning. For some reason, that particular method stuck in my head long after most other things I read in computer magazines of the time faded away. Maybe due to both the simplicity of tic-tac-toe and of the algorithm itself.
> As an aside, line 511 is entered when it fails to find matching values with the current game state for all 19 boards and flipped boards. It seems like it was originally intended to be a comment using the REM command like 511 REM REMEMBER THE TERMINATION OF THIS LOOP IS IMPOSSIBLE, but perhaps that part was omitted during editing, so it just starts with REMEMBER.
Actually, that line does start with "511 REM". There was no requirement for REM to be followed by a space.
I didn't realize that! Thanks for the clarification.
PDF of Gardner's Scientific American article on HEXAPAWN.
https://people.csail.mit.edu/brooks/idocs/GardnerHexapawn.pd...
Matt Parker did a video about a physical implementation of MENACE as part of a museum display for a day: https://www.youtube.com/watch?v=R9c-_neaxeU
So basically it has a table of all possible moves, and after losing a game, it deletes a move that led to the defeat? Then why not simply have a smaller table of moves right from the start, with losing moves already removed?
Because that wouldn't help readers understand how the computer learns with this simple algorithm.
People bought the book to not only play, but also learn from simple games. There's nothing quite like it nowadays.
I would have previously agreed (that there is nothing quite like it these days) - but my son is now part of an online games coding club. They start off assembling ready made 'Scratch' instructions, and playing at tweaking them. In later lessons they then start to write their own Scratch recipes, before moving to Python libraries then writing Python directly.
So far I've been really impressed with the materials, then tutors and the games they've made.
For what he has learnt, and the support they also provide outside of the lessons, £50 a month feels pretty cheap.
Forgive me, but I don't think scratch is all that good - my son did it too. I never liked these super simplified approaches to computing because I don't think they are necessary. Scratch wouldnt be that useful in the 80s. BASIC, despite its flaws, was both simple and powerful. You could code in the same language as many pros from the get go.
"You can code in the same language as the pros" is a huge selling point. If you're a kid using a computer, you've seen off-the-shelf software and that's probably your inspiration. You want to be able to make standalone things that look and work like the ones you've used before, not "it only runs in this sandbox" toys. "Use the cool program I wrote, Dad" hits different when he can run it just like Excel and Firefox.
Yeah Scratch has a lot of limitations - but as an introduction to the concepts, it has been amazing. Watching him be able to build a game that he enjoyed on day one, then by maybe 6 lessons later to be using Python - has been great. I'm not a coder so it is not something I could help with (I play with Arduino etc. but I don't know python).
But getting the early simple lessons to explain how changing variables affects the game, and how to run things in sequence, has been really powerful for him.
You can learn a lot from Scratch, that's for sure. I'm not saying it's bad, it's actually a decent learning tool. But I think it's a step back from BASIC.
You could code a ton of fairly decent games, utilities and even full applications in BASIC. While that's theoretically possible in Scratch, it's a lot more cumbersome. Scratch feels more like a puzzle game than a real programming language. BASIC, especially the later, better dialects, could do it all. With 2 very understandable lines:
10 PRINT "glimshe rulez!"
20 GOTO 10
You could teach that the computer is under your command and you can ask it to do work for you nonstop. It teaches a bit of I/O, program sequence and loops. No stupid "main" functions, indentation nonsense, cryptic library includes or cumbersome drag-and-drop. The simplicity of the code above is one of the treasures of computing history. 90% or more of humanity can quickly understand these two lines and I super disagree with Dijkstra about BASIC.
It was at the same time a teaching tool and a professional programming language (although, arguably, not amazing at that).
Scratch is good for immediate feedback. I mentored some middle school students last year that learned Scratch in elementary. They've graduated to JavaScript and Python now. They built a bunch of simple—and super fun—games for a school project. Notepad.exe and a browser :)
Then you should check out Snap!, which is like Scratch without any of the limitations, essentially a visual programming language with the full power of Scheme.
https://snap.berkeley.edu
Snap! 5 is here (snap.berkeley.edu):
https://news.ycombinator.com/item?id=20309162
>One of the coolest ways to learn programming I've ever seen is the Snap! visual programming language, which is written in JavaScript and runs in the browser. https://snap.berkeley.edu
>It's the culmination of years of work by Brian Harvey and Jens Mönig and other Smalltalk and education experts. It benefits from their experience and expert understanding about constructionist education, Smalltalk, Scratch, E-Toys, Lisp, Logo, Star Logo, and many other excellent systems.
>Snap! takes the best ideas, then freshly and coherently synthesizes them into a visual programming language that kids can use, but is also satisfying to professional programmers, with all the power of Scheme (lexical closures, special forms, macros, continuations, user defined functions and control structures), but deeply integrating and leveraging the web browser and the internet (JavaScript primitives, everything is a first class object, dynamically loaded extensions, etc).
https://news.ycombinator.com/item?id=18497883
>Alan Kay wrote some interesting stuff about some of the inspirations for "Tile-" and "Block-Based Programming", like "Thinkin' Things", in a discussion about the Snap! visual programming language! https://snap.berkeley.edu
>From: Alan Kay Date: Thu, 3 May 2018 07:49:16 +0000 (UTC) Subject: Re: Blocky + Micropolis = Blockropolis! ;)
>Yes, all of these "blocks" editors sprouted from the original one I designed for Etoys* more than 20 years ago now -- most of the followup was by way of Jens Moenig -- who did SNAP. You can see Etoys demoed on the OLPC in my 2007 TED talk.
>I'd advise coming up with a special kid's oriented language for your SimCity/Metropolis system and then render it in "blocks".
>Cheers
>Alan
https://news.ycombinator.com/item?id=38016554
>I'm also a huge fan of Snap!, which has all the advantages of Logo (Lisp without parenthesis) and Scratch / eToys / Squeak / App Inventor family of block based visual programming languages, but all the power of Scheme.
>If you know Scheme, then it's easy to think about Snap!: it's just Scheme with a visual block syntax, but with some functions renamed to make them easier to learn, plus all the stage and turtle graphics stuff from Scratch, running in a web browser!
>I didn't realize until watching in amazement as Jens Mönig used his own creation, that it also has full keyboard support, so you can create and edit programs without using the mouse!
>It's much easier to teach Scheme to kids by teaching them Snap!, because the user interface is so much better than a text editor.
OK, that makes sense - the game has a better playability if it starts on an average level and "learns" over time.
No, that's not why. The comment you're replying to gave a different reason that it was done that way. That comment explained, twice, that it's not merely, or even primarily, to improve the game's playability; it was to serve as an executable demonstration of the matchbox learning algorithm.
The blog post explained that the game derived from Martin Gardner's popularization of Donald Michie's work on the algorithm.
The output of the program also outlines the algorithm, using a series of PRINT statements.
Finally, the explanatory text in the book also explains the algorithm, in somewhat more depth.
Like many of the games in the book, it had a didactic purpose. It's not about improving playability.
> Martin Gardner's popularization of Donald Michie's work on the algorithm.
I remember reading this, but for the life of me I can't recall what the title of the book was. ISTR it also had a chapter exploring multi-dimensional spaces, in particular the problem of packing hyperspheres into hypercubes.
I can't keep his book titles straight.
How would it learn without playing against the person already?
It gives a sense of intelligence the way it’s played now but it’s a simple algorithm.
Eventually the computer runs out of things to remove and it has to give up.
this makes me want to rewrite the unbeatable tic tac toe algorithm I wrote back in high school so that instead of starting optimized it just walks through potential game states and eliminates them as it loses.
[dead]