Live data from Hacker News

Impending kOS

archive.vector.org.uk

161–170 of 242 posts

Re: Impending kOS

#161

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!)…

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.

Re: Impending kOS

#162

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

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.

Re: Impending kOS

#163
post #131

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 t…

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.

Re: Impending kOS

#164
post #83
post #34

Earlier quoted context omitted.

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 deskto…

I'm just a regular web and app developer, but would it be at all possible to write a layer on top of k that makes it at least more readable while retaining most of the speed advantage? To me, part of being an engineer is not taking offense when being told there are potentially better ways to do things, but at the same time I can understand why some people jump to that kind of statement since at first glance it seems…

Industry does try to lower the barrier to entry. At the same time it strives to reach ever-higher tops. APL family of languages have a high barrier to entry - which is of course a problem - but even remaining novice in the language you can be routinely more efficient working with APL than working with another language. So - that high barrier to entry is a disadvantage, but for that you can have pretty high levels of efficiency in the same language going from newbie to intermediate to advanced levels.

Re: Impending kOS

#165
post #34

Earlier quoted context omitted.

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 deskto…

>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…

VPRI (vpri.org) was already mentioned here. The goal of Alan Kay, as I understand it, to reduce complexity of computer systems - by making them smaller. k shows you potential results with this approach - doing things differently, you can have small and functional systems, so they could be easier to understand while remaining feature-rich.

Re: Impending kOS

#166
post #148
post #138

Earlier quoted context omitted.

The reason k, q or other array languages like J (which I use) help, not teach, people to solve novel problems is that they give you abstractions to quickly play with in order to tackle novel problems. My take on this whole thing is that these array languages (APL, k, J, q) are a perfect fit for things that are essentially arrays - big data, images, etc... And to those who shy away from the seemingly 'noisy' syntax, I…

I think part of the difficulty here is that it's almost like Haskell's point free style, but not quite. It isn't really clear where the arguments to avg go. It seems that it's meant to be a bit like this: avg list -> (sumall list) / (tally list) I guess you just need to know how the argument you give to avg when you use it distributes over the functions that comprise the expression. The list argument to tally isn't a…

In J there are two special ways to combine functions which are written using special syntax. Namely,

1) when you want to calculate f(y, g(y)) , you write (f g) y - this is "hook" of one argument (monadic, in J terms)

2) when you want to calculate f(x, g(y)) , you write x (f g) y - this is "hook" of two arguments (dyadic)

3) when you want to calculate f(g(y), h(y)) , you write (g f h) y - this is monadic "fork"

4) when you need f(g(x, y), h(x, y)) , you use x (g f h) y - dyadic fork

5) when you have a train - say, (a b c d e) x - longer than 3 elements, then you consider rightmost 3 functions (functions are called verbs in J) as a single fork - say, f - and then consider (a b f) x . So (a b c d e) x is

b(a(x), d(c(x), e(x)))

If the train length is even, the last operation becomes hook - so x (a b c d) y is

a(x, c(b(x, y), d(x, y)))

You can express any computation as a sufficiently complex train.

Re: Impending kOS

#167
post #102

Earlier quoted context omitted.

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.

Would it run under Kona? [1] 1. https://github.com/kevinlawler/kona

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

Re: Impending kOS

#168
post #87

Earlier quoted context omitted.

I'll give this a shot. I'll try to explain what's in my mind as I read it as well. First, get out the reference manual: http://kparc.com/k.txt and we'll do the first couple lines. The sequence that goes f x applies x to f. this f is unary. The sequence that goes x f y applies x and y to f. this f is binary (and just labelled verb). Some things (adverbs) go f a x and apply f in some special way to x. Last hint: You re…

I have one question. I learned some J some time ago, but never really talked about it with anyone, and so my programs - a few lines' scripts, really - were always written with long, meaningful variable names. I read your explanation and every time you wrote "we don't know what it is yet" I wondered "why the heck isn't it just appropriately named?". I mean, why is 'c' better than something like 'nl_pos' for example? I…

j is abstract. It seems like it should be easier if it is concrete, but I find that this tends to lead to assumptions and encourages scanning instead of reading.

When I sit down to a program, I have an idea about what I want to do. I don't have home/end keys on my keyboard and I note that pressing Fn-Left and Fn-Right is annoying because I don't usually push them (I use emacs sometimes). So when I sit down to edit I want to add emacs keys.

I can see at http://kparc.com/z.txt that hx handles home/end, and that cX is control-X, so I think it should be something like:

    ca:{hx 0 -1};ce:{hx 0 1}
Now I look at the characters spent: Is it possible I could say this simpler? I don't think so, but I'd love someone to tell me.

How about delete? I think what I want to do is select the next character and remove it. So where is the cursor? Well I remembered that hx moves the cursor, so I read it's definition:

    hx:{L i+d*x}
Okay, so I remember d is "dimensions" and "i" is something, and L I haven't seen yet. So I go look at L:

    L:{K@B/0|x&d-1}
Now I have two new words: K and B to look up:

    B:{c[x]&y+b x}
    K:{J(;|\(*k),)[H]x}
Okay, B is straightforward: b is indexed by line, so b x returns the offset of line x. We add this to y (which is the second value of |x&d-1) and take the min of it and the offset for c. I might think at this point B converts the x/y coordinate into a linear offset. But what about K?

K is using J and H (but it turns out we only need J):

    J:{k::2#0|x&-1+#a}
And here we see the definition of k: x&-1+#a is the smallest of x and the second to last character in the file (a), and the max of that and zero (0|). This reads like "bounds check x to the shape of a". Taking 2 from that simply takes two values and assigns them to k so if x is only one-value k will still have two.

k is the cursor selection.

From here, I can make an attempt at implementing delete. My first attempt looked something like:

    cd{a::((0,k)_a),(((k+1),(#a)-(k+1)))_a}
Oh! But I've seen a lot of these terms before! Maybe I can do better. I note that kx is documented as the callback for keystrokes http://kparc.com/z.txt and can come up with:

    cd:{K j+!2;kx""}
This seems about as simple as I can make it. I'd like to see someone do better, but knowing that K is a setter for the cursor selection and j is the offset of the cursor, then j+!2 simply returns offset and offset+1; K will select it and kx"" will remove it.

Now maybe if k were called cursorSelection I might have gotten my first cd faster, but I would've missed the opportunity to see how these functions and variables were interconnected and I might not have written the second one.

I noticed however, that not scrolling really helped this exercise. I just moved my eyes around, and jotted a few symbols down on my notepad. I feel like if I had to scroll or switch windows I would not have been able to do this.

As for your last question: What does one need to master it? For now, I would say practice. Try writing a program in as dense a manner as possible. Remove as much redundancy as you can. Read it and re-read it until you feel like it can be no more abstract.

I am working on a much better answer, but I hope that one will do for now.

Re: Impending kOS

#169
post #159

Earlier quoted context omitted.

Wow, that was fascinating. K looks utterly mind-expanding, thanks for breaking this down. You obviously have some experience working with K, and it sounds like at least Javascript, too? K is so foreign I expect it has a lot of interesting thoughts locked up in there that maybe don't get the attention they deserve. Would you say there are any "killer features" of the language / environment that you miss when working w…

Killer feature -------------- Not having to write: for(int i=0; i which generally obscures the fact that I'm trying to do a map or fold (e.g. - reduce) operation :).

ES5

Re: Impending kOS

#170
post #95

Earlier quoted context omitted.

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.

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?

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.

Post reply on HN