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?