Choosing Languages for Golfing What are some tips for choosing the right language to golf?
What factors affect the language to be chosen?

Here are some example problem types:


Problems that require I/O solution, either console or file
Problems that require parsing
Problems that requires you to write your solution as a function definition
Math problems
Problem dealing with prime numbers
Solving number puzzles
Performing numerical methods
String processing
Array processing
Tricky 2D array problems
Computational geometry
Recursion
2D graphics
3D graphics
Audio
Networking / web
Parallel processing


Don't simply say things like "Use GolfScript|J" because you like them.
Putting my two cents in on array programming languages, J and APL in particular.

K/Kona, Q, and Nial fall in this category too, but they generally have the same benefits and criticisms. Use discretion. I will use J examples below, mostly because these are ASCII and thus easy to type--remember than APL characters count as single bytes, so don't let that be your problem with the language as choice for golfing.


Math problems
Solving number puzzles
Performing numerical methods
Tricky 2D array problems


These two are very good math and data-manipulation languages, because they toss arrays around a high level, and a lot of looping is done implicitly, by saying, e.g. add ten to each of 3, 4, and 5 (10 + 3 4 5) or sum each row of an array (+/"1 arr--the looping is in the "1).


Problem dealing with prime numbers


With prime number problems in particular, J has fast and short builtin primitives, as do some dialects of APL. (Edit: I'm thinking of Nars2000, which is part dialect and part completely different implementation. APL has no builtin for primes.) N-th prime (p:), no. of primes up to (_1&amp;p:), factoring (q:), GCD and LCM (+. and *.), and so on, there's a lot there. However, in practice, the question will often specify that you have to cook your own prime implementations, so these don't see too much use. There are still neat and fancy ways of getting the prime stuff you need, it just becomes a little less cut-and-paste.


String processing
Array processing


Array and string processing is a bit of a mixed bag: if it's something that APL/J is good at or has a primitive or common idiom for, it's nearly trivial; if it's something that's very sequential and not very parallelizable, you're going to have a bad time. Anything in between is up in the air, though usually they will respond favourably.


Problems that require I/O solution, either console or file
Problems that requires you to write your solution as a function definition


IO is weird. APL has a single-character input expression, but with J you have to spend at least 8 to read in a number: ".1!:1]1. Output is a little less verbose, but you're still looking at 6 or 7 characters wasted, in practice. J in particular really likes it a lot if you can take in the input as arguments to a function, instead of having to muck around with IO itself.

In practice, with J and APL, usually the solution is written as a function that you invoke at the console. With APL, you can basically just put in variable names for your arguments and wrap the expression you were working with in curly braces and call it a day.

But with J, there's a bit of an overhead for defining functions explicitly--3 :'...', and you have to escape any strings inside--so what is usually done is something called tacit programming: you program at the function level, combining primitives in a manner not unlike that of Haskell. This can be both a blessing and a curse, because you don't have to spend as many characters referring to your arguments, but it's easy to drown in parentheses and end up losing tens of characters trying to hack your otherwise short and clever solution into something that works.


Problems that require parsing
Computational geometry


I don't have experience with golfing these particular problems, but I will say this: in the end, array programming languages are very good at piping and transforming lots of data in the same way. If you can turn the problem into an exercise in number shuffling, you can make it an APL/J problem, no sweat.

That said, not everything is an APL/J problem. Unlike Golfscript, APL and J just happened to be good for golfing, alongside their other benefits ;)