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
- 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&p:), factoring (
q:), GCD and LCM (
*.), 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 ;)