Impending kOS • Hacker News Board

Re: Impending kOS

#131

Post by jwatte » Sun, Oct 19, 2014, 2:10 AM UTC

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.

Re: Impending kOS

#132

Post by RickHull » Sun, Oct 19, 2014, 2:19 AM UTC

zokier wrote: post #7

bshimmin wrote: post #3

Here's the text editor they're talking about: http://www.kparc.com/edit.k The code is, well, not the easiest to understand.

Here is the four line version: http://www.kparc.com/$/edit.k (lines beginning with / are comments)

Obviously bug free! Regarding intelligibility / comprehensibility: it's somewhere between brainfuck and Perl's worst examples of line noise

Re: Impending kOS

#133

Post by jwatte » Sun, Oct 19, 2014, 2:30 AM UTC

geocar wrote: post #34

jeffreyrogers wrote: post #12

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

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…

If the SQL is I/O bound, the kdb version cannot be 1000x faster. And if it's not I/O bound, you're not pushing it right. (Nite: compare columnar SQL here.) K can't make your I/O subsystem faster, and the new OS probably doesn't natively support 99.9% of existing high performance hardware.

Re: Impending kOS

#134

Post by Widdershin » Sun, Oct 19, 2014, 2:30 AM UTC

tinco wrote: post #112

MichaelGG wrote: post #107

Earlier quoted context omitted.

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

Sure, simply do: module Enumerable def dollar(c) map.with_index{|a,i| a == c ? i : nil }.reject{|i| i.nil? } end end And then you could do: c = a.dollar("\n") There is of course a reason this dollar method is not a part of the standard library. Its name makes no sense and it's oddly specific, how often would you want the indexes of matches to a character? Most modern languages don't like to work with indexes a lot, a…

Regarding find_all_with_index, you can do:

    .find_all.with_index { |item, index| ... }

Re: Impending kOS

#135

Post by mamcx » Sun, Oct 19, 2014, 2:50 AM UTC

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?

Re: Impending kOS

#136

Post by fa » Sun, Oct 19, 2014, 3:03 AM UTC

kencausey wrote: post #113

sohagan857 wrote: post #44

Earlier quoted context omitted.

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

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?

Right. The part of the page that says "download (then $chmod +x k)" and linking to 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.

Re: Impending kOS

#137

Post by JulianMorrison » Sun, Oct 19, 2014, 3:05 AM UTC

mamcx wrote: post #135

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…

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.

Re: Impending kOS

#138

Post by eggy » Sun, Oct 19, 2014, 3:10 AM UTC

dkarapetyan wrote: post #25

jeffreyrogers wrote: post #12

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

Not knowing how to code is not really an issue because we can and do teach people how to code the same way we teach people how to count and do basic algebra. What we can't do well is teach people how to solve novel problems that they haven't encountered before.

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 point them to mathematics. Until you understand the sigma symbols and others, it is noise too. Why are all the new languages getting hot on 'vectorization' - Julia and company - because GPUs and data are all array-based. To have the array as your lingua franca puts you in a good position for all sorts of attacks on modern computing needs. And for those who cannot live with the syntax, and say how can you create a dsl - you can. Here is a J example of computing averages:

  +/%#

You can set this up as:

  avg=: +/%#

or

  tally =: #
  divide =: %
  sumall =: +/

How's that for a dsl? Which allows this now:

  avg=: sumall divide tally
  avg 2 4 6
  4

EDIT: I forgot to add that these operations, as others in J or APL, work on scalars, vectors and arrays without any special typing or handling. See this presentation for at least the first 5 minutes to see J in action with explanation: http://www.infoq.com/presentations/j-language The conciseness allows you to start seeing the small patterns in the small expressions just like mathematics, hence bringing clarity and speed of abstraction to your concept manipulations.

Re: Impending kOS

#139

Post by Jupe » Sun, Oct 19, 2014, 3:14 AM UTC

outside1234 wrote: post #4

bshimmin wrote: post #3

Here's the text editor they're talking about: http://www.kparc.com/edit.k The code is, well, not the easiest to understand.

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

Open a new tab and enter this (sans quotes) into the address bar:

data:text/html,

Done :)

Re: Impending kOS

#140

Post by alricb » Sun, Oct 19, 2014, 3:34 AM UTC

ggreer wrote: post #48

616c wrote: post #17

Earlier quoted context omitted.

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…

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

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