
Impending kOS - nightTrevors
http://archive.vector.org.uk/art10501320
======
kiyoto
>Kdb+ has sharp elbows.

No shit. I used to work as a quant, and while I was an okay quant and mediocre
trader at best, I survived for three years in the industry because of my kdb+
proficiency: the firm I was at spent a couple of million dollars on kdb+ only
to find out that most people could not wrap their heads around kdb+ let alone
debug it effectively.

My (former) colleagues were definitely smart people. In many ways, they were
way smarter than myself. But I somehow could get a much better handle of
kdb+'s idiosyncrasies, and my ability to stare at dense k/q code (usually no
more than a dozen lines) and figure out what's wrong with it earned me the
reputation as the "q guy" \- and some level of job security.

The firm eventually phased out kdb+ completely after my boss and I left (the
two proponents of kdb+).

~~~
qfan
I've worked in many shops that use kdb+ and the ones who really benefit are
the ones who bothered to get some training on it rather than those who just
assume they'll wing it somehow. Kx themselves have been running great intro
workshops for a couple of years now. Some guys at the next desk attended one
and came back buzzing with excitement at how they now saw through the noise.
So the take away is - if you didn't bother to learn it, stop complaining that
you don't understand it. It's not difficult to get when it is explained well,
but you're not gonna get it just by staring at it.

~~~
kiyoto
>I've worked in many shops that use kdb+ and the ones who really benefit are
the ones who bothered to get some training on it rather than those who just
assume they'll wing it somehow.

Yea, I know all about the training and First Derivative. My employer also
hired them.

In their defense, every First Derivative KDB+ consultant that I worked with
was very sharp and an excellent teacher. They really knew their stuff, and
First Derivative is no small part of what has made KDB+ so successful.
However, even with their excellent pedagogy, most of my co-workers were
totally lost/weren't willing to apply themselves to learn q/kdb+ well.

Here is another way to think about it: many people can't ever get their heads
around certain conceptually difficult topics, say, measure theory or quantum
physics. I don't think kdb+ is nearly as hard, but it seemed that way looking
at my peers who were no slowpokes.

------
viksit
The last line of TFA reads like the beginning of some sort of movie in the
drama/thriller category. "kOS is coming. Nothing will be the same afterwards."

That's what irritated me most.

What I'd like to understand is - what led the author to this particular
conclusion? Is it the fact that this language is super expressive and concise?
Is it that it routinely [1] outperforms its C counterparts even if it
ultimately translates to C? Is the Z graphical interface so superior that
it'll blow the pants off Cocoa and Quartz and X.org or Wayland or what have
you? Why would one rewrite emacs or vim on it? I don't want some basic 4 line
text editor - I would like to be _productive_. Why would Mozilla spend energy
porting firefox to it? Or Google, chrome? Or bash?

Simply talking about the history of K/kdb+ and how brilliant its creator is
_simply_ doesn't help the reader understand why they should be excited about
it. If that was the intention of this article, then the real points to make
should've started _after_ that line.

That would've been much more interesting.

[1] - No pun intended, of course

~~~
geocar
What you're actually seeing is testimony: people saying they are seeing
something amazing, and they aren't very good at explaining what they saw.

Btw: k doesn't translate to C. It's actually a quite simple interpreter. The
fact that it outperforms other languages so easily _should_ be saying more
about those languages than it should be saying anything about k.

~~~
mwcampbell
So would k be even faster if it were compiled to machine code rather than
being interpreted? Would that involve an unacceptable speed versus space
trade-off? Or am I missing some crucial reason why k code has to be
interpreted?

~~~
Torn
According to wikipedia's uncited 'performance characteristics' section of
their page on K (programming language):

> The small size of the interpreter and compact syntax of the language makes
> it possible for K applications to fit entirely within the level 1 cache of
> the processor.

Sounds like the overhead's acceptable?

.

Edit: the following page (2002) says

> Even though K is an interpreted language, the source code is somewhat
> compiled internally, but not into abstract machine code like Java or Python.
> The interpreter can be invoked interactively or non-interactively, and you
> can also compile a source file down to a binary file for product
> distribution, if you wish.

