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

331–340 of 432 posts

Re: Stages of denial in encountering K

#331

Post by geocar »

wpietri wrote: post #289
yiyus wrote: post #269

Earlier quoted context omitted.

Analogies are just analogies. The point of my comment was that you need to approach this with an open mind, forgetting what you already know from other languages. > Overly-concise code being difficult to maintain is a well-accepted fact. Your well-accepted facts do not apply to this totally different paradigm. You seem to think those well-accepted facts are universal. They are not. I have spent the last two years lea…

> The point of my comment was that you need to approach this with an open mind, forgetting what you already know from other languages. Why do I need to do that? I'm interested in solving problems for people, especially using computers. To do that, I need to build teams and build software. I need to think about costs and benefits, about longevity and sustainability. A great deal of that thinking is driven by the world…

> Why do I need to [approach this with an open mind]?

Because those are the standard terms of intellectual discussion. People going into such a conversation without an open mind are called idiots, and they're not worth taking too seriously.

> I need to think about costs and benefits, about longevity and sustainability

Isn't it weird that people don't value that?

I mean, look at how many python programmers are out there! I have programs written just five years old that don't work in a new python interpreter and that's terrible for "longevity and sustainability". Good thing there are so many cheap Python programmers so we can keep the costs down: We're going to be rewriting this thing until we're old and gray!

I personally find this line of thinking quite unproductive though.

> I know people who teach themselves Esperanto and Klingon, and they seem to have a good time.

Hey that's great. I know a few Go programmers too. Loads of fun those chaps.

If only Esperanto or Klingon or Go were useful in some way....

Re: Stages of denial in encountering K

#332

Post by Veedrac »

geocar wrote: post #308
Veedrac wrote: post #264

Earlier quoted context omitted.

Python 3.7+: Counter(elems).values() But we can play this game both ways. What's the K for (Counter(a) & Counter(b)).most_common(3)?

It's a little funny comparing a language with another language+plus-its-entire-ecosystem, but k fares remarkably well I think. Counter could be #:'=: (count each group) c:#:'=: Values would just be dot. Counter[x]&Counter[y] is a bit tricky to write, because while the documentation says set intersection, what they really mean is the set intersection of the keys with the lower of the values. This is entirely clear in…

> It's a little funny comparing a language with another language+plus-its-entire-ecosystem

This is pretty much my point: any ‘reimplement this weird built-in thing in $OTHER_LANG’ is going to involve overheads unless $OTHER_LANG also has that thing. I don't think keeping most types out of prelude should be a downside; you can always ‘from myprelude import * ’ if you disagree.

> How would you do this in Python?

I don't really know what "persists the unique index of f" means, but this seems similar to shelve. I can misuse that to give the same effect as what you showed.

    with shelve.open('x') as db: db.setdefault("f", len(db))
    >>> 0
    with shelve.open('x') as db: db.setdefault("g", len(db))
    >>> 1
    with shelve.open('x') as db: db.setdefault("h", len(db))
    >>> 2
    with shelve.open('x') as db: db.setdefault("f", len(db))
    >>> 0

Re: Stages of denial in encountering K

#333

Post by 7thaccount »

threatofrain wrote: post #323
7thaccount wrote: post #224

Earlier quoted context omitted.

Aaron Hsu writes about this a lot. In an APL snippet, you often don't need layers of blackbox abstractions. You can see the whole thing at a macro layer. I'm sure it takes time though.

Mathematics is also written tersely but not this tersely, and nor is terse math easy to read for mathematicians. Terse logic is also very different from terse names; how much of K brevity is just from name compression vs logical succinctness? Haskell people could also use single character names everywhere. When will they adopt the conveniences of fitting everything in as few pages as possible? And what’s the point of…

It's more than that though. APL symbols can operate on multi-dimensional data by default.

Re: Stages of denial in encountering K

#334

Post by BiteCode_dev »

snicker7 wrote: post #282

I use to program financial applications in K/Q for a stint. Very elegant and orthogonal language. And very well documented. One major issue I had with it and other APL-ish languages: lack of skimmability. I can easily skim thousands of lines of Perl and Java in seconds and have a rough idea of what the code does. Reading K, however, requires careful and deliberate attention to every single character. I found it usefu…

That's bad in my book.

I write a line once for a 100 times I read it.

Re: Stages of denial in encountering K

#336

Post by dang »

gjulianm wrote: post #212
dang wrote: post #127

Earlier quoted context omitted.

