After ZX Spectrum Basic, Icon is the first programming language I learned once I had a PC. It's extremely good for learning event based programming and the basic principles of UI programming, as nothing gets in your way and is baked in. The syntax is also a good stepping stone to many other languages. When you're a teenager and your first self taught program in a language is an image editing GUI to build HTML image maps that says a lot about the language design and ease of use! https://gist.github.com/MattOates/076c85498232465388a39e7efc...
Every time I use generator functions in Python I wonder how many people realise this is a poor mans Icon.
It's worth pointing out that Unicon is where all the Icon development happens as OSS now. The current implementation can almost certainly still run my 19 year old program linked. http://unicon.org/
The 'Graphics Programming in Icon' book is also a gem (available for free here [0]). It's written in the same (readable) form and style as the other books, and uses the added power of Icon to demonstrate how quick you can get going (take a look at their L-systems demo). There's also information on UI design.
I remember a whole library with demo programs was available with the interpreter. It included a 'caricature generator' you should check out if you can find it back, that was fun.
Apart from that, there's a treasure trove of information available in articles and newsletters (The Icon Analyst [1], and The Icon Newsletter [2]), which are filled with little projects that please the mind.
The "everyone gets a stack" implementation feels awkward and limiting.
One of the first non-trivial simulators that I wrote was an implementation of Icon's control structures using heap-allocated frames.
While heap allocating a frame is more expensive than incrementing/decrementing a stack pointer, managing lots of heap-allocated execution contexts is faster than managing lots of execution stacks, especially in a 32 bit world.
It had an ordinary stack for each thread, which was used mainly for running libc stuff.
Icon is a fantastic programming language. It's... a lot like jq, actually, though both are independently developed, and Stephen Dolan never knew about Icon when he wrote jq.
The primary characteristic of both is that they have pervasive backtracking. The primary difference is that jq is built around a concept of immutable, copy-on-write data types. Well, the syntax is also radically different, but that's less interesting to me.
Anyways, I'm very fond of Icon, and I miss writing code in it. It really feels like a language that could have been a much better Python or Perl N. There was an effort to make it so called Unicon, but it never really took off.
Thank you for the info on jq. I had seen it before, but I dismissed it as a "grep for JSON" kind of thing, and I don't do a lot of JSON. Hearing it's got more in common with Icon, I'll have to give it another look.
Icon was the first language I really got enamored with. I took two classes from Ralph Griswold, and generators, backtracking, and string scanning made for really pretty algorithms. Python has /almost/ caught up to the expressiveness that Icon had in the late 80s / early 90s.
Generators and backtracking are even more pervasive in jq than in Icon because jq evaluates all generators fully, even conditional expressions. You have to use the first() -or related- functions to limit evaluation of generators. Whereas in Icon conditionals are always limited to the first value, and you have to use the `every` keyword to evaluate generators fully.
To me, Icon and jq are kindred spirits, even though they have nothing in common in terms of lineage.
I agree strongly on the it could (and should) have been a better Python or Perl. A lot of the reasons I like Raku (previously Perl 6) is that it's adopted a lot of the philosophy of Icon possibly accidentally.
I found SNOBOL a lot harder to work with than Icon. Icon is an Algol-like language in that it has the usual flow control mechanisms, enhanced with Icon's backtracking. SNOBOL is a lot more like assembly. So it's harder (for me) to read the basic control flow of a program.
I think SNOBOL predated the invention of structured programming, or at least Griswold wasn't aware of structured programming's advantages when he designed it.
Dr Christopher (Tools of Computing) wrote some docs on parsing that were interesting to me (first time I saw matrix multiplication used in computing first/follow, etc sets). I am pretty sure he used Icon, because it was my first exposure to that as well. I thought it was an interesting language at the time, but never did anything with it. Good grief that was closing in on 20 years ago... sigh.
Every time I use generator functions in Python I wonder how many people realise this is a poor mans Icon.
It's worth pointing out that Unicon is where all the Icon development happens as OSS now. The current implementation can almost certainly still run my 19 year old program linked. http://unicon.org/