In that vein I’d suggest J (or APL but J has ascii symbols). It will blow your mind and you will learn a lot of different ways of thinking about composition.
A modern version of APL I personally really found a fondness towards were BQN. I really like some of the lisp-y influences in that language and it is open-source (which some of the more well known other APLs are not).
People have tried to define and measure this and related ideas in different ways, and I'm not sold on any of them in particular. I can however suggest some languages that stand out in some of these explorations that you might consider.
+ Lisp dialects. In particular, take a look at Clojure, Shen, and Racket.
+ Smalltalk. Try Pharo. Check out some YouTube videos with Alan Kay.
Yeah, there's a reason why people who make the AOC leaderboard overwhelmingly use Python. It's very efficient for small-ish tasks like AOC.
I'm really liking Nim as a hobby these days. It has a very powerful macro system, which might interest OP. Nim macros basically normal nim code, executed at compile time by an interpreter built-in the compiler, which can directly manipulate or generate Nim AST.
Macros aren't exactly easy to read or write (again, it consists of manipulating AST nodes directly), but they can generate any amount of boilerplate code you need.
Personally, FWIW, I find shifting gears from Nim to Python to bring back a lot of Py-verbosity..but I used to think Python was pretty terse. { Also, Python is often gratuitously (some might say grotesquely) run-time resource inefficient. }
TXR Lisp values terseness, though not above everything else or to ridiculous degrees where we write catenative code using single international characters denoting functions.
TXR is a native program, with its own run-time, and has very low dependencies. There is a capable, expressive FFI.
Here is an example: ger2err: a complete, stand-alone program with command line parsing, which connects to Gerrit servers to extract changeset comments, turning them into compiler error format you can use in your IDE.
Fewest lines of code, or fewest expressions? Suppose you open/read/process/writeback/close on one "line": in principle that is five expressions, and it is supported by a vast volume of code in the lower layers, which shows that it is all a matter of complexity management, particularly as expressed in the definitions of the interfaces between layers.
Also, legibility is a crucially important aspect of complexity.
BASH is the most terse. You can develop a whole application in less than 100 lines. But if you want to read it 100 days from now, python is easier to read. I like python's handling of arrays and strings. I sometimes mix shell into python scripts.
FORTH seems to be most famous for what you can do in minimal lines of code.
I can't exactly say I recommend it for practical use though, it's everything I think a language shouldn't be, but it sure does attract some devoted fans.
Having written a Forth, and a long standing interest in it... I've come to the conclusion that Forth is the crippled inverse of Lisp
They are both very minimal in their syntax, for many purposes Forth uses a space where lisp uses parenthesis to ensure the arguments are consumed by the correct functions.
However.... you can't match spaces, which leads to losing track of arguments on the stack
I can think of ways this could be handled in an IDE, but my bet on Forth includes types, and operator overloading, a language called STOIC in the 1960s.
I definitely like LISP a lot more than forth, because it's more structured and explicit, and less "hackerish", even though I wouldn't choose LISP either for real use, although I could see it being a great backend for visual scripting(I've done something similar but with an extremely stripped down list based language stored in JSON).
TL;DR: time-to-solution is much more important than "code reduction"/typing time.
--
PLs from the APL family are probably most succint, then come Forth-like languages.
But most succint doesn't mean they're fastest to solve problems with, correct, or reable/easier to maintain.
When writing code in APL/J/K/Q you write one-liners in the REPL and iterate (refactor?) on them until you're getting the desired result. It might be that a little bit more verbose language will give you a solution faster, even if it will require a little bit more typing, but less iterations in the REPL.
The possibility of making a mistake or getting the wrong result is much higher for the APL family of languages.
The idiomatic style makes them almost write-only and hard to maintain.
