# What is the point of unicode gibberish?

It's been a few years since I came back into this forum to play some code golf and I am seeing a flood of unicode only "languages" where large operations are hidden in a single unicode character and string compressing is built in default.

Of course the author tried to explain what the bunch of symbols mean but that doesn't matter because there is a real long representation of the language, which is what the author linked on "try it online" feature.

So what is the point of even trying to write small golfed code when some guy can just compress their code and claim it is smaller? Also do they know what "BYTES" even mean? You cannot say your 144 unicode chars use 144 bytes. Unless of course you make up a dictionary of these containing 255 chars so they could theoretically fit one byte, but that is a stretch.

I'm old school. I like bending real multi purpose computer languages like Python, Perl, Ruby... to their knees until the single last useless ascii char in the code is removed. Even languages that are meant for golfing should be better than that soup (I can't even call alphabet soup).

So what's up with that? Is there a tag like "ascii-languages-only" that people could add to make sure these things are excluded and other people can play with their brains and not their zip tools?

• I imagine people are into that so I honestly want to know what is the purpose of it and if it shouldn't be considered cheating. So if you downvoted me, I guess you have an opinion on the matter. So help me out here – JBernardo Nov 2 '19 at 4:30
• These languages use a SBCS (Single Byte Character Set), so each character is actually a single byte in that representation. It's not like it be any better if the code was a mash of ASCII unprintables anyway – Jo King Nov 2 '19 at 4:42
• @JoKing That's exactly what I thought, so that just make it a compiled binary instead of a source code. So, again, what is the point? The same way I can write x86 assembly or generate the compiled bytes to claim it is smaller – JBernardo Nov 2 '19 at 4:44
• You can do that. There is nothing stopping you from doing that. There are lots of excellent assembly and machine code solutions (although they tend to be hand-golfed, versus compiled). – Unrelated String Nov 2 '19 at 5:33
• You're not alone in this, we used to get these types of meta threads regularly a while back, though I imagine everyone who can't bring themselves to at least tolerate golfing languages here have already left. See How can we help users who are put off by the use of golfing languages? and J and GolfScript suck all the enjoyment out of Code Golf. – xnor Nov 2 '19 at 5:55
• @xnor I would imagine that, but I am able to tolerate a bit Golfscript for example because I understand it a stack based language where all operations are defined with a single char, but the text and numbers are still there to make it somewhat reasonable. My issue is when you compile code and saying it is source – JBernardo Nov 2 '19 at 10:40
• @UnrelatedString You must be joking, right? Then anyone will start pasting solutions lzma compressed that runs on Perl-lzma or Python-lzma languages, for example. That is plain ridiculous – JBernardo Nov 2 '19 at 18:16
• I suspect the reason you have received so many downvotes is that you don't appear to have made a good faith effort to understand what you seem to dislike. Most of your statements come off more as a rant about wanting to ban various languages and comments on how people who enjoy this must be foolish than as a question. Indeed, the point of the SBCS that these languages employ is an attempt by the author to make the language more readable. Further, competition isn't restricted by the existence of these languages, you are free to golf in (and vote on) whatever you want. – FryAmTheEggman Nov 2 '19 at 20:15
• Pretty much all answers are written from scratch rather than compressed. There's no difference between how one writes Jelly vs Golfscript, except that you may have to copy-paste certain characters or use a special keyboard. The only language (apart from Charcoal) I can think of that is compressed afterward would be Stax, though that is compressing from an already golfy position. – Jo King Nov 2 '19 at 21:55
• If someone were to solve a challenge by writing a binary executable (or the succinct version of a charcoal program) by hand (rather than compiling from something else), would that be fine? If so, once they have that answer, is it okay if they submit that, but also disassemble it and link to the assembly (or the verbose charcoal code), seeing as that's basically a more a more readable version of their code? And if that's fine, would it be possible to allow that but not the opposite? You can't know which version came first after all – Sara J Nov 3 '19 at 6:57

