5
\$\begingroup\$

Say I'm designing a new language for golf or some other esoteric purpose, and I'd like feedback on some design concepts. I feel posting this on SO, Programmers, CS, or pretty much any other site on SE would likely just going to get down-votes or at least side-eyes. Even if not, I think I'd likely get better responses from this community because what makes a good esolang is often very different from what makes good general-purpose language (e.g. the Funge family).

Would such a question be considered on-topic for PPCG?

\$\endgroup\$
  • \$\begingroup\$ I feel like any such question would be either too broad or primarily opinion-based. You can always ask in chat, though! \$\endgroup\$ – Quintec Feb 7 at 1:27
  • 5
    \$\begingroup\$ Dennis has said in chat that language design tips are too broad. However, agreeing with you that it doesn't fit elsewhere on SE and that we'd be able to answer it best, I think the community should move towards accepting such questions. \$\endgroup\$ – lirtosiast Feb 7 at 1:37
  • 1
    \$\begingroup\$ I think you'd have to phrase it carefully to be" constructive subjective" and not a "What’s your favorite ______?" question. In particular, I'm thinking along the lines of "how can this language better address particular kinds of challenges?" could be made constructive. \$\endgroup\$ – p.s.w.g Feb 7 at 1:39
  • \$\begingroup\$ Related \$\endgroup\$ – Shaggy Feb 7 at 21:13
  • \$\begingroup\$ I'm late to the party, but CS is what you want. They have a language-design tag specifically for these kinds of questions. You are right though: You'll likely get downvotes or side-eyes, in the same way that BF questions on codereview get side-eyes. \$\endgroup\$ – Nathan Merrill Feb 21 at 21:34
1
\$\begingroup\$

Designing languages for golfing requires a good amount of exposure to golf problems such that you can create a list of useful structures that you would like to abbreviate. Trivial example constructs are filter, map, zip and reduce operations and various variants of those operations.

The most obvious thing is to pack as much functionality into a single character or single byte (if you don't want to use ASCII). You overload it as much as possible. You can have a character do something for an integer, something else for a double, something else for a list etc. You really want to pack as much functionality into a single character as possible.

The next obvious thing is to have implicit type conversions wherever possible because explicit type conversions would just make a solution one byte longer. Of course, this means you have to trade off between overloading and implicit type conversions. And this is exactly where a lot of experience comes back in such that you know which is going to be used more often.

I'm the person behind Burlesque (the programming language) and it was never designed to be a golfing language but it eventually turned into one over the course and there are a lot of mistakes (some that were fixed, some that can't be fixed by design) when it comes to golfing. (Most obviously Burlesque uses two characters per built-in, you'd automatically make all burlesque programs half as long if you'd map every burlesque built-in to one byte).

One other thing you can do is to use parsing errors to "mean" something. I.e. if the parsing error is at the end of a program you can just ignore it or fix it for example in the case of "m{foobar" which is missing a "}" but since it's at the end of the program you could just insert a "}" and you saved one byte.

If you want to know something or more details you can hit me up in a chat.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .