[anyfoo]

I'm torn. Not about the conciseness of the language overall, but about using symbols vs. names. I do see how the symbols make things more concise, less clutter, and can even make it easier to grasp a piece of code if you are deeply familiar with them[1].

On the other hand, there might be a limit. I do know how it is to use the Haskell lens package only occasionally, and then having to lookup again what the operators read out loud as "percent-percent-at-squiggly" and "hat-dot-dot" stand for (withIndex and toListOf respectively).

But arguably, the ones that are long and seldom used need looking up anyway, and their name is not that much more useful maybe?

[1] Also compare "2+2*8" with "sum 2 to the product of 2 and 8", or even just "sum(2,prod(2,8))".

[endgame]

The lens library has a reasonably consistent visual language baked into it:

- Operators containing `%` apply a function to the target (mnemonic: % is "mod" in many languages).

- Operators containing `=` have a `MonadState` constraint and operate on the monadic state.

- Operators containing `~` operate directly on values.

- Operators starting with `<` pass through the new value.

- Operators starting with `<<` pass through the old value.

- Operators containing `@` operate on indexed optics (mnemonic: indices tell you where you are "at" in the structure you're traversing).

So an operator like `(<<<>=)` means "semigroup append something in the monadic state and return the old result". This is the power of a well-chosen symbol language, and I don't know how you'd do this ergonomically and compactly with only named operators.

[secondaryacct]

You wouldnt make it compact, so the new dreaming intern joining your codebase would be able to gloriously produce changes rapidly and get hired under the well intentioned smiles of the rest of the team.

Instead, in the kdb team I joined recently (a one-letter, symbol heavy language used by quants), nobody can remember what things do, nobody has time to teach you the insanity of code older than 2 months, and you re instead spending weeks "learning" under the heavy sighs of everyone suffering from the new burden guy.

Why do you want to do things compactly rather than with clarity?

I wish google could search for one-letter language specific symbol so I could ask "what does -9! do on type J vs type C" (nonsensical exemple, I cant remember types without looking at the type table, but I think -9! transforms a bit array into an object)

[nine_k]

Look, the parent comment lays out a regular dictionary that allows to unpack a symbolic name into words, or pack words into a symbolic name.

In your case, the vocabulary is absent. (And yes, the custom of naming K functions with numbers, especially negative numbers, is sort of annoying.)

[andrewl-hn]

I think the K team recognized these issues and tried to address them - at least partially - with Q and it's readable function names and SQL-like extensions. But, AFAIK most Kdb programmers keep writing straight K instead. Don't know why either.

[WillDaSilva]

As anyone who uses such a language could tell you, you get used to the symbols quite quickly, and commit their meaning into memory. For that reason I mostly view the heavy use of symbols in a programming language as a negative only insofar as it makes it intimidating to newcomers.

The only other thing can I find can be an issue with the heavy use of symbols in a language is that it can lead to a certain degree of inflexibility in the language. There are only so many symbols that can be used, and once they're all used up your options are either use normal variable names (and reduce the number of ideas that can be expressed concisely), or make symbols context dependent.

The designers of k went to some lengths to avoid the use of variable names, so some symbols are better than others in terms of clarity. Some mean the same thing everywhere, but others are heavily context dependent in an effort to reuse the limited amount of symbols they have at their disposal.

k is a great domain-specific language, but struggles at being a good general purpose language for a variety of reasons. I'd love to be able to use it for data processing inside of other languages. Let the other less expressive but more robust languages handle the control flow, library interactions, etc., and then run k code to work with data as vectors and tables. If only k supported n-dimensional arrays, then it'd be very interesting to see what it could do if integrated with something like Numpy, but I could spend all day wishing k was better than it is. I'm very happy with what it's able to do, and generally groan when I find myself having to use other less expressive data processing tools (which is practically everything).

[tablespoon]

> I'm torn. Not about the conciseness of the language overall, but about using symbols vs. names. I do see how the symbols make things more concise, less clutter, and can even make it easier to grasp a piece of code if you are deeply familiar with them[1].

I think the "if you are deeply familiar with them" is important. Using non-standard symbols makes comprehension more binary: either you've memorized them and understand or you don't; there's no muddling through, relying on common concepts and terms to make up for incomplete memorization.

That probably also results in a much more binary user base: true-believers who dedicated a bunch of time to become proficient, and non-users who were unable or unwilling to, and not a whole lot in between.

[pault]

Are you talking about vim? I thought this article was about programming languages.

[initplus]

The trouble in Haskell is that an operator like %%@~ is just an arbitrary name.

In languages like K or APL, the combination of symbols is the actual definition.

[anyfoo]

As APL shows, you then need quite a large alphabet of symbols, though.

But I'm not strongly in either camp. A few common branches of mathematics taken together have quite a large alphabet of symbols, too, and we work well with it. It feels like symbolic notations can seem obtuse at first and be hard to get into, but once you're used to it the alternative may appear worse.

[neolog]

> As APL shows, you then need quite a large alphabet of symbols, though.

I count 71, which doesn't seem like a lot.

[still_grokking]

That's more than key-words in most languages, I think.

[scns]

Quick'n'dirty wetware lookup:

Go: < 30

C: ~ 31

C++: > 70

[neolog]

Python builtins (not even keywords): 68

[nextaccountic]

lens operators in haskell at least have some structure https://news.ycombinator.com/item?id=28124226

[nightpool]

how is "%%@~" different from, say, "°"? Since they're both designed to be contentless, couldn't you form a bijection between them without losing anything? (And if your objection is atomicity, how do you feel about "%" and "°"?)

[endgame]

The premise here is wrong, because lens operators are very much designed to carry meaning. See my sibling comment (parent->parent->sibling, I guess), but operators with `@` operate on indexed optics, and the leading `%%` means "modify, and collect summary".