I'm old school. I like bending real multi purpose computer languages like Python, Perl, Ruby... to their knees until the single last useless ascii char in the code is removed. Even languages that are meant for golfing should be better than that soup (I can't even call alphabet soup).

I'm old school too. I also like bending a real multi purpose computer language, APL, to its knees until the single last useless APL char in the code is removed.

Did you know that…

Would it not be unfair to prevent other languages from using all eight bits of their code bytes‽

• I knew someone would come up with this argument. One exception does not make it a truth. This community is going back to HQ9+ times with this mentality. I will start zipping my code then to make use of all 8 bits – JBernardo Nov 3 '19 at 11:11
• @JBernardo You must be joking, right? Then anyone will start pasting solutions lzma compressed that runs on Perl-lzma or Python-lzma languages, for example. That is plain ridiculous. – user85052 Nov 4 '19 at 5:50
• @JBernardo I don't understand what this has to do with HQ9+. Care to elaborate? And by all means, do zip your code (while providing an interpreter that unzips it and runs it), and let's see if your compressed code can be shorter than the golfing languages' solutions. That'll be real code golf! – Adám Nov 4 '19 at 7:30
• @JBernardo I think the issue with your argument is that it assumes regular languages are trying to compete with ones like O5AB1E. I treat each language as its own sub-competition: if you post a raw X86 machine code program, that's not competing with my uncompiled C++. – Redwolf Programs Nov 10 '19 at 4:36

... so that just make it a compiled binary instead of a source code. So, again, what is the point? The same way I can write x86 assembly or generate the compiled bytes to claim it is smaller

... My issue is when you compile code and saying it is source

Python code is a source code because Python interpreter can run it. x86 assembly code is a source code because an assembler, say gas, can compile it so that the machine or OS can run it.

If you compile an x86 assembly code, you get a binary file which contains x86 machine code. And it is still a source code because the machine or OS can run it. It's just that an extra layer of an interpreter or a compiler is removed. Likewise, a kind of binary code written for a golfing language, say Jelly, is still a source code because Jelly interpreter can run it. It's all the same thing.

(Digression: people had to actually code in machine code before an assembler was introduced.)

How do you prove anything was written by hand or compiled by a computer? That's exactly what I'm pointing out, people can do whatever and compile their crap into these "languages" and say they came up with a small solution. That is exactly as zipping text

IMO, "written by hand" or "compiled by a computer" isn't really relevant. If you're trying to golf in x86 machine code, you'd be mostly writing the program in x86 assembly first, and then compile it to get the machine code. Then you tweak the x86 assembly to get shorter machine code. Probably you can also do it purely in machine code, but it's likely to be much harder and inefficient. If you don't believe me, I did exactly this (golfing machine code at assembly level) when I was golfing in Z80Golf.

Also, coding and golfing in the "golfing languages" requires much more ingenuity than simply zipping a source code in another language. The users who use those languages use them because they can. They're just having their own small competition. You don't need to join them or even try to read them.

Here is my favorite quote on this topic (original source):

For me I joined because it is fun. I spend all day writing readable code and sometimes it's nice to write something just because I can. I have no problems with golfing languages. The shortest code wins. Thats the rules most times. If I get an upvote for my Java/Python/Lotus Notes answer because I have done something smart that someone else thinks is cool then that's good enough for me. If someone beats my byte count with Jelly/GolfScript/AnyOtherGolfLang then respect to them for being able to do it. They get an upvote from me. I like this community. Let's not start taking it too seriously.

• That bottom quote is indeed great. Something I have lived by ever since I joined this community tbh. :) Apart from the voting mentality on CGCC (easy short answers tend to get more upvotes than complex yet very clever longer answers - regardless of the language tbh; see my example in my answer below/above), I never really understood why people had problems with golfing languages. I think in most cases it's just jealousy of the upvotes, even though votes and the win-conditions in general doesn't mean a thing tbh, and they could start learning those golfing languages themselves.. – Kevin Cruijssen Nov 8 '19 at 14:54