[http://www.kuro5hin.org/story/2002/11/14/22741/791](http://www.kuro5hin.org/story/2002/11/14/22741/791)

~~~
smcl
Thanks for the link to kuro5hin btw - it's a nice intro to k but also I've not
been on k5 for years, I had no idea it was still going :)

------
sz4kerto
The same story told again -- it's aim is to generate this magical atmosphere
around a fast db engine and language that's deliberately obfuscated to make
people who work in it feel smart, so they try to spread that it's the best.
KDB/Q is a nice tool, not the holy grail how they put it. And it's not fast
because they know something better - it's because it lacks almost any safety
measure.

~~~
kiyoto
I totally agree. That's why I wrote a parser for the language to help me and
my coworkers debug =)
[https://github.com/kiyoto/ungod](https://github.com/kiyoto/ungod)

As I commented above, the syntax is horrible. But I still think it is an
effective tool for certain problems.

------
bshimmin
Here's the text editor they're talking about:
[http://www.kparc.com/edit.k](http://www.kparc.com/edit.k)

The code is, well, not the easiest to understand.

~~~
outside1234
That's an understatement. If we are allowed code like this, I can write an
editor in ONE line of JavaScript. :)

~~~
beagle3
Note that his lines are < 60 chars.

Can you write this editor in one line of less than 6000 chars of javascript
(without a "textarea")?

~~~
calinet6
It does not matter. This is not a programming language; languages are designed
for human comprehension. Human comprehension is an irreducible part of the
whole paradigm of programming, being necessary to understand the _nearly
always_ complex logic required to describe anything of value.

This is gibberish. It fails at the one task of a programming language: to
translate something a human can understand into something a computer can
understand, with as little confusion as possible.

~~~
beagle3
No, it is just not a language for the masses who have gotten used to all
programming language syntax being minor variations on the Algol/Pascal/C
theme.

Much like math and physics, this is an extremely terse notation that is
immensely useful to those who practice it, and looks like gibberish to those
who have not attempted to study it. You could give the same comment about an
article in any area of math whose notation you are unfamiliar with -- and you
would be just as equally wrong.

------
scottlocklin
The APL family was developed to think about math and linear algebra in
particular. Iverson's "Notation as a tool of thought" f'rinstance:
[http://www.jsoftware.com/papers/tot.htm](http://www.jsoftware.com/papers/tot.htm)

If you've worked with such things for your day job, exposure to an APL
language is mind blowing in the same way as exposure to Lisp is. You'll
rapidly find out that an awful lot of the numerics world is an ad-hoc
reinvention of an APL language. Leading thinkers in the numerics world have
noticed. Have a look at the Tensor type inside Torch7, or -idx- class in Lush
(the same thing): they are, in fact, a sort of APL with a more conventional,
aka painfully wordy, notation.

Writing an editor in an array language seems crazy, but then, writing a
parallel processing system in a language that was designed to run applications
in your web browser also seems crazy. If people had stuck with APL style
languages, well, databases, particularly distributed databases (Kx and 1010,
both K based systems, scale to Pentascale, and have for a long time), would
suck less, as would CUDA programming. Their revival could make life easier in
these problem domains.

------
zokier
Googled around, Kuro5hin (that's a name I haven't seen for some time) has a
tutorial for K from 2002:
[http://www.kuro5hin.org/story/2002/11/14/22741/791](http://www.kuro5hin.org/story/2002/11/14/22741/791)

The download link at [http://www.kparc.com/](http://www.kparc.com/) asks for
password, so I'm not sure whats going on with that.

~~~
sohagan857
You have to have a personal invite to download the code atm. The whole article
is telling you it is not available yet, but "if coming".

~~~
kencausey
I may be mistaken but I believe zokier is referring to a download link for k
whereas you are referring to a download for kOS. No?

~~~
fa
Right. The part of the page that says "download (then $chmod +x k)" and
linking to [http://kparc.com/download/k](http://kparc.com/download/k) is
password-protected. I just want to follow along some of this tutorial
material. I'll try to do this with Kona.

------
manish_gill
The language looks fascinating. Check out Kona, an open source implementation:
[https://github.com/kevinlawler/kona](https://github.com/kevinlawler/kona)

------
radicalbyte
Interesting article. Found this
([http://queue.acm.org/detail.cfm?id=1531242](http://queue.acm.org/detail.cfm?id=1531242),
submitted here
[https://news.ycombinator.com/item?id=8476120](https://news.ycombinator.com/item?id=8476120))
interview with Arthur Whitney (from 2009) which is also really interesting.

------
TheOsiris
> “It is a lot easier to find your errors in four lines of code than in four
> hundred.”

Looking at his code on
[http://www.kparc.com/edit.k](http://www.kparc.com/edit.k) I'd like to
disagree with that statement

~~~
wyc
If I posted four lines of Chinese or Sanskrit, it's likely that native English
speakers would disagree that they had much meaning either. However, this
doesn't mean that those lines are inherently devoid of meaning or difficult to
parse.

~~~
616c
That is a fun experiment. I studied linguistics in college, and I do not think
anyone ever discussed textual density of different languages with the "same"
content (the latter part would be its own terrifying chestnut; if you have not
studied machine translation and semantic eval and good luck ever confirming
such a statement).

I studied Arabic a lot, and Chinese about a year. I cannot speak to Chinese
with only one hazy year under my belt, but I can speak to Arabic.

Because Arabic has lots of syntax realized at the morpholgical level, you can
encode a whole sentence (subject (with declension inherent and gender
variable, verb conjugated (to passive/active, past/present/future,
standard/subjunctive) and direct object (declension inherent and gender
variable) _all in one word_ as we know the in English.

أضربه (A-dr-b-u; a (I) dr-b (hit) u (him/it): I hit him (present tense)

And that is a super simple example. I have seen much more compicated setences
in one word, and even better in two or three. So, I hypothesized Arabic is
very, very dense. I think and Russian and others could be considered similar.

However, with this level of density (maybe we argue "compression" from a CS
perspective) I noticed books and their translation were routinely about the
same length in pages. Never identical mind you, but never something crazy like
50 pages more (I am guessing; it has been a long time since I made such an
experiment and would have trouble agreeing with someone on what is
significant).

Now, one could hypothesize a shitload about what this means, but computation
is realized as the same "stuff" (machine code instructions) in programming
languages, where no parallel exists in human language for mapping human
language to computaion, as far as I know from my between minor and major
courseload in linguistics, specifically computational linguistics. If someone
can contradict me, I would LOVE to read about measured cognition and language
constructs.

~~~
ggreer
It's important to separate spoken information density from written information
density. Some languages win at one while losing at the other. Your arabic
example was shorter than the equivalent english on paper, but longer when
spoken (4 syllables vs 3).

In terms of information density per syllable, mandarin wins, with english
coming in a close second. When speaking, english usually has more syllables
per unit time than mandarin, so english has the highest spoken information
density of any language. Japanese is the on the opposite end of the spectrum.
Despite having the highest syllabic rate, it has the lowest information
density.[1]

For written information density, logographic languages win. This is pretty
obvious if you've seen a Chinese or Japanese translation of something
familiar, such as a Harry Potter book. They're ludicrously thin.

1\. See the figures at the end of this paper: [http://www.ddl.ish-
lyon.cnrs.fr/fulltext/pellegrino/Pellegri...](http://www.ddl.ish-
lyon.cnrs.fr/fulltext/pellegrino/Pellegrino_to%20appear_Language.pdf)

~~~
alricb
> When speaking, english usually has more syllables per unit time than
> mandarin, so english has the highest spoken information density of any
> language.

Of the seven languages in the study, using 20 specific short texts, that were
originally written in English then translated (well?) in other languages.

~~~
ggreer
They recognized this issue and accounted for it. From the paper:

 _Since the texts were not explicitly designed for detailed cross-language
comparison, they exhibit a rather large variation in length. For instance, the
lengths of the 20 English texts range from 62 to 104 syllables. To deal with
this variation, each text was matched with its translation in an eighth
language, Vietnamese (VI), different from the seven languages of the corpus.
This external point of reference was used to normalize the parameters for each
text in each language and consequently to facilitate the interpretation by
comparison with a mostly isolating language (see below)._

It shouldn't be particularly surprising that english comes out ahead. It has a
huge vocabulary, tons of phonemes, and makes many parts of speech optional. It
lacks tones, but would probably have to sacrifice some phonemes to stay
comprehensible.

~~~
alricb
That just deals with the variation in length of the texts, not the effect of
translation quality or other possible problems with the experiment, like
written -> spoken conversion.

------
lmm
There's a contradiction I always see in these pieces: they talk a lot about
the importance of using the right data structure. But these languages get
their incredible conciseness by not giving you any choice about your data
structures; their array type is hardcoded into the language, and if you want
to use something else then your code balloons.

~~~
beagle3
K basically has 3 data shapes:

atom (int, float, char, date, symbol, ...)

list (one dimensional array of atoms, dicts, flips or lists)

dict (a map from one list to another)

There's also a flip, which exchanges the first two indexes applied to an item
(so, e.g., it effectively transposes a list of lists) but it is just sugar
(both syntactic and semantic).

You can trust Whitney that all of these are properly implemented, including
appends.

It's not often that you actually need more. I've discovered this after using K
for a while, and going back to python.

Back in my pre-K (ha!) C++ and Python day, I had an awful lot of classes
everywhere. After using K for a while, my Python and C both have much much
fewer (structs in C more often than python, as C is missing python's dict).
And the code has gotten much shorter and more efficient. Arguably, more
readable as well. And I've essentially dropped C++ for C, because the extra
complexity is just not worth it.

------
ah-
k/q really doesn't have to be this unreadable, that's just Arthurs style.
Here's some code in C by him for comparison:
[http://kx.com/q/cs107/a.c](http://kx.com/q/cs107/a.c)

~~~
nemo1618
I tried cleaning it up a bit:
[https://gist.github.com/lukechampine/f54fce8fd756254cefb2](https://gist.github.com/lukechampine/f54fce8fd756254cefb2)

But the actual meaning of the program is still lost on me. I can only guess it
has something to do with parsing files (note the checks for curly braces).
Feeding it its own source code produces some output, but I have no idea what
it actually modified.

~~~
epsylon
It's a solution to CS107 assignment 1 :
[http://web.stanford.edu/class/cs107/assign1.html](http://web.stanford.edu/class/cs107/assign1.html)

~~~
nemo1618
Guess I could have just looked at the URL, huh. Well, it was fun trying to
reverse Whitney's code anyhow.

Humorously, it looks like this code would have received a poor grade. It meets
just about every standard for low quality outlined here:
[http://web.stanford.edu/class/cs107/landmarks.html](http://web.stanford.edu/class/cs107/landmarks.html),
particularly "Fast code which doesn't work quite right." (Due to an off-by-one
error, this code fails to properly reconstruct the example text.)

~~~
asd02
> Due to an off-by-one error, this code fails to properly reconstruct the
> example text

What's your example? It seems to work fine to me on "{all is well}{ell that
en}{hat end}{t ends well}"

------
svan99
I love K/Q and is using it in my startup. Thanks a lot for Kx's recent freeing
up the 32bit version. To use APL-like languages I have to really shift the way
of designing/modeling things. Most importantly K may not be best for lots of
developers working on the same thing. Object oriented languages will fit
better in that case. K projects often only involve one or two developers who
model things in vector thinking (column based thinking in data domain), know
exactly what to do and how to do it. Vector thinking is not suitable for all
problems, but works really well if it does. Btw, new 3.2 version of kdb
appears to be even faster than before. It also improves websocket integration
and JSON data conversion. Very nice to integrate with nodejs/Qt.

We also use Forth which I think is a really another way of shifting mind.

~~~
icsa
What kind of computation is done at your startup? I've used k/q for trading,
graph analytics and computer vision (scene reconstruction).

------
ndesaulniers
I seriously thought that the article, and some of the code examples people are
posting [0] was a joke! I need to go rethink my career.

[0] [http://www.kparc.com/$/edit.k](http://www.kparc.com/$/edit.k)

~~~
avmich
That's certainly good - we should learn languages which are different enough
to justify learning.

Your code in whatever language you work will benefit from that rethinking.

------
robfig
So K is a general purpose programming language? If the claims are true, why
don't they submit some entries to the Computer Language Benchmarks Game?

~~~
tinco
It's proprietary.

~~~
xorcist
<sarcasm>Yeah, that's why.</sarcasm>

~~~
igouy
Perhaps they asked if their K programs were wanted:

[http://benchmarksgame.alioth.debian.org/play.html#languagex](http://benchmarksgame.alioth.debian.org/play.html#languagex)

------
jamesfisher
Does a good formal introduction exist for K, or Q, or APL, or J, or any other
languages in this family? Something with, you know, a syntax definition at
least, and any kind of formal definition of the semantics.

The closest I could find is this [1] but "The model is expressed in SHARP
APL", so from the start, it's circular.

[1]
[http://www.jsoftware.com/papers/APLSyntaxSemantics.htm](http://www.jsoftware.com/papers/APLSyntaxSemantics.htm)

~~~
eggy
It's not formal, but it is helpful to watch these series of videos by Martin
Saurer on J:

[https://www.youtube.com/watch?v=VSJpJt3c11c](https://www.youtube.com/watch?v=VSJpJt3c11c)

It goes form solving some Euler problems to a full-blown web app in J.

------
zokier
I wonder what K would look like with bit reader-friendly syntax. I tried
running a program that supposedly "will take a K expression and produce its
English translation"
([http://kx.com/a/k/examples/read.k](http://kx.com/a/k/examples/read.k)), but
either it doesn't work with kdb+/q or I can't figure out how to use it. Does
anyone have some example output, or advise?

------
anonbanker
A language/kernel/db/ui to watch. Reading the comments here, it seems the
language separates the wheat from the chaff; the average brogrammer won't he
able to handle this, but many of us are very interested in exploring.

An OS this small is incredibly exciting to me.

------
sumanthvepa
Worked at Morgan Stanley's fixed income desk many years ago as my first job
after grad school, programming A+. It was a decidedly acquired taste. The
language and style were utterly alien to anyone coming from a background in C
(and at that time an early version of Java.) While A+ was fast for
manipulating arrays (much of what the trading floor needed), it seemed that
doing GUI development with A+ was really pointless. The speed of the language
didn't matter in GUI interactions, and it was very hard do understand other
people's code.

------
tmikaeld
Um, so what happened?

~~~
geocar
It's not done yet.

This summer, Pierre and I got kOS to boot directly into g (the graphical
interface; formally called z) with ISR, keymap, modesetting, basic filesystem,
etc weighing in around 100 lines of C. That was pretty exciting. Could
probably be done with less with some deeper changes to Arthur's code, but it's
still very useful to run k under Linux. Oleg made a silly little game in kOS.

Arthur and Oleg did some performance benchmarks staging k against q (current
kdb+), Postgres, some "popular RDBMS" (that I can't name), and MongoDB. It was
impressive that k is so much faster than q, but it also really underscores the
cost of the wrong data structure (and how hard it is to get the right one with
SQL or MongoDB).

~~~
DennisP
How much are you planning to opensource?

I realize you have a thriving commercial software company and that's cool.
But...wow. This is exactly the sort of thing Alan Kay's team has been working
on for the past five years, and you guys seem to be beating them to it, with a
completely different approach. It would be pretty amazing to be able to dig
into it, find out how the whole system works, and contribute.

~~~
geocar
I'm not actually employed by kx, so I can't say for certain.

I don't think Arthur's opposed to open sourcing bits though.

~~~
reedlaw
Would it run under Kona? [1]

1\. [https://github.com/kevinlawler/kona](https://github.com/kevinlawler/kona)

~~~
geocar
No. A lot of the verbs have changed in k.

~~~
chippy
so would it work if Kona changed?

~~~
scottlocklin
Kona is K3. K5, the subject of the article, is being invented now. I'm quite
certain there is no plan to make Kona K5 compatible.

------
mamcx
So, I read about the fast interpreter and small language. How do something
like this?

"Whitney’s strategy was to implement a core of the language – including the
bits everyone thought most difficult, the operators and nested arrays – and
use that to implement the rest of the language. The core was to be written in
self-expanding C. As far as I know, the kdb+ interpreter is built the same
way.

Unlike the tall skinny C programs in the textbooks, the code for this
interpreter spills sideways across the page. It certainly doesn’t look like
C."

This mean that the code is very unreadable C? Like a kind of code-golf?

How replicate it for built a speedy interpreter? And what if I use lua or
python instead?

~~~
JulianMorrison
There are two opposite schools of readable C.

The mainstream says: readable C has function and variable and type names that
express meaning, so a function is read like a narrative with verbs, adjectives
and nouns. The fact that this narrative scrolls over pages, is unimportant.

The APL/K/J school says: readable C has functions, variables, and types named
with single letters, so that the totality of a function is short enough to fit
in _one glance_ \- preferably, on one line that does not need a scrollbar. The
function does exactly what it says, no more and no less; its intent is thus
completely clear. To name it descriptively would ruin the ability to grasp the
whole thing as a gestalt.

~~~
mamcx
Ok, so APL/K/J is for people that read compressed code..

But that how relate to how build a fast interpreter? Faster than C?

------
anonu
I hate to love KDB because its a very expensive closed platform. But if you
understand some of the concepts and how easy it is to achieve those concepts
with a few lines of q code you can do some brilliant things. Yes, KDB is a
great data store and provides very quick methods for crunching that data with
its vector-based approach.

However, whats really impressed me with KDB is that you can do so much more
with it. In some banks it has effectively become the messaging middleware for
connecting hundreds of disparate data sources. In addition to passing messages
you get the data storage and analytics tools for free...

------
duckingtest
This seems to be a very fun language to write in, in the same way optimizing
assembly code in the ancient times was fun; the age of skilled artisans.
Unfortunately (for programmers - great for the rest) now is the time of a
factory worker. Due to that, I don't think this language and its platform has
a long future.

Its continued survival is rather a testament to excellency of marketing (as
evidenced by this article!) rather than actual merits.

~~~
avmich
I think the opposite :) - marketing of R is light years ahead. Language is
very obscure, but so good that from time to time you're going to hear
wonderful stories from new enlightened.

And with the rise of parallel programming we're going to actually switch more
to more vector way of describing and solving problems. Just like Lisp ideas
are spreading everywhere in modern languages, APL ideas are also fruitful.

------
rsync
I'm interested in a kOS with a "god says ..." program built in ...

~~~
serf
get Terry Davis on the job. Is he opposed to porting his holy code to other
esoteric platforms?

------
jeffreyrogers
> kOS is coming. Nothing will be the same afterwards.

There seems to be this strange idea going around that if we just get the right
tool, everything else is going to change forever. I see this a lot with people
trying to create IDEs that let non-programmers create programs without really
knowing how to code.

But the thing is, most people just don't have anything worth coding. The
problem isn't that the tools don't exist. They do, even if they aren't
perfect. It's that making something that matters isn't an easy thing to do.
And no tool can change that.

~~~
geocar
If I am from another planet, and say I don't know why programs are so big and
slow and buggy, and the most complicated program you see I've produced is a
glorified calculator, it's too easy to be patronising and say _well, that 's
because you haven't done anything complicated_.

However if I then show you a programming language, a database engine (similar
in capability to SQL but around 1000x faster), a graphical desktop with icons,
mouse, editors, filesystems, ISR, and so on- and it's still under 400 lines of
C code, then maybe it's easier to have this conversation that I think we need
to have: That maybe _all you programmers_ have simply been doing it wrong, and
there's something fundamentally wrong with the way you and _everyone else_
programs computers.

I think most programmers take so much offence from _the thesis_ : that
everyone programs wrongly (or badly) and that a fundamental shift in the way
we program could make programming much better, that it's been difficult to
actually work on this problem. Just look at all the people who are complaining
about the text editor being difficult to read without saying _I can 't read
this, and I want to get better_.

And I think it should be obvious: You've built bridges for thousands of years,
so you expect you're pretty good at it now, and yet there are still
improvements in bridgemaking today; why do you expect programming to be any
different? Why do you have "best practices" for programming if you've only
been doing it for a few decades and don't really know how to do it yet?

Maybe it's much easier to think we're working on giving non-programmers the
ability to program, but we're not: we're trying to make programming suck less.

~~~
jeffreyrogers
>And I think it should be obvious: You've built bridges for thousands of
years, so you expect you're pretty good at it now, and yet there are still
improvements in bridgemaking today

Right, and I'm not saying programming won't improve. It obviously has. No one
wants to write a web app in C++ or assembly. What I'm specifically taking
issue with is the idea that there is some sort of monumental change out there
that is going to enable us to do... what exactly?... well no one can really
answer that, but the claim is that it is big and exciting and will change
everything.

~~~
geocar
When I can fit my program on the screen, I don't make any mistakes.

I think this is true of most programmers.

While "hello world" type programs tend to be the pedagogical example, kOS
demonstrates that the complexity of such a one-screen low-defect program is
much higher than people previously thought.

~~~
MichaelGG
Not being facetious, but does this extend to using larger screens, multiple
screens, wider columns or multiple windows, and smaller fonts? Or was one
screen just meant as an estimate for 200 lines or so?

~~~
geocar
I think it is the act of scrolling or window-switching or head-moving that is
the cost. To that end, I find using a MBA screen to be perfectly adequate for
programming because it fits entirely in my field of view.

My screen is about 55 lines tall and maybe 170 characters wide. I sometimes
shrink or increase the font slightly to make programs fit on screen.

------
tsmith
Sounds great! Where's the documentation on IPC / mutexes / threading?

> todo

> files, procs, tcp/ip, usb, ..

Oh.

~~~
icsa
E.g. - (k4/q)
[http://code.kx.com/wiki/Reference/hopen](http://code.kx.com/wiki/Reference/hopen)
shows how to open a file/proc.

The rest of the wiki is quite useful including a references and tutorials for
q.

k5 uses operators instead of words like q.

Btw, being able map/reduce w/ 1000 procs on a 8GB Linux vm (using k5) is both
useful and fun.

------
rgbrgb
Kind of curious to play around with that text editor. Any chance of K running
on OSX?

~~~
ah-
You can get kdb+ for free from here: [http://kx.com/software-
download.php](http://kx.com/software-download.php)

However, they've been working on a new version of k that's not publicly
available yet and I suppose the kparc stuff requires that.

------
esya
Hey Geo, if you read this, congrats :)

Tristan

------
agarttha
joke: search jqk on google images

------
lafar6502
I don't buy this story. Maybe kdb is fast and great, but the article attempts
to describe it as a work of a genius, better than anything else because it's
100 lines of code, doing its own memory management and running on bare metal.
But in fact many other programs do their own memory management and can run on
bare metal. JVM or .Net do their own mem management, all database servers too,
and many, many others. So what's left on the table? 500 lines of C code that's
meant to change the world? I really doubt it (or, these guys arent using line
breaks). We've read so many similar stories about Lisp and how it's one
language that can do everything in 5 lines of code or how you can build an
entire OS and all applications in Lisp, but where's that OS now?

~~~
icsa
What's left on the table is the efficient use of resources.

When I mentioned to a friend that the current version of K5 was a binary <
100KB, his response was "I don't believe it. I can't write HelloWorld in less
than 100 KB!".

Access to more resources does not mean that one should be wasteful.

K benefits from a dedication to avoiding waste and duplication and efficient
use of mathematical concepts. The Fundamental New Computing Technologies at
VPRI has similar goals (an entire end-user system including "Office" apps in
40 KLOC or less).

Being able to prototype a multi-proc map/reduce algorithm in k with 1000 procs
on a laptop with 8 GB RAM is quite nice.

> 500 lines of C code that's meant to change the world? I really doubt it (or,
> these guys arent using line breaks). There are line breaks, undoubtedly.
> That said, I'm sure the code is concise - much like k code.

K3 was 1200 lines of code and included the language, windows(GUI), database,
IPC, REPL (w/ simple debugger), FFI and OS interaction. The Windows executable
was 320 KB.

------
jwatte
Every ten years, some company comes around and claims that their
functional/data flow/columnar/meta shortish is orders of magnitude better.
Usually, the one thing they have going for them is that they focus on only a
small subproblem. That lets them be small. Every demo is one of no edge cases,
no exceptions, and no I/O errors. (Or they cram all that into some "standard"
library.)

The real challenge is that, 99% of the time, requirements and integration is
what kills you, not raw performance. For the cases where performance (or
formal correctness, or whatever) matters, the main challenge is usually to
convince the market that it's worth paying for, and then finding the right
developer project match.

~~~
avmich
This is all false for APL. First, APL is right there in the history with
Fortran and Lisp - and its "every ten years" became irrelevant already when it
was used to analyze IBM 360 hardware and found some bugs which were fixed in
time for shipping. Second, these languages are truly for very wide ranges of
problems - it's the industry curse that APL isn't used more widely; I guess
the reason is it's harder to learn. But you can do can use it for really
everything. Who'd thing JavaScript would be the language to write Linux
emulator? So it's less wonder that k is used for OS writing.

