71–80 of 161 posts
Earlier quoted context omitted.
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...
Earlier quoted context omitted.
I wish you'd actually read the article before shooting your mouth off with a Well Actually. FTA: > Next one: nanomsg. An alternative to ZeroMQ. In comments: > How would you split nanomsg, then? > [...] 2. coroutine library, e.g. libtask, libmill [...] Not to mention that this is obvious if you understand what the core of each thing is in terms of capabilities. If you are gonna be the "technically..." guy, at least do…
Commenting like this will get you banned on HN regardless of how much you know or how right you are. Please reread the site guidelines (linked at bottom of every HN page) and take them to heart from now on.
Earlier quoted context omitted.
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 sof…
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 fundamenta…
Earlier quoted context omitted.
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.
This is only software I have ever seen that actually got smaller over time. Not only that, it is the only software I have ever seen that used a GUI and then ditched it in a subsequent version. Few programs are so aligned with my own software sensibilities. Only complaint is that they used to have a FreeBSD port and now only have Linux and macOS but no BSD. Unfortunately Linux compat in BSD is being perceived by some…
Earlier quoted context omitted.
I like K better than Q too, but J[1] clicks with me more. J has JDB[2] and Jd[3] for things somewhat similar to qdb with Jd being the commercial offering similar to qdb rather than JDB. I would probably choose APL over Q if that were a choice. In J you can always make your definitions (verbs, nouns, etc...) plain words if you like the way Q reads. [1] jsoftware.com [2] http://code.jsoftware.com/wiki/JDB [3] http://ww…
Have you used Dyalog APL recently? They now have a rank operator and fork/hook from J. I am learning J but haven't made up my mind about this.
Earlier quoted context omitted.
1) Yes, but that's not huge by modern standard. OP could have phrased it better, but I presume his point was that 500KB is extremely small by modern standards. The whole executable fits comfortably in L3, so you'll probably never have a full cache miss for instructions. On the other hand, while it's cool that it's small, I'm not sure that binary size is a good proxy for performance. Instruction cache misses are rarel…
> Instruction cache misses are rarely going to be a limiting factor. k's performance is a combination of a lot of small things, each one independently doesn't seem to be that meaningful. And yet, the combination screams. The main interpreter core, for example, used to be When Python switched the interpreter loop from a switch to a threaded one, for example, they got ~20% speedup[0]; I wouldn't be surprised if the fit…
Yes, I presume it's very fast because of a number of smart design decisions. I would guess that the relatively small on-disk size of executable is a consequence of these decisions, rather than a cause of the high speed. And as you point it, it's really the design of the core interpreter that matters.
When Python switched the interpreter loop from a switch to a threaded one, for example, they got ~20% speedup[0]; I wouldn't be surprised if the fitting entirely within the I-cache (which K did and Python didn't at the time) gives another 20% speedup.
I'm familiar with this improvement, and talk it up often. Since certain opcodes are more likely to follow other opcodes (even if they are globally rare) threaded dispatch can significantly reduce branch prediction errors. But despite not having measured the number of I-cache misses on the Python benchmarks, I'd be utterly astonished if there were enough of them to allow for a 20% speedup. My guess would be that the potential is something around 1%, but if you can prove that it's more than 10% I'd be excited to help you work on solving it.
Earlier quoted context omitted.
> 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.
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.
They make the source code larger.
That makes it harder to read.
Earlier quoted context omitted.
> 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, becaus…
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.
The columnar structure of the DB as well as its IPC layer make it very good at creating chains of processes that can be used to stream row updates and branch them out to different processes with different responsibilities. Likewise it's on disk database is great for running complex (time series) queries.
This speed and terseness comes at a cost of being fairly "old school" in its approach. It's only recently for instance the we got stack traces, and readability is definitely not for the faint of heart though this depends on how it is written.
In my view the biggest thing that is needed right now is better tooling and libraries. Some attempts have been made to do this, and I am hearing that the new initiatives by kx will be addressing this in the coming months. The lack of standardized testing library/framework also can be problematic, as every team that I have seen does it slightly differently, and a "best practice" would beneficial.