what do yall think of a "universal koth language". simple to learn, interfaces with python, js, and jvm, has common functions found in koth, maybe a simple controller skeleton people can build on it...
was just talking with lyxal about his blog post and hit upon the idea that cgcc langs dont necessarily have to be for cg
Would be an interesting idea, but I think something like RTO's KotH tools, which just run the different languages and let them interface, would work better
I think Nathan Merrill made a package for Java attempting to do this, but a language/interface could be interesting if it works for multiple languages.
I mean, that seems like it has the exact same problem as just using JS/Python/Java in the first place. If you don't know Elm, it adds a big entry barrier.
No language is just "easy to learn" out of the box, and lots more people have JS/Python experience than Elm experience or experience with similar languages
I have considered making a KoTH in such a way where it's literally a "fill-in-the-blanks" where each person creates a few pieces of logic or takes them from other posts and doesn't need a framework.
@RadvylfPrograms Elm makes writing code for the handler simpler, because it has less syntax and error messages that help you when you do something illegal.
@RadvylfPrograms :61233552 It's actually designed to be similar to Javascript, but that's beyond the point. It's really easy to follow by example, you don't need to know the entire language and as I said several times the error messages are directed at helping beginners so if you make a mistake it's very likely the compiler will tell you exactly how to fix it.
@WheatWizard In theory yeah, but even though I know and have used Python, I've still caught myself not answering KotHs just because it's less convenient for me than JS.
I'm sure if I needed to use Elm for something I'd get used to it quickly, but just the fact that a KotH's in a language I don't know is often enough to keep me from answering it, even as a fan of KotHs
I'm saying that KotHs already have a higher entry barrier than other challenge types, and people don't like writing code in languages they're unfamiliar with, even if it's relatively easy to do so. Even I, as someone who likes KotHs more than average, often avoid writing KotHs submissions in languages I'm familiar with but don't use often.
I get that you apparently dislike Python. Cool. But I find it pretty straightforward, and even then I am discouraged from answering KotHs in it because it's not my primary language. Even more so with Java. I'm not saying anything about Python in particular, or Elm.
what do yall think of a "universal koth language". simple to learn, interfaces with python, js, and jvm, has common functions found in koth, maybe a simple controller skeleton people can build on it...
what do yall think of a "universal koth language". simple to learn, interfaces with python, js, and jvm, has common functions found in koth, maybe a simple controller skeleton people can build on it...
Yeah. Right now JS and Python mean most people can compete, but if ATO/RTO come out with a feature that allows multi-language KotHs, that will be the best option by far.
IMO having some framework that makes it equally easy to answer KOTHs in any of a number of languages is way better than trying to standardize any language for KOTHs, whether its elm, python, js, or something new
Well, for the RTO KotH tools, there will be a specific list of languages which it has a library with a nice interface for, and the rest will use a slightly less nice interface but would still be usable. Not sure exactly how it would look yet.
And on the bot's side, it'd be a function/method that takes some information about the turn, then returns what it wants to do. Java ones could store state in a class, JS ones could have a state object passed, etc.
The thing about DSLs are that they contain nothing more than is required for the domain given. A good DSL can be understood in a minute or two, and will naturally point you in the direction of the answer. Even when you use JS you have to engage with a sort of DSL: the interface, the interface has to be explained and understood. This is a barrier that pretty much cannot be eliminated, some understanding has to be made. A true DSL lowers this barrier by just being an interface without all the extra stuff required to be a valid JS library. But true DSLs have some draw backs. They have to …
"Incurious" isn't really a good description. I'm not answering because I'm "curious" about the actual process of answering, but because I want to be able to compete. Doesn't matter how much any of us dislike that people don't answer KotHs in languages they're unfamiliar with, it happens and entry barrier is quite often the difference between 1 or 2 and 40 answers.
The reality is that there are always people who cannot compete. There is no language everyone knows. And I think the best approach is not to pick the language the most people know, but rather to pick the language which has the lowest worst case barrier for entry.
There's also a third option nobody's brought up yet, which is languages where JS/Python/Java are used, but the OP offers to translate any bots submitted in other languages.
5
That's the strategy that's been used in my most successful KotH, and a lot of other popular ones.
We also might have different goals. I'm perfectly content with 5 good answers. After 10 answers I generally feel like koths have rapidly diminishing returns.
@WheatWizard Relating to your earlier point, I think it's very easy to understand enough of pretty much any language to make something like a KoTH bot.
It depends a lot. Sometimes the early answers are all really simple and the complexity evolves over time. Other times they do just decrease in quality, but that's a problem with the skill ceiling of that particular KotH IMO.
@WheatWizard Its always good to come back, I might actually stay active this time lol. But ik that a lot changed with the community so it will be a bit bittersweet since a lot of the community i knew is gone
And a good controller will have lots of added complexity. As in, hours spent getting the logging fine-tuned to be useful for testing bots, graphical controllers, balancing things and making sure the controller isn't biased to prefer certain bots.
Yes, but they usually aren't super heavy on the technical side of things (from what I have seen). Big and complex, but not groundbreaking. Maybe that's just my limited experience I have so far.
To me, it feels like there are a few levels of bots: 1. Trivial bots with very simple behavior 2. Bots which have simple logic but usually ignore competitors 3. Bots with more complex logic designed to beat the competition while still relying on basic info (most "good" bots) 4. Bots which predict the moves of their opponents (sometimes banned) 5. Bots which directly mess with other bots or the controller (almost always banned)
There's nothing wrong with a koth only allowing a single language, especially one as widely spread as JavaScript. Rather than ambiguously "converting" answers to JavaScript (presumably yourself and by hand) you should simply limit the challenge to JS only. We've had plenty of Java-only and Python-only koths in the past, after all. — MayubeAug 8, 2018 at 14:23
I like the game theory koths a lot more than the "complex koths". A lot of them are definitely too simple, but the "complex koths" are just boring to me.
Comparing King of the Ziggurat, King of the Holster, Gold Collector, and (say) the XKCD one, all of them rely on game theory, just to different extents. For all of them, there could be bots up to the level of #4 (although that was banned in some) and the higher level the bot, the better (usually).
i've never really tried a complex koth myself but a lot of that's because there's a lot to implement and it's hard to think about what you're actually doing with any of that
Sorry I never finished responding to this. "Doesn't matter how much any of us dislike that people don't answer KotHs in languages they're unfamiliar with" seems to be very fundamentally missing the point here. The point is that there are always going to be people turned away by the entry barrier, and so the goal is to minimize that entry barrier for as much of the population as possible. There are two ways to do that, choose a large segment of the population e.g. JS programmers and make their barrier as low as possible which you are suggesting or as I am suggesting lower the barrier as lo…
Honestly KotH are such hard challenges to run. if you have a complex idea for a KotH you just end up with very few answers because it takes hours to develop even a basic bot.
i feel like it is actually a good metric of how far along a koth is because it's not really worth doing until you've already got existing bots worth playing around
@RadvylfPrograms I chose my words carefully, and I suggest reading them carefully. Knowing Js and being "significantly more comfortable answering in JS over other options" are not the same thing.
There's definitely selection bias at play too because existing koths cater towards users who are "significantly more comfortable answering in JS over other options".
js has a shit ton of weird quirks and python is less than ideal for other reasons so if there's going to be any serious consideration of koth language something like elm really does make the most sense
@RadvylfPrograms If you have time to answer one of two KotHs, would you prefer to answer one where you are comfortable with the language or one where you are just passably comfortable? most people would trend towards the language they are most comfortable right?
@RadvylfPrograms Well that's the point of inflection. How many (and what) users are you going to lose because they can't program in JS. These are the people who are significantly more comfortable in JS. I write JS professionally but I don't really prefer JS over other options. It's unlikely that switching to or from JS is really going to make much of a difference to me.
And the other factor is who are you going to gain because they are willing to try X (DSL, Elm, Lua etc.) instead of JS. These are the two factors, that are being weighed.
@RadvylfPrograms Elm doesn't like recursion and generally is rather uptight about when you are allowed to recurse. Most looping is done with helper functions not raw recursion.
Also fwiw Elm has easy interop with JS so if the koth is in Elm you can literally just write JS.
@WheatWizard I think you've made some good points. Not going to go fully centrist on the issue, but y'all have shown me some of my pro-JS/Python-KotH biases.
@UnrelatedString But...why would anyone new to JS be writing Array(31).fill(0) in the first place? And what's the weird edge case in that situation?
The thing about DSLs are that they contain nothing more than is required for the domain given. A good DSL can be understood in a minute or two, and will naturally point you in the direction of the answer. Even when you use JS you have to engage with a sort of DSL: the interface, the interface has to be explained and understood. This is a barrier that pretty much cannot be eliminated, some understanding has to be made. A true DSL lowers this barrier by just being an interface without all the extra stuff required to be a valid JS library. But true DSLs have some draw backs. They have to …
@RadvylfPrograms I will say likewise, that the more I consider it the more I feel that there might be more a case by case basis. JS has benefits of course, and I think for some koths it might be better to go with JS.
@RadvylfPrograms it seemed like the easiest way to initialize an array with 31 zeroes and the previous bot i wrote i think i treated an array like a dict instead and some of the mapping or reduce operations were weird on it
i suppose the implicit qualifier on that sentence was "languages that arent complete tarpits", as all the features of most tarpits do exactly what you expect, by virtue of all features being incredibly simple
Not that anyone was saying this but it does often bother me when programmers say stuff like: "Every language has flaws it's really about the right tool for the job", which is kind of obviously true, but leads to this implication that all languages are equally good. And it sort of ends up as a thought terminating cliche where nothing about language design really matters.
@WheatWizard I don't see what's wrong with saying that. Obviously, every language has its own specialty. JS is good for web stuff and lots of other stuff, C is good for number-crunching and lots of other stuff, and brainfuck is good for fucking up your brain :P
As I said it is obviously true that no language is the right tool for every job. However it is not true that every language is the right tool for some job. It's a way to weasel out of uncomfortable criticism without having to really engage thoughtfully.
brainfuck is the best choice for messing up your brain moderately. Malbolge is the best choice for more severe, semi-permanent brain damage. Assembly is what you want for causing someone excruciating pain and permanent brain damage
Joking aside, I agree with you, but I do think it's not just a way to weasel out of uncomfortable criticism. I've seen a lot of people bash Python for being slow despite it not being built for that in mind
@user I think that what really is important is to get past "bashing". There shouldn't be teams here. At one extreme if someone says "you should never use Python because it's slow" that's dumb and should be discarded, speed isn't always a big concern. However Python is used in a lot of ways and being aware that there's a tradeoff or that other similar languages are a lot faster is useful. The Python designers chose to not make speed a priority and they have to live with that choice.
What's really important is principled discussion where people are willing to say that some things could be improved or that some compromises are worth it in some cases. Unfortunately mostly people just try to sort languages into two buckets called "good" and "bad", with utmost importance placed upon the first programming language you learned ending up in that good bucket.
