[de_Selby]

That's more on you than it is the language though. You can write obtuse write-only code in any language.

I will concede that there is a culture of trying to be a bit too clever on the k4 mailing list but it's perfectly possible to write maintainable code in kdb+

[Cyph0n]

But from what I recall, the syntax is terse by design - this is not inherently bad, though. In other mainstream languages, you have to go out of your way to write obtuse code (e.g, code golf).

I'm guessing that best way to address this issue is through liberal use of explanatory comments.

[de_Selby]

Terse syntax isn't an issue, you just need to get used to reading it. Using 1 character variable names is another matter though.

There is no reason not to use camel cased variable names and indent functions, if/else blocks etc, and when written this way the code can be perfectly legible even to non q programmers.

Something else that leads people into the write-only trap is that the usual way of working with the language is to use the REPL loop while working, where you can tend to be doing multiple things on 1 line. It's just laziness not to reformat and clean up the code afterwards though.

[geocar]

> There is no reason not to use camel cased variable names and indent functions,

There is: it makes the program bigger. Program source code length is significant, and if you have more lines, you have more opportunities for bugs.

[nl]

Is this supposed to be a joke? Or maybe related to some weird coding environment?

Long variable names may take more characters, but there is no way they increase bugs.

Indenting(!) doesn't even take many more characters if you use tabs...

[geocar]

> Is this supposed to be a joke? … there is no way they increase bugs.

No, it's not supposed to be a joke.

Steve McConnell 1993 observed density is proportional to source program length, so this should be obvious to every programmer: If a small program (as measured in source code bytes) is more likely to be a correct program, then this follows.

A major issue with discussing programming is the sheer number of people who believe they know how to program, when any non-programmer could see quite obviously that they don't: A professional bridge-builder doesn't often fail to build a bridge, but a professional CMS programmer seems to unable to get much past hello world without a bug or two; Less code will therefore produce less bugs.

[nl]

You are completely misrepresenting what McConnell says.

There is a summary of his advice here[1], but just to highlight

Describe everything the routine does And we mean literally everything. If that makes the name ridiculously long, the name isn't the problem. Your routine is.

And

Make names as long as necessary According to McConnell, the optimum name length for a variable is 9 to 15 characters; routines tend to be more complex and therefore deserve longer names. Make your names as long as they need to be in order to make them understandable.

I've read McConnell, and your claims are so completely the opposite of what he recommends that I'm still unconvinced you aren't trolling.

[1] https://blog.codinghorror.com/i-shall-call-it-somethingmanag...

[ams6110]

Mathematical formulas don't use long variable names. They use x, y, and various greek letters.

[nl]

This is generally (amongst mathematicians) considered to be a problem, not a good thing (Source: work with university Math departments).

Edit, see http://mathoverflow.net/questions/8295/origins-of-mathematic... for the confusion this causes..

[maemre]

That might be because:

- you need to write same variable name on each step of derivation of a formula

- paper and blackboards don't have autocomplete

- juxtaposition is used for multiplication, thus SwapBlue can be Swap times Blue or a single variable called SwapBlue, spacing for multiplication is not a good solution when writing to board/paper

[Locke1689]

And despite lambda calculus being written entirely using single letter variable names, Scheme programmers all use proper word-size variable names in their programs.

Mathematics notation is so notoriously awful that mathematicians often can't even read equations from other disciplines without significant extra context.

[valarauca1]

Bugs don't hide in variable names or white space.

Compiler errors do. But you catch those first run.

If tab vs 2 spaces vs 3 spaces can induce a logic error that is a purposely obtuse language.

[geocar]

> Bugs don't hide in variable names or white space.

Bugs do hide in variable names and whitespace.

    thisIsALongVariableName = True
    thisIsaLongVariableName = True

is easy to spot when they're side-by-side, but not so much when they're two pages away from each other. Python's tabs and spaces can confuse the indention in cases so that code that "looks" aligned actually isn't.

If you haven't run into a problem caused by a typo, you haven't been programming long enough.

[wott]

This is indeed a problem with languages without mandatory variable declaration. Is it the case of K, Q or whatever its name is?

[buckie]

While I agree that it's possible to write maintainable in kdb+, I'd argue that it takes noticeably more effort; or, as in inverse, if you drop your coding standards things get worse faster. I'd say the same for regex as well (though in a more limited sense).

The "characters to clever/unmaintainable" ratios you achieve with k (which most kdb+ platforms end up reaching for at some point) are almost unparalleled. A famous example of how awesome/powerful/ridiculous k can be is the "4 lines of K" text editor: http://www.kparc.com/$/edit.k

I guess my point is that letting your guard down, for even a single line, can be orders of magnitude more trouble than it would be in most languages and for that reason I wouldn't base a new stack on it. Also, the developers for it are rare-ish and expensive + it has a serious learning curve for those unfamiliar with FP or Lisp.

[jimbokun]

Not knowing k, seems like the worst part of the edit.k examples is every variable has a one character name.

Or do those single character tokens have special meanings in k? Which would be even worse.

[geocar]

> Not knowing k, seems like the worst part of the edit.k examples is every variable has a one character name. Or do those single character tokens have special meanings in k? Which would be even worse.

It can seem that way, but there is value in dense programs: They take up less room on the screen. This means you can see where you repeat yourself, and can often find bugs by just reading your code.

I can't count the number of times I scrolled over some code and missed a bug.

[hueving]

Change your scrolling settings?

[geocar]

Not sure what you mean by that.

[anonu]

Yes, the terseness of the language itself lends itself to terseness everywhere - even in variable namings. It's not necessary and I usually avoid that when I write k or q. Purposefully obfuscating code like that lends to the "bad rep" that the language gets.