betaveros

I'm the author but not the OP. Thanks!

I'm not sure I follow the question about infix notation and precedence, but: Trains of identifiers like `a b c d e f g` are always parsed as `b`, `d`, `f` being infix binary operators; their precedences are looked up at runtime to decide how that expression evaluates. Explicit function calls and indexing always bind more tightly, and operands in those trains can contain either; an expression like `a(arg) b c(arg1, arg2) d e[i] f g[j:k]` has the same binary operators as before. But operators are only single identifiers and don't contain function calls, so `a b (c)` is still the binary operator `b` with arguments `a` and `(c)`.

"Sets" are just dictionaries with set elements as the keys and null as every value. This makes sense because you want testing for set membership to be fast like locating a key in a dictionary and because, like in Python, iterating over a dictionary iterates over its keys.

We also already have `.+` for prepending a list element to a list and `+.` for appending. (These are the analogues of Scala's `+:` and `:+`.)

This language isn't an attempt to solve Python's problems. At best it's an attempt to get around some minor speed bumps I personally experience when writing short Python scripts. I did not create this language with the expectation or hope that even a single other person in the world would want to learn it, much less become proficient. Clojure is a great language! It's just that I, personally, need more mental effort to translate thoughts to code using prefix notation and other aspects of Lisp syntax, and decided that reducing that kind of mental effort for myself was a goal of this language.

I like this idea. I think I've considered adding immutable variables, but haven't prioritized them because other things I wanted to work on have a better expressiveness or bug-catching ability to effort ratio. Plus I haven't thought of a good syntax for them. But I might eventually get around to it.

Author here. FWIW I 100% agree with your assessment. This would be a horrible choice for anything resembling production code and I hope nobody considers it. I'm not really even sure I'd recommend anybody other than me use the language for anything; there are a lot of decisions informed by how I, specifically, think about and write code. For me, this language works well when I want to write scripts that are <100 lines or so, and for that alone I think it's achieved its purpose. I think of it as a "home-cooked" programming language, a la <https://www.robinsloan.com/notes/home-cooked-app/>.

Hi, author here. I'll probably go into this in more detail in a blog post later, but the short reason for runtime precedences (briefly discussed much further down in the README) is that I wanted to be able to write chained comparisons like `x < y < z` without privileging comparison operators in the syntax, so `less_than := <; x less_than y less_than z` also has to work. This means that you can never resolve the structure of a chain of binary operators while parsing, so you have to wait until runtime. The fact that precedence is mutable at runtime is not at all important, but given the above decision, I thought I might as well go the full mile. (Also, it's funny :)

Looks like it was done twice in 2010 (https://www.go-hero.net/jam/10/languages/Piet) and once in 2015 (by me!) (https://www.go-hero.net/jam/15/languages/Piet)

I sorta cheated with an assembler (https://github.com/sl236/Piet) though.

For the lulz, I turned your code into one line with lambdas: https://gist.github.com/betaveros/1e76b3ca53001c8edcef

It takes quite a few more characters, but it was fun.

There was a Google Code Jam problem this year precisely about detecting the difference between the fair shuffle and the "terribly, terribly wrong" shuffle: https://code.google.com/codejam/contest/2984486/dashboard#s=...