For me it's "veteran" (those who saw the creation of the site), "old" (those from 2013/2014 onwards), "old-ish" (2015/2016), "same as me" (same as me), "new-ish" (a year or so after me) and "new" (within the last year)
But many "multiple times in the same language" answers on old challenges are by new users doing Python or JS (or whatever well-known language they know)
This would probably be significantly easier if such stats were more accessible but unfortunately everything's just in an answer and people are inconsistent with formatting :P
if submissions took like, language from a dropdown, byte count / a charset, code, and then explanations, it would make such stats a lot easier to go through :P
I've always found Arnauld's answers impressive, but I don't know JS enough to ever be properly "impressed" by them, beyond casual "ok, that's confusing. And, clever, I guess". I have (multiple times) seen an answer by Dennis, typically in Python/Jelly, and been genuinely speechless due to how clever the answer is
@rak1507 I can go looking for some. I generally only upvote answers if 1) they're on my challenges or 2) I find them genuinely impressive or 3) they're the same answer I would've posted
Chaining builtins together to solve a challenge isn't especially interesting, and, unfortunately, that's what a lot of challenges are in golfing languages. However, having the insight to recognize that an entirely different method is the best/shortest way is truly impressive
I generally don't give much of a crap about any answer that just does exactly what the challenge describes, including a lot of my own. The answers of mine I'm most proud of, and the answers I'll upvote the most, are those that properly find a creative, clever or "abusive" answer ("abusive" meaning that it "abuses" tricks/bugs/whatever in the language to be shorter)
I'm taking Human Geography and Computer Science Principles this year (9th grade), planning on taking AP tests for like 7 different subjects overall lol
My view is that golfing languages basically just abstract away some of the boring parts. You don't need to focus on spending 50 bytes on something like finding the nearest prime, you just let the golflang handle that and work on the interesting part
@RedwolfPrograms it might get one, if someone posts a goat-detection challenge (not just up vs down goats), and if the language author was still active
@RedwolfPrograms if you have a challenge that has two parts A and B, if they're builtins, the short way in a golflang will probably be to do A+B, but the short way in a regular language is almost certainly not A+B
'You don't need to focus on spending 50 bytes on something like finding the nearest prime' a golf lang has an easy way to do that for you, a regular language, you'd have to adapt the logic round the rest of your solution, which is fundamentally more interesting imo
@LilChartZ i think the perfect language for golfing should be popular (to encourage competition), stable (to prevent divisions based on version), not controlled by a codegolf user (to prevent adaptation to the popular style of challenges posted here), and maybe a bit verbose (to leave room for multiple steps of outgolfing and creativity in combining parts of the solution)
@ngn It's also one of those languages that, personally, makes me genuinely impressed. A lot of 05AB1E seems to be "push various stuff to the stack, and use the builtin that takes 15 inputs and produces the output". Husk is often "create an infinite list, find the first element where x". Jelly, even with it's often convenient builtins, always seems like more of an exercise in succinctly composing the perfect functions
@ngn Honestly, Jelly meets a lot of those. I dislike it's verbosity enough that I'm creating a "spin-off" that reallocated the builtins to have shorter more common ones
the problem with jelly's verbosity is usually it gets beaten on specific easy challenges by 05AB1E on the basis that the exact same approach is used but they have different allocations between 1- and 2-byte builtins lmao
@ngn I think a better approach than "isn't made by a code golfer" is "made with a general purpose usage in mind". Dennis used to use CJam for pretty much everything code based, and I believe he strove to make Jelly as general purpose as he could
The fact that the code page is supposed to be able to be typed, and the builtin allocation, makes me believe that Dennis 100% made Jelly to be more general purpose than most golfing langs, probably due to the amount he used CJam in non-code golf contexts
