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

191–200 of 432 posts

Re: Stages of denial in encountering K

#191

Post by jstimpfle »

Athas wrote: post #126

People are so quick to reject K and APL-style languages for superficial reasons that they never get to the deep and interesting reasons! I am mostly familiar with APL, but I think the things I appreciate and dislike are about the same in K. One interesting philosophical difference, at least among some APL programmers, is that building abstractions should be avoided. TFA has a hint of that philosophy, in its suggestio…

> One interesting philosophical difference, at least among some APL programmers, building abstractions should be avoided

Humans need abstractions to think. What programmers need are abstractions that are not black boxes. I.e. can be opened.

Re: Stages of denial in encountering K

#192

Post by oblio »

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…

That's an interesting take on things. Another one would be that ~40-50 million programmers do things one way and ~10000 (totally random guess) do it another way :-)

Re: Stages of denial in encountering K

#193

Post by tkfu »

floatingatoll wrote: post #123
hasa wrote: post #68

Some people find entertaining from these extremely compact syntax languages. I have hard time to understand them, but such is life.

Regular expressions are a more concise way of writing string matching and extraction code, often exponentially more efficiently than without. They’re also usually more compact than spoken English can represent. For example, this proofreading regex detects possible issues in spelling: /(?<!c)i(?=e)/

That's a really bad proofreading regex, though, because it will be wrong more than a third of the time--which is much, much higher than the expected real spelling error rate. The "i before e except after c" rule only has a high success rate when you add the caveat that it only applies to words where the ie or ei makes the sound [i:] (like in "believe", for example), and that caveat isn't expressible via regex.

Re: Stages of denial in encountering K

#194

Post by magicalhippo »

kick wrote: post #92
kick wrote: post #91

Earlier quoted context omitted.

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

Ray-tracer: http://www.nsl.com/k/ray/raya.k

So how would this look like if it also needed to handle triangles? And we want textures, so we need texture coordinates and a way to specify per-object materials. Also, the original code just uses bounding spheres, we probably want something better like a kd-tree.

In the original code[1] these changes are trivial to make, even for someone new to the code base. How would they look in k? As others I struggle to see past the terseness, but maybe it would make more sense if I could see the program evolve.

[1]: https://web.archive.org/web/20070822025008/http://www.ffcons...

Re: Stages of denial in encountering K

#195

Post by chrispsn »

saagarjha wrote: post #139

Look, I don't hate K. It's probably a pretty good language for the task it seems to have been designed for, which appears to be numerical computing. Being able to fit an entire code on a screen is an interesting concept; while I'm not completely convinced it should be a goal in and of itself it's certainly something I can't rule out as a possible productivity booster. However, I still find it problematic, and it's no…

I started with Python and still miss its lazy generators. K's grain favours calculations that drive down long 'straights' of arrays without many conditional turns, but it's eager-first, which can be a drag for some problems (eg making a prime number generator object that I can take an arbitrary number of elements from lazily). Still, it hasn't been as bad as I feared.

I like the choices of primitives in K and the novel ways they can be combined to do things more efficiently (and with fewer pieces!) than you may expect. Good examples are 'where' (&), the grade twins (), scan (\), and eachprior (':).

I love the adverb syntax: each (') lets you map a function over a data structure with zero syntactic effort, and 'over' (/) and 'scan' (\) make reductions trivial.

With regards to an on-ramp, I started with John Earnest's oK REPL and did a bunch of Project Euler and Advent of Code problems. I then moved to trying to understand the examples on kparc.com. I then converted a spreadsheet application from JS to k7. In all of this, John's documentation was essential.

For me, having single variable names isn't paramount, but in some cases - particularly functions - I can see it helps to 'drive' your mind towards finding simpler ways to do things. It lets the characters that do the 'real' work come to the forefront.

Re: Stages of denial in encountering K

#196

Post by quelltext »

floatingatoll wrote: post #123
hasa wrote: post #68

Some people find entertaining from these extremely compact syntax languages. I have hard time to understand them, but such is life.

Regular expressions are a more concise way of writing string matching and extraction code, often exponentially more efficiently than without. They’re also usually more compact than spoken English can represent. For example, this proofreading regex detects possible issues in spelling: /(?<!c)i(?=e)/

Doesn't that regex detect correct spellings instead of wrong ones? I.e. it matches tier, tie, etc.

Re: Stages of denial in encountering K

#197

Post by LandR »

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.

Displays fine for me on my desktop.

I'm happy with just text.

Re: Stages of denial in encountering K

#198

Post by yiyus »

rgrs wrote: post #77

author ended article with > Leaning back in your chair, you think to yourself: > |/ what does this translate into?

Roughly:

    let max = list[0];
    for (let i = 0; i
With a|b, you get the maximum between a and b. / is reduction. So, |/list, will be equivalent to list[0]|list[1]|list[2]|...|list[n], i.e. the maximum value in the list.

Re: Stages of denial in encountering K

#199

Post by iateanapple »

goto11 wrote: post #136
dang wrote: post #107

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.

I doubt that K can reduce line count by a factor 1000 though. The examples in the article is mostly about shorter identifiers like "!" instead of "range" and a compact notation. That is perhaps a factor 5 not a factor 1000. The example with a for-loop for summing a range is a blatant strawman. In which modern language would that be idiomatic? Furthermore the examples only show a particular use case: Processing lists…

> That is perhaps a factor 5 not a factor 1000.

I’ve personally found 20-30x compared to Java - admittedly not the most compact language.

Re: Stages of denial in encountering K

#200

Post by jbotz »

7777fps wrote: post #149
buzzkillington wrote: post #129

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Write-only_language >Languages that are often derided as write-only include APL, Dynamic debugging technique (DDT), Perl,[2] Forth, Text Editor and Corrector (TECO),[3] Mathematica, IGOR Pro and regular expression syntax used in various languages.

You've got me wondering about the utility of a genuinely write-only language. As a thought experiment, would there be benefit to letting functions only be written once? No-one could come along and break code by changing a function. If you wanted to fix a bug in a function you would have to write a new copy and explicitly update callers to use the new version. A lot of maintenance overhead? Possibly, but tooling would…

This is exactly the main idea behind the Unison language.[1] All functions are immutable and identified by a hash rather than name. When you make any change you are creating a new function with a new hash. It's definitely a very interesting idea.

[1] https://www.unisonweb.org/

Post reply on HN