ASCII/UTF-8 may be the most used encoding for programming languages, but that doesn't mean every programming language should use it.. Those 'gibberish' characters in Charcoal/Jelly/05AB1E/etc. with their custom SBCS (Single Byte Character Set) encodings are actually created to make it more readable than raw bytes.. Yes, it may not be as straight-forward to see what's going on if you're unfamiliar with the language than let's say a Java program where everything is quite verbose, but I can personally read 05AB1E which I learned in the past two years more than let's say Perl or GolfScript, which I'm both completely unfamiliar with.

Also, to give some counter examples of why it's a weird thing to ask for ASCII only encodings:

1. In our native tongue, should we ban the regular Latin alphabet and ten digits, and start using the Chinese alphabet and numeric system?.. It's the most used character set in the world since roughly 1/3th of the world's population is Chinese (assuming most of them can read/write). 我該用中文寫剩下的信息嗎？ Your question is pretty similar by asking for ASCII only, just because you can read the characters.
2. Malbolge is ASCII only. Does that make its extremely complex encrypting/decrypting nature make it any more readable/understandable? Can you see what's going on in this Malbolge answer just because it's written in ASCII? To me this entire language is more gibberish than anything anyone would be able to produce in 05AB1E/Jelly/Charcoal/etc...

Personally I never really understood why people had problems with golfing languages, tbh. I personally started code-golfing mid-2016 and primarily answered in Java 7, which I was using at work and was familiar with. I knew Java 8 was shorter with its lambdas, and I also saw all these unfamiliar languages (including ASCII-focused ones like Perl, GolfScript, Japt, etc.) which were much shorter, but I didn't care. (Almost every answer was gibberish to me at the time tbh.) I had fun completing challenges in Java 7, and that was the most important. :)
The only problem I have with codegolf languages, or to be more precise: the code-golf win-condition and what people tend to upvote in general on CGCC: a very straight-forward but short codegolf answer would get a lot more upvotes than let's say a Java answer with some very clever tricks or which took a lot of effort. BUT, this doesn't apply to just code-golfing languages, it applies to all languages in general! Still, people will also see the effort of those more complex answers and upvote for it -eventually- (but usually not nearly as much as the easier but shorter answers).

To give some examples of answers of mine (in both 05AB1E and Java):

• Short but upvoted a lot:
• This 3-byte 05AB1E (legacy) program is currently my third most upvoted answer. Unlike the title of the challenge itself (It took me a lot of time to make this, pls like.), it's a very straight-forward implementation and took barely any thought to create and post.
• Similar, this 8-bytes Java answer is not only one of my shortest and most upvoted, but also the easiest of all Java answers I posted.
• Longer and very complex answers:
• 123 bytes 05AB1E answer. 05AB1E doesn't have any date builtins, so I was calculating the next day as well as the day of the week manually. It took quite a bit of fiddling around to get it to work, write the explanation, and golf it down some more, but it doesn't have nearly as much upvotes as the earlier 3-bytes answer.
• 1290 bytes Java answer (which is even long for Java standards ;p). This challenge was unanswered for almost two years (for good reason), and it took quite a few hours before I had implemented all edge cases and fixed all bugs.

Still, whether it's Java or 05AB1E, and ASCII or a custom encoding, golfing in both languages is a pretty similar experience for me: complete a certain challenge by using the language's strong points and overcome certain weaknesses as short as possible, and have fun with it! And although I appreciate the votes of course; whether I get 1 or 10 upvotes I don't really care about, as long as I had fun doing the challenge.

I also don't really understand why you have a problem with Charcoal, Jelly, 05AB1E, etc., but not with Japt, GolfScript, etc.. Apart from copy-pasting characters depending on your keyboard, completing challenges in all of them would be fairly similar, as I mentioned in the last bold phrase above.