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

Stages of denial in encountering K

nsl.com

Post reply on HN
Print view View original

61–70 of 432 posts

Re: Stages of denial in encountering K

#61

Post by chrispsn »

From Arthur:

    design goal: speed
    write fast, run fast, modify fast.
    minimize product of vocabulary and program size.
https://a.kx.com/a/k/readme.txt

    comprehensive programming environments 
    (programming, files, comms, procs, ...)
    are depressingly complex.
    commonlisp, c/lib/syscalls, java, winapi
    are all in the 1000's of entry points.
    many with multiple complex parameters.
    with k we try to do more with less
    in order to write correct programs faster.
https://web.archive.org/web/20041024065350/http://www.kx.com...

    > Just curious, but does the state of California charge you a large tax
    > for each character in a variable name?
    
    yes.
    
    we also try to fit our algorithms onto licence plates.
https://web.archive.org/web/20040823040634/http://www.kx.com...

For some 'licence plate' K algorithm dissections, you might like this Twitter account:

https://twitter.com/kcodetweets

Re: Stages of denial in encountering K

#62

Post by [deleted] »

gallabytes wrote: post #60
kazinator wrote: post #44

> When the entire system fits in a page of code you can understand everything about it from the top down. I'm sorry, but that sounds like the juvenile fantasy of someone who is still in their programming puberty. Good luck fitting an operating system, web browser or air traffic control system into a page of code.

there almost certainly is an encoding such that every program any human will ever write fits in 128 bytes, though I doubt we'll ever design one. to convince yourself of this, notice that you don't expect to ever produce two programs with the same blake2 hash. there's a lot of room for improvement in conciseness of code. I would still be surprised if it was meaningfully possible to write a full-featured modern OS with…

[deleted]

Re: Stages of denial in encountering K

#63

Post by kick »

kazinator wrote: post #53
kick wrote: post #23

Earlier quoted context omitted.

If you don't know the language, you won't be writing, editing or improving code in it anyway. Your test is therefore irrelevant for programming languages.

If people don't know a language, yet find it readable, they are more likely to end up getting involved in doing those things. Poor readability is not a good way to keep people out; you're not selecting for talent.

If the language is readable beforehand, but brings a 30% productivity decrease to those proficient in it compared to what they could have with one that wasn't, even the best programmer will be mediocre.

Further, the best have had a long history of finding APL and derivatives appealing: Ken Thompson? Liked APL. Alan Perlis? Loved APL. Rob Pike? Has spent years on an APL interpreter.

APL isn't lacking fantastic programmers.

k has shipped with a Python-like sugar layer for years now (q). Readable to most, but without the notational value, much is lost.

Q'Nial (one of my favorite programming languages) is readable by most. It's very verbose, but by all means an APL-derivative. It's not as useful a tool as one with notational benefit, and never attracted much interest.

Anyone close-minded enough to ignore something entirely because they don't understand it at first isn't likely "top talent."

Re: Stages of denial in encountering K

#64

Post by kazinator »

gallabytes wrote: post #60
kazinator wrote: post #44

> When the entire system fits in a page of code you can understand everything about it from the top down. I'm sorry, but that sounds like the juvenile fantasy of someone who is still in their programming puberty. Good luck fitting an operating system, web browser or air traffic control system into a page of code.

there almost certainly is an encoding such that every program any human will ever write fits in 128 bytes, though I doubt we'll ever design one. to convince yourself of this, notice that you don't expect to ever produce two programs with the same blake2 hash. there's a lot of room for improvement in conciseness of code. I would still be surprised if it was meaningfully possible to write a full-featured modern OS with…

Hashes do not encode; to convince yourself of this, try to recover a program from it blake2 hash.

Re: Stages of denial in encountering K

#65

Post by keymone »

saagarjha wrote: post #48
keymone wrote: post #34

Earlier quoted context omitted.

As I understand author’s point, your example with “sum” is only valid because “sum” word has very few meanings, especially in software engineering world. Even the word “product” would introduce certain ambiguity in context of real world codebase: is it “math” product or some “domain” product? It’s even worse with most other words. So if in any given codebase you still have to know the specific meaning of every word,…

> “sum” word has very few meanings, especially in software engineering world Sum types, checksums, …

That’s why I said “few”, not “one”?

Re: Stages of denial in encountering K

#66

Post by bryanrasmussen »

Veedrac wrote: post #56

K +/!100 Python sum(range(100)) Haskell sum [0..99] Rust (0..100).sum() Ruby (0..99).sum There are plenty of ultra-concise languages for toy problems like these; they are called ‘golfing languages’. Ultimately it's a bit pointless since most of the time people aren't playing code golf. (The issue with setting everything to obscure ultra-compressed keywords isn't that it's not possible to learn those keywords , but th…

Well I guess I agree with this statement, except that I don't think K is primarily used for solving toy problems.

Re: Stages of denial in encountering K

#67

Post by sklivvz1971 »

The irony of claiming to represent a readable language, that others are in denial of reality about this, and presenting your thesis on a '90s looking website with typographic lines spanning almost 400 chars at 100% width...

ABTASTTSBMR than the whole sentence. OK.

Re: Stages of denial in encountering K

#70

Post by Kwantuum »

Veedrac wrote: post #56

K +/!100 Python sum(range(100)) Haskell sum [0..99] Rust (0..100).sum() Ruby (0..99).sum There are plenty of ultra-concise languages for toy problems like these; they are called ‘golfing languages’. Ultimately it's a bit pointless since most of the time people aren't playing code golf. (The issue with setting everything to obscure ultra-compressed keywords isn't that it's not possible to learn those keywords , but th…

Except in K all the idioms are laid flat. As pointed out in the article, the K code is the equivalent of range(100).reduce(operator.add), it encapsulates the entire meaning, there is no need for an intermediate function definition because that would be longer than the code itself.
Post reply on HN