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

101–110 of 432 posts

Re: Stages of denial in encountering K

#101

Post by hmry »

rubyn00bie wrote: post #58

Only because earlier today I so definitely thought about the whole "code is a liability (debt)" reality we all live in... that is to say, I'm spit-balling here: but for once K makes me go "oh shit!" and not because of the craziness of its syntax... rather, if that syntax is so precise/terse, and even if to the outsider it looks fucking insane, does it have a wicked lower TCO because you literally have insanely less l…

The "amount" of code is the same as in any functional language though. It's just written in a smaller text file.

Re: Stages of denial in encountering K

#102

Post by TurboHaskal »

jes5199 wrote: post #9

the thing that's odd to me is that you could write this exact same post about other languages - a person who learns Haskell ends up writing that exact same range/reduce/plus statement. Modern lisps like Racket or Clojure take you there. Forth programmers and Joy programmers already noticed that their two languages had converged: and they'd write basically exactly this, too. Really, it's only the "mainstream" language…

A Common Lisp programmer would write it like that too. He would then disassemble the function, run away in terror and eventually come back to rewrite the whole thing with a more efficient loop expression.

Re: Stages of denial in encountering K

#103

Post by brazzy »

satokema wrote: post #71
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…

The article's point is a meta-point. Congratulations on actually being part of the meme in the article.

The article's point is dishonest smugassery. Congratulations on convincing people to avoid K for its community, if not the language itself.

Re: Stages of denial in encountering K

#104

Post by kick »

brazzy wrote: post #99
kick wrote: post #94

Earlier quoted context omitted.

Graphical spreadsheet application: http://www.nsl.com/papers/spreadsheet.htm

With 5 to 10 lines of comment per one line of code, it starts to become readable. You're still left constantly wondering "what do a and x mean in this context, again?" 3/10, would definitely not want to use for any kind of real work.

John Earnest links to his tutorial in the Stages of Denial post; if you click it and give it a read, you'll probably understand much easier.

But you shouldn't feel pressured to use k: people who advocate for k play the role of a Cassandra who can drown her tears in dollar bills.

Re: Stages of denial in encountering K

#105

Post by brazzy »

iateanapple wrote: post #82
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.

> I'm sorry, but that sounds like the juvenile fantasy of someone who is still in their programming puberty. For larger applications what PeCaN was saying still mostly holds true. I work on large (1-10 million loc systems) enterprise java code bases and write some side projects in k as a hobby. I can get the equivalent of around 30-40 java class files on screen at once with k. Even on poorly written enterprise code b…

...and in idiomatic K code, you apparently still need to constantly wonder what 'a' or 'X' means in your current context, with likely 5 different usages on your screen at once.

Re: Stages of denial in encountering K

#106

Post by kick »

brokensegue wrote: post #100
kick wrote: post #91

Earlier quoted context omitted.

XML parser: https://a.kx.com/a/k/examples/xml.k

is this like a code golf example? or what you expect "good" K to look like?

Which part do you not understand? In any case, raya.k is quite splendid. Did you check that one out? It's very clean and quite simple. (I linked to it right below that one.)

Re: Stages of denial in encountering K

#107

Post by dang »

A million-line program isn't readable by anybody, no matter how readable the language is. If the equivalent program can be written in, say, a thousand lines in some more concise language, that's more than worth the learning curve, even if the language is strange and off-putting.

Re: Stages of denial in encountering K

#108

Post by chrispsn »

hmry wrote: post #101
rubyn00bie wrote: post #58

Only because earlier today I so definitely thought about the whole "code is a liability (debt)" reality we all live in... that is to say, I'm spit-balling here: but for once K makes me go "oh shit!" and not because of the craziness of its syntax... rather, if that syntax is so precise/terse, and even if to the outsider it looks fucking insane, does it have a wicked lower TCO because you literally have insanely less l…

The "amount" of code is the same as in any functional language though. It's just written in a smaller text file.

Arthur tries to choose primitives carefully so that the amount of steps is smaller than other languages (see the 'product' quote in another comment). So even if you give each symbol an English name, the code will often end up smaller.

Re: Stages of denial in encountering K

#109

Post by neonate »

sklivvz1971 wrote: post #67

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.

That objection seems trivial.

Re: Stages of denial in encountering K

#110

Post by gerikson »

kstenerud wrote: post #84
chrispsn wrote: post #61

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

The readme examples remind me of Perl code. Example: print !~($/=$")+2*map 1..$s{$_%$'}++,

This one comment managed to insult both K and Perl coders...
Post reply on HN