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

101–110 of 242 posts

Re: Impending kOS

#101

Post by geocar »

mwcampbell wrote: post #100
geocar wrote: post #27

Earlier quoted context omitted.

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

Arthur, Oleg and Pierre use Asus UX31A; I have a MBA. I did the first kernel in qemu, but Pierre got an EFI boot going with Intel modesetting pretty quickly.

I'm more interested in smaller devices though (ARM, etc).

Re: Impending kOS

#102

Post by geocar »

DennisP wrote: post #92
geocar wrote: post #27

Earlier quoted context omitted.

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.

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.

Re: Impending kOS

#103

Post by mwcampbell »

geocar wrote: post #101
mwcampbell wrote: post #100

Earlier quoted context omitted.

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

Arthur, Oleg and Pierre use Asus UX31A; I have a MBA. I did the first kernel in qemu, but Pierre got an EFI boot going with Intel modesetting pretty quickly. I'm more interested in smaller devices though (ARM, etc).

So is a laptop like the UX31A or the MBA actually usable as a laptop with kOS yet? I imagine power management is going to be complicated to implement, if you haven't gotten to that yet.

> I'm more interested in smaller devices though (ARM, etc).

Yes. I imagine a smartphone with a very low-power processor and a couple orders of magnitude less RAM than the mainstream models could have very impressive battery life.

Re: Impending kOS

#104

Post by gcanyon »

geocar wrote: post #37
dang wrote: post #31

Earlier quoted context omitted.

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…

If someone produces smaller and faster code than me, then I should want to learn from it. I wonder why other people have the exact opposite reaction. Why do you think that is?

I'm not sure -- I know that after the fourth or fifth time solving a problem on projecteuler.net in 20 lines of code and seeing someone post a 1-line J/K solution, I went and downloaded J. I even managed to solve a few euler problems with it, which I regard as a large accomplishment for a novice. I like to tell people I've written a whole twenty or so lines of code in J!

Re: Impending kOS

#105

Post by tinco »

geocar wrote: post #87
tlrobinson wrote: post #33

Earlier quoted context omitted.

Could someone who can parse (reverse engineer?) this write up an explanation? (if you exist)

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…

That was awesome, thanks for explaining that for us. It makes a lot of sense the way you explain it, and I quickly got the idea that you can make some powerful expressions this way.

The smooth creation of lists is I think one of the most important language features higher level languages have over lower level languages like C.

Just this thing:

    c::a$"\n"
That's all I needed to be convinced that modern languages should have similar view constructs. In ruby it'd be:

  c = a.map.with_index{|a,i| a == "\n" ? i : nil }.reject{|i| i.nil? }
Quite a mouthful, mainly because Ruby lacks a neat way to do '$'. But doing the same thing in C would really be awkward, and likely not as efficient unless you have some fancy code for building enumerators in C.

Re: Impending kOS

#106

Post by dang »

nialo wrote: post #98
dang wrote: post #31

Earlier quoted context omitted.

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?

My understanding of the literature is that no one has found a better way to measure program complexity than lines of code. In particular, the fancier metrics (cyclometric complexity and so on) don't add any value over simple LoC.

We've debated the merits of counting tokens before, but I don't recall anyone mentioning a study about it. In real programs—i.e. when you're dealing with idiomatic code as opposed to something designed to game a metric—I doubt that LoC, lexical length, and number of tokens differ much.

Re: Impending kOS

#107

Post by MichaelGG »

tinco wrote: post #105
geocar wrote: 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…

That was awesome, thanks for explaining that for us. It makes a lot of sense the way you explain it, and I quickly got the idea that you can make some powerful expressions this way. The smooth creation of lists is I think one of the most important language features higher level languages have over lower level languages like C. Just this thing: c::a$"\n" That's all I needed to be convinced that modern languages should…

Certainly you could wrap up the $ operator into some Ruby method?

Re: Impending kOS

#108

Post by tinco »

robfig wrote: post #71

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?

It's proprietary.

Re: Impending kOS

#109

Post by losvedir »

geocar wrote: post #87
tlrobinson wrote: post #33

Earlier quoted context omitted.

Could someone who can parse (reverse engineer?) this write up an explanation? (if you exist)

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…

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 with more traditional languages?

Re: Impending kOS

#110

Post by MichaelGG »

geocar wrote: post #95
jeffreyrogers wrote: post #64

Earlier quoted context omitted.

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

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?
Post reply on HN