Welcome to the first CGCC Blog post!
After 7 years, and three attempts, we've finally started a site blog, for posts and topics that the community here on CGCC is likely to find interesting. If you'd like to suggest topics, or would like to write a post about something specific, feel free to head over to our ideas thread and write up a suggestion!
Intially, the idea for a blog came about when Stack Exchange was promoting BlogOverflow back in 2014. Unfortunately, the idea "sort of just... stopped" and never came to fruition. 4 years ago, BlogOverflow stopped, right as there was renewed interest in having one, so we moved off-site for a while, before stagnating again. Finally, we decided to give it another shot, which is why you're reading this now!
If you'd like to see all the blog posts, check out the cgcc-blog tag - all the posts are collected there, and each post has that tag. If you'd like to check out our drafting and discussion room, feel free to drop by and ask any questions you have. For our very first post, we've decided to discuss whether golfing languages are good or bad for the site, a discussion which has been around since the creation of the site. Additionally, be sure to read until the end to see some underappreciated challenges, answers and languages.
Banning golfing languages has been an idea since the creation of the site, back when "golfing language" meant the clunky, outdated mess that is Golfscript and the general-purpose-but-short languages J and APL. The general idea behind the ban is that verbose languages such as Java are unable to compete with languages specially designed for golfing, so, in order to level the playing field, various different measures (handicaps, bans, language-specific competitions etc.) have been suggested.
So, are golfing languages good for the site?
In general, I disagree with these playing-field-leveling measures. Code Golf.SE has a principle of "Answers don't compete with all other answers, they compete with other answers in the same language". For example, a Java submission is only ever trying to beat the other Java submissions, rather than the Jelly answers. This is a good compromise of a policy, and I personally prefer it much more than sites that only allow specific languages. However, it can also feel a bit cheap or hand-wavy.
The thing I most enjoy about golfing languages is that they force you to think in completely different ways to regular languages. Their vast builtin libraries completely trivialise trivial problems - as they should. People complain that having a builtin to do something (for example, a builtin to calculate the dot product of two arrays) trivialises that task. That it isn't "real coding" to just copy-paste the
ḋ character instead of having to actually write your own method. However, I wholeheartedly believe that if a task can be trivialised in a golfing language, it's a trivial task in any language.
Golfing languages are interesting when the challenge is interesting. Generally speaking, the more interesting a challenge is, the more interesting the golfing language answer will be, because the approaches are going to be completely different. Using a golfing language allows you to abstract away a task until you can distil it into its core principles. And, often, this results in a trivial answer in a golfing language, because the core of the challenge is trivial, but this can only be realised through the level of abstraction available in golfing languages. For example, consider this Jelly answer to a challenge about the Padovan sequence. This sequence is similar to the Fibonacci sequence, and so most practical languages use this approach. However, this style of recursion is not always golfy in golfing languages, so it requires a fresh take and a new way to understand the task in order to create a competitive solution.
This is, in my opinion, the biggest argument for golfing languages. The obvious solution may not always be the shortest in every language, and by expanding the ways one can approach a problem (via expanding the builtins available), golfing languages are able to find more creative ways to answer. That's not to say that practical languages can't be interesting, but that the approaches in practical languages are limited by their builtin set.
Those who have been on the site for a while will know that answers (officially) compete only with other answers in the same language. That unfortunately isn't immediately obvious to new users. Posting a 200 byte Python answer when there's 10 bytes of strange unicode in first place is discouraging. Why bother, when you don't know any of the languages that are consistently at the top?
Golfing languages are also designed for one thing: golfing. In JS or Python, you'd have to balance the byte counts of potentially dozens of approaches to a part of a problem. You would need to take into account how changing the syntax in one place affects it in others. In Jelly or 05AB1E, many answers are just a few built-ins strung together.
Entire classes of challenges can be completely trivialized by golfing languages. Prime-related challenges, for example. While it costs you 30-40 bytes for a primality check in most practical languages, a golfing language can do that in a single byte. You could argue that these challenges are already trivial if they could be solved in a few bytes in a golfing language, but it could also be that golfing languages make a larger number of challenges count as trivial.
Overall, golfing languages can be discouraging to new users, and trivialize many problems.
Golfing languages have both good and bad impacts on the site as a whole. They can be discouraging to new users, who don't yet know the rules regarding competition between languages. Despite trivializing many challenges, it could be argued that these sorts of challenges are already quite trivial. And although they are often significantly shorter, golfing languages can still be difficult and interesting to golf in.
Whether you believe that golfing languages encourage creative thinking, or that they make it more difficult for newer users to get started, the fact that this site allows any language undeniably sets it apart from other golfing communities.
This section is for demonstrating some underappreciated challenges and answers. Be sure to check them out and give them an upvote if you find them interesting!
We recommend you check out this brainfuck interpreter written in Vim by Aaron Miller. It's an incredible program that demonstrates that Vim is (essentially) Turing complete!
Additionally, feel free to nominate challenges, languages and answers in the comments below for the next blog post!
This was written by Redwolf Programs and caird coinheringaahing. The Yes section and introductions were written by caird and the No section and conclusion by Redwolf. Feel free to leave any thoughts on the post or blog as either comments, or answers if more substantial.