Welp, you were not kidding: https://github.com/KxSystems/kdb/blob/master/c/c/curl.c

This code is basically obfuscated by hand. Absolutely unapproachable. Only the original author(s) can understand it.

Judging by other comments, it seems to work well. So they seem to be good programmers producing working code. It's just not intelligible by other human beings, which is a pretty bad thing, but not the only factor in software quality/health.

The Vim code base is at some parts straight batshit insane, but it's one of the most polished programs I've ever used.

All that being said, I would find infuriating to work with such code. Nope!

It takes time getting used to, yes.

And it is not for all people.

But it's just a foreign language; You could look at Japanese text[0] and make similar statements, and would be just as valid (or rather, invalid) as your statement.

You expect to be able to read it because you're used to a class of languages which are all similar enough at the surface level -- perhaps you are even familiar with more than one fundamentally different classes, say, "lispish and algolish" or "germanic and latin". But that doesn't make APLish or Japanese[0] horrible.

This is just APL using C syntax.

[0] assuming, the proverbial you does not know Japanese

The difference between "#define Z static" and Japanese is that Japanese is an effective method of communicating between 125 million people.

And k/q is an effective method of writing very fast software for domains such as finance understood by thousands of people.

Just because you find it strange, it does not mean it's strange.

I'm sure you'd find languages in Papua New Guinea difficult at times, and you'd argue English is "better" because more people speak it, and there is a richer literature in it, but the ideas expressed in those languages - and how they are expressed uniquely in those languages - are valuable to the people who speak them.

No one here said it was strange. The original word was 'unhealthy'.

I'd be very interested to learn more about which semantics of APL-derivatives correspond to which of the 4 or 5 distinct meanings of the keyword 'static' in C.

k/q is an effective method of writing useful code. if you are not used to it and can't appreciate it, doesn't mean that nobody can.

Could you please stop breaking the guidelines? We just asked you to comment more substantively than this.

https://news.ycombinator.com/newsguidelines.html

I don't see where this code is getting a definition for K. (The return type of the ctype function).

It's not in the "k.h" header, though that references it also.

Maybe the build system injects it through the compiler command line or a forced-include header. Though the gcc command line alluded to in the block comment header shows no evidence of that.

Edit: Found it! It's a typedef for a pointer to a struct k0:

  typedef struct k0{signed char m,a,t;C u;I r;union{G g;H h;I i;J j;E e;F f;S s;struct k0*k;struct{J n;G G0[1];};};}*K;

That's the dominant data structure in the whole program. It's a little different from what's used in APL and J, but essentially it represents an array which carries around its length, shape, and pointer to items. An explanation for the J version is in An Implementation of J [1].

There are a handful of helper functions to get/set various parts of this structure, and most of the functions in the language (and its implementation) take 1 or 2 of these and return 1.

[1]: http://sblom.github.io/openj-core/iojNoun.htm#Arrays

I'm a vocal convert.

This approach helps me find bugs and repetition in my programs which makes my code shorter and faster as a result.

I can see the argument for terseness. In fact I loathe how verbose Java is, I try to minimize LOC, and I enjoy using ?:. However, I don't think it's a good idea to use this extreme single-character, single-line style in languages not designed for it. If you really want this style, you should use APL or design your own language.

Basically, this really wants to be using a custom preprocessor for a cleaner notation.

That would be a good step, but I don't think a preprocessor alone is enough to make this a good idea. You want good compiler error messages, static analysis tools, debuggers, code editors. You want a whole language.

They have a whole language there, didn't you notice? Namely, this Q thing that the submission is about.

What we're looking at here is some of its C implementation internals. They are using short identifiers and the C preprocessor to help with terseness. The justification is that this is "like APL". But there is enough C cruft there that it's not really like APL. A possibility would be to generate whatever code those C macros are generating, but with some other preprocessor which polishes the notation a little bit.

Even if those analysis tools and debuggers were developed for Q, they likely wouldn't apply to this code.

The point is that using Q style in C is not a good way to make a C program, regardless of whether said C program is the implementation of Q or not.

The point (mine, that is) is that I basically agree that it's not a good way to code in C, but perhaps the style could work better as a notation that transliterates to C.

what a gap. an abyss. inventor, and users of kdb explicitly and deliberately DO NOT WANT these things (static analysis tools, debuggers, code editors). nor they need it. language is so simple, there is no need for static analysis or code editors. (they compromised on error messages somewhat recently, though; now error messages are two words instead of one)

personally, i disagree with them on debugger. would be nice to have one.

You are right. There is an impassable abyss. I will never agree with anyone who believes that good error messages, analysis tools, or debuggers are not worth having.

> I will never agree with anyone who believes that good error messages, analysis tools, or debuggers are not worth having.

Even if they can do things you cannot do?

What are you doing here if so freely admit you have a closed mind?

They are using APL. This style is used in APL/J/K/etc implementations as well as the languages themselves.

I don't think it's a good idea to import the style of a language into its implementation written in a different language; at least, not to this extent. When in Rome...

It's how Whitney's always done it:

http://code.jsoftware.com/wiki/Essays/Incunabulum

> I can see the argument for terseness

The argument is that my programs are shorter and faster and more correct?

> I don't think it's a good idea to use this extreme single-character, single-line style in languages not designed for it.

You think if I need to write C, that I should do things that make my program larger and slower and less correct?

That doesn't make any sense to me at all.

> You think if I need to write C, that I should do things that make my program larger and slower and less correct?

Yes (marginally), when those things are at odds with the tools and conventions of C, because there are serious downsides you don't list. Compiler error messages will be difficult to understand. Tools for code analysis and debugging will be less useful or even completely unusable. Most importantly, because your personal style is alien to other people you lose the ability to collaborate with other developers.

A language designed for this would mitigate most of those downsides.

> Tools for code analysis and debugging will be less useful or even completely unusable.

If you don’t put bugs in the first place this causes very little problem in practice.

> because your personal style is alien to other people you lose the ability to collaborate with other developers.

Another solution is to expand the program by adding white space and long identifiers after it is written.

This works better for me since if someone wants to change my program it’s because they want it to do something that I didn’t.

Longer identifiers don't make C programs larger. (Well, shared libraries have larger symbol tables, and unstripped executables have bigger debug info.)

Using multiple lines and indentation doesn't change executable code.

> Longer identifiers don't make C programs larger.

They make the source code larger.

That makes it harder to read.

I can't understand your comment; can you make greater use of one-letter words?

z^n=x^n+y^n

what can be greater than this?

I have a marvelous response for you, but even if I use nothing but one-letter words, it doesn't fit into this margin.

Oops, I see we are devolving into Reddit. Alas, at least the end is near; recursion bottoms out at 4chan which is just one stack frame down.

It's so terse, it's gotta be fast!