Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Impending kOS

archive.vector.org.uk

Post reply on HN
Print view View original

91–100 of 242 posts

Re: Impending kOS

#91

Post by geocar »

MichaelGG wrote: post #79
geocar wrote: 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 hesitantly excited about this language, after reading this article. The power increase I've gained going from an "OO" imperative mindset to functional has been huge. The simple volume of code from other styles just boggles my mind. I can't understand why people prefer their verbose code with so much edifice. Making another leap like that sounds very promising. At the same time, it does sound slightly off. What's…

I wanted to be able to type K and press a button and get the result, so the first bit of k code I wrote was the following:

    np::*((l$[=/k;(*i),0;i]),j)_a;ci:{{J y;x:3:. x;J y;kx x;K(y,j)}[np;j]}
When you type !10 and press control-I it prints the result where the cursor is and selects it. This way you can press backspace to delete the output and change the code easily.

How much code should that take? Probably less than that (I didn't know about bin yet), but I think that's part of the learning process.

I think a minimal logo would only take a couple lines.

Re: Impending kOS

#92

Post by DennisP »

geocar wrote: post #27
tmikaeld wrote: post #2

Um, so what happened?

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

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.

Re: Impending kOS

#93

Post by mahyarm »

kiyoto wrote: post #23
masklinn wrote: post #22

Earlier quoted context omitted.

Why were you a proponent of kdb+?

For several reasons, some more legitimate than others. 1. kdb+ was (and maybe is) a good solution to the problem that we had: doing complex data manipulation/simple statistical calculations against billions of rows of time series data. Hadoop is the term du jour for data processing, but truth of the matter is that finance doesn't have really huge data. At best, it's a couple of terabytes, and most of the time, you ar…

It almost sounds like kdb needs an alternative syntax that is more human readable.

Re: Impending kOS

#94

Post by geocar »

burntsushi wrote: post #69
geocar wrote: post #51

Earlier quoted context omitted.

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.

Well, does there exist a technical analysis written by someone who understands k that explains why it is so much faster than X languages?

As I said, I think this is the wrong question.

The real question is why is X language so slow?

This is not intended to be glib: but I do not think I can put it more simply than that. X language is slow because it uses lots of library code that it doesn't actually use (to get a friendly interface), it has a lot of redundancy (because of the wrong abstraction level), and because it wastes memory (in order to have an API that links well with others). Or it's slow because it thinks B-Trees are really cool. Or because it has the wrong intrinsics. I don't know.

But I am convinced this is the discussion we need to be having.

Re: Impending kOS

#95

Post by geocar »

jeffreyrogers wrote: post #64
geocar wrote: 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…

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.

Re: Impending kOS

#96

Post by ddoolin »

geocar wrote: post #88
ddoolin wrote: post #83

Earlier quoted context omitted.

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…

I think this "readable" bit is the theory behind q which you can download from kx.com; Some people think it is more readable. q/kdb+ supports websockets and has a built-in http server so it is very possible to make web apps with it. However I think there is value in the dense coding style that has nothing to do with it's performance: it's that it reduces bugs and helps you think about the problem.

You've sparked my interest, for sure. I'd love to pull it down and give it a whirl. Hell, one could conceivably write those things with K as well.

Thanks for the perspective. Good luck to you all with kOS and others.

Re: Impending kOS

#97

Post by ANTSANTS »

ah- wrote: post #36

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

Good lord, I need a drink now.

Re: Impending kOS

#98

Post by nialo »

dang wrote: post #31
geocar wrote: post #21

Earlier quoted context omitted.

I disagree fundamentally. I have noticed every page I scroll causes a comprehensive loss of around 90%, so in reading something that is 10 pagefuls long, I might only be able to produce a tiny part of the program. Your milage may vary. I find not scrolling, and just moving my eyes, I rapidly absorb the program, and I find most bugs just by reading the code . This practice is absolutely impossible for me if I have to…

Yes, the research literature on software development has consistently found that code size is the best measurement of complexity and predictor of error rates. (Sorry I don't have citations handy but we've discussed this many times on HN, and there's a recent study in the book "Making Software" that adds to it.) What's interesting is how strongly this goes against what most people think they know about good programmin…

But, is number of lines a particularly good size measurement?

Is there evidence one way or the other on whether it's better to measure size with, say, number of lines, number of tokens, or number of nodes in a parse tree? or something else?

Re: Impending kOS

#99

Post by beagle3 »

mahyarm wrote: post #93
kiyoto wrote: post #23

Earlier quoted context omitted.

For several reasons, some more legitimate than others. 1. kdb+ was (and maybe is) a good solution to the problem that we had: doing complex data manipulation/simple statistical calculations against billions of rows of time series data. Hadoop is the term du jour for data processing, but truth of the matter is that finance doesn't have really huge data. At best, it's a couple of terabytes, and most of the time, you ar…

It almost sounds like kdb needs an alternative syntax that is more human readable.

It has one: q. But once you get over the syntax, you realize that you also need to grok different semantics that you are used to.

Some q is readable english - e.g., an expression like

   sum price where size>3
is (to the uninitiated) more readable than the equivalent k

   +/price@&size>3
but that only works for simple stuff. The (idiomatic!) computation of maximum-subarray-sum[0]

   |/0(0|+)\
becomes

   max over 0 (0 max +) scan
which is not more readable. And you can drive the point ad absurdum by making it even more verbose:

   max over zero (zero max plus) scan
The syntax seems like it is what stops you from understanding it because it is the first thing you meet. But it's the semantics that you need to grok, and the syntax just matches them.

[0] http://en.wikipedia.org/wiki/Maximum_subarray_problem

Re: Impending kOS

#100

Post by mwcampbell »

geocar wrote: post #27
tmikaeld wrote: post #2

Um, so what happened?

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

What hardware is your team currently targeting with kOS? An x86 virtual machine under something like VirtualBox seems to be a popular choice among developers of alternative operating systems, since it's a way of avoiding the diversity of PC hardware and the need for lots of drivers. So are you doing that? Or sticking to things that are pretty well standardized but outdated, like IDE and VGA as opposed to SATA and modern GPUs? Or are you targeting a particular subset of PC hardware?
Post reply on HN