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

141–150 of 242 posts

Re: Impending kOS

#141

Post by ggreer »

alricb wrote: post #140
ggreer wrote: post #48

Earlier quoted context omitted.

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.

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.

Re: Impending kOS

#142

Post by dragonwriter »

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…

> A view is a concept in k that is unusual in other languages: When "a" gets updated, then "c" will automatically contain the new values.

Its actually not at all an unusual concept; its well known from SQL, for instance, but also Scala has them (Scala views aren't views in the sense that you use the term, but the lazily-implemented transformers they implement produce views of the type under discussion) as does Ruby (via Enumerable::Lazy). In fact, while the name "views" isn't exactly commonly used for them outside of SQL (though, as noted, Scala uses the term for the construct through which one obtains them), they are pretty ubiquitous in modern languages.

Re: Impending kOS

#143

Post by minor_nitwit »

geocar wrote: post #91
MichaelGG wrote: post #79

Earlier quoted context omitted.

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

that's awesome. It's a one line REPL.

Re: Impending kOS

#144

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

Re: Impending kOS

#145

Post by nitrogen »

kemayo wrote: post #63
zokier wrote: post #7

Earlier quoted context omitted.

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

Since I don't know how to read K, and it's not really very friendly to amateurs who're just scanning a program without a reference open... is this equivalent to a bare C program implementing an editor with no libraries, or is it relying on stuff the system provides?

I see cz cx and cv in the four-line version, which seem like they are referring to Ctrl-Z, Ctrl-X, etc. If that is the case, then there is a lot of behind the scenes support stuff to get from those four lines of code to a window on the screen or a buffer in a terminal.

Re: Impending kOS

#147

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

Re: Impending kOS

#148

Post by KayEss »

eggy wrote: post #138
dkarapetyan wrote: post #25

Earlier quoted context omitted.

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…

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 problem, but why does sumall get it's own copy of it? Or is the execution model something else entirely?

Re: Impending kOS

#149

Post by wglb »

uberalex wrote: post #13
wyc wrote: post #10

Earlier quoted context omitted.

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.

I think that the issue is that just measuring simplicity in terms of number of lines is a bad metric. You can have extremely complex expressions in a single statement that are at least as hard to read and debug as an equivalent, much longer piece of code that employs temporary variables and single-purpose statements.

Actually it is a good metric, certainly to the first order. Yes, you can have a line or three that is more complex than the rest but practically it isn't going to reduce the line count that much.

And token counts don't help as code that insists that each brace must be on its own line detracts from readability. For one thing it pushes the last bit of the function off the bottom of the screen meaning you have to scroll.

A line that is overly complex is eventually get rewritten.

I say this as someone who has written large bodies of code in sigma 5 assembly, Fortran II and IV bliss 36, C, C++, and Lisp. Perhaps more to the point, these days I read large bodies of code measured in millions. Lines of code dictates how long it will take to understand it.

Peter Norvig in paip gives some examples of small code and how it can be exceedingly clear.

Re: Impending kOS

#150

Post by icsa »

burntsushi wrote: post #120
geocar wrote: post #94

Earlier quoted context omitted.

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

It's not the wrong question. You just rephrased it. And in the process of doing so, you missed the point of my question. I emphasized the word "technical" because I was trying to politely ask for evidence. Evidence should be some combination of code, benchmarks and analysis. The code should provide isomorphic samples from the languages (or implementations of languages) that are being tested. Ideally, the code samples…

/ http://shootout.alioth.debian.org

http://kparc.com/z/comp.k

Post reply on HN