Single-letter identifiers are a natural thing to object to when coming from other language paradigms, i.e. nearly every programming background out there, but this is a category error. What seems ridiculous in one context can be sensible in another. The objection turns out to be parochial. It reminds me of how people think that parentheses are a significant aspect of Lisp, when in practice they're not. The parens look…

One or two characters for identifiers is optimal? What kind of programs are being written with APL/K? At some point you'll have more concepts in your program that available letters unless you're dealing with tiny programs.

The more experienced programmers in this thread can answer this better, but I believe top-level functions tend to get longer names.

Re: Stages of denial in encountering K

#337

Post by LessDmesg »

I have the same question for K aficionados as I have for Forth ones: what real-world, human-usable, important software has been written in it? A GUI framework, a web browser, a window manager, a text editor, etc. Anything?

I'm asking because the article is poking at C-like languages, i.e. implying that K is good for general-purpose use. Yet all I hear about is that K is good at multiplying numbers and matrices, which is a pretty limited playground.

Re: Stages of denial in encountering K

#338

Post by spopejoy »

7thaccount wrote: post #319
aw1621107 wrote: post #261

I've seen a few posts here and there over the years about array languages, but I can't recall any (or any discussion in their comments) that have mentioned any disadvantages beyond more human factors. So for the k/q/APL/array language gurus out there: in what situations would I not want to use k or another array language, if the relative obscurity of the syntax and mental model were not a factor (e.g., assuming you,…

Performance depending on your use case. APL/J/K can be very fast for an interpreted language, but they won't beat C, C++, Fortran, and Java in most cases. Also, think about distribution. With most of the array languages, it is commercial, so I'd be cautious about building a business around it. With other languages, it is free to use and deploy as you see fit and some have binary executables that don't need a runtime.…

> With most of the array languages, it is commercial, so I'd be cautious about building a business around it

K/Kdb/q seems very happy with this state of affairs, which is really strange: if they O/S'd it I could see a lot of goodwill/mindshare going their way, but I think their Morgan Stanley roots view O/S as commie nonsense. Meanwhile, it's definitely viewed as legacy in the bulge-bracket banks that use it b/c it's so hard to hire for, not to mention its limited applications for teams (kdb is NOT a good multi-user database). However elegant it may be, it's doomed to be a COBOL if this is where its main userbase stays.

J is open source, but I can't get a handle on how battle-tested it is. It always seemed like Kdb was the real product that got used in anger.

Personally I think array-heads should spend more time with Haskell, since it has the ability to be massively terse and point-free, has type inference, loves infix gobbledygook, can be tuned for great performance, and is thoroughly open-source.

Re: Stages of denial in encountering K

#339

Post by at_a_remove »

clarry wrote: post #335
at_a_remove wrote: post #317

My hat is off to the people who can handle this kind of thing; I myself cannot.

Do you really think you could not, even after taking a few weeks to study and practice?

Probably not, no.

I could easily see myself becoming dejected after printing out a few cheat sheets and buying some relevant books. I would have attempted some exercises and done whatever toy projects with an increasing feeling of dread that I was simply aping what was before me only to find what I thought I had learned had slipped away in a weekend. Should I get much further than that, I would then try to solve an actual problem I had with it and that would be the end of it as I would stagger into realms of development environments and dependencies to try to get the right libraries in order, I would look for advice online and tentatively ask questions only to be blasted for using the wrong dialect of whatever, or have my questions misconstrued until I could be informed that what I really have is an XY problem, I don't really want what I asked for after all. What a relief to me.

At that point I throw in my hat and go back to what I am used to.

I know myself well enough to know that I just haven't the grit or patience to torment myself with trying to find an application for the befunge du jour and, as such, learning it becomes a Glass Bead Game for me. If my life depended on it, perhaps, but this reminds me too much of the "executable line noise" I escaped: Perl, with a kind of sly terseness I associate with any number of obfuscations as a kind of puzzlebox monument to the "cleverness" of packing something into a single line I have had to slam into while programming.

I lack the vim to tilt at these windmills.

Re: Stages of denial in encountering K

#340

Post by kazinator »

gerikson wrote: post #207
Beltiras wrote: post #183

I went through a similar transformation when I finally understood LiSP. I knew Python and had programmed in it for several years but it was breaking into Scheme that changed my approach. I wonder if learning new paradigms always changes how you use other languages.

According to Peter Norvig, you were half-way to Lisp using Python: https://norvig.com/python-lisp.html

According to Guy Steele, if you're a C++ programmer using Java, you've been dragged halfway to Lisp.

https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/...

So by that estimate, if you switch to Python you're another halfway to Lisp (three quarters of the way from C++).

Post reply on HN