Stages of denial in encountering K • Hacker News Board

Re: Stages of denial in encountering K

#371

Post by kazinator » Mon, Mar 09, 2020, 10:33 PM UTC

geocar wrote: post #249

neo2006 wrote: post #243

Earlier quoted context omitted.

Moreover if I need to keep in my head the corresponding concepts for all of this symbols, it's like learning a new natural language. We sometimes forget that one of the most important feature programming f language is to unburden the programmer from the language it self and get him to focus on the concepts. I also don't see the point of optimizing on the number of line of code if the complexity per character is incre…

> I also don't see the point of optimizing on the number of line of code if the complexity per character is increased (did I just invented a kpi here?) It doesn't increase linearly though. #:'=: is seven characters that mean as much as 68 separate lexemes in lisp: (defun count (list) (let ((hash (make-hash-table))) (dolist (el list) (incf (gethash (cadr el) hash 0) (car el))) (let (result) (maphash (lambda (key val)…

That's just using nothing but the features of ANSI Lisp, which was at the time of its standardization already criticized for being large and facing pressure to stay small.

The hashing stuff feels a little "bolted on" in ANSI CL. Add-on libraries can round out the functionality.

In another dialect, TXR Lisp, the whole (let ...) part above reduces to this:

   (hash-pairs hash) ;; get key-value pairs as two-element lists

such a function could be had in ANSI Lisp.

To reduce a sequence into a histogram returned as a hash in TXR Lisp, we would do a group-reduce

   [group-reduce (hash) identity (op succ @1) INPUT-LIST-HERE 0]

The idea here is that the input items are projected through a function (here specified as identity, to take the items themselves) and grouped into buckets by the projected value.

Within each of these buckets, an independent reduce (i.e. left fold) is going on, whereby a hash table holds the reduce accumulators.

For maximum flexibility, group-reduce asks the caller to specify the hash table rather than making one implicitly; hence the (hash) argument.

Likewise, the initial value for the reduce (shared by all the buckets) is specified explicitly. reduce is too general a concept to justify making it a defaulted optional argument that goes to zero.

Here, we somehow abuse reduce. We start the accumulator at 0, and at each reduction step, we ignore the new value coming in, and instead produce the successor of the accumulator as the new accumulator value, so all we do is count the reduction steps in each bucket, thus producing a frequency histogram.

(op succ @1) is needed rather than succ because the function it denotes takes two or more arguments (it gets called with two), whereas succ requires exactly one argument. If succ ignored arguments after the first one, it could be like this:

  [group-reduce (hash) identity succ INPUT-LIST-HERE 0]

But relaxing the checks on the number of arguments in library functions for the sake of code golfing isn't a good idea. Further, if the function constructed the hash implicitly, and geared toward numeric processing, making the default accumulator zero, it could look like:

  [group-reduce identity succ INPUT-LIST-HERE]

and if we cripple group-reduce by taking out the projection we can get it down to:

  [group-reduce succ INPUT-LIST-HERE]

Basically, Lisp can be succinct to the point of diminishing returns, if you have the right set of functions for the task at hand.

The traditional, mainstream Lisps assume that the developers will make these for themselves, especially for tasks outside of list processing.

Re: Stages of denial in encountering K

#372

Post by spopejoy » Mon, Mar 09, 2020, 10:35 PM UTC

7thaccount wrote: post #363

spopejoy wrote: post #338

Earlier quoted context omitted.

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

I'm not an expert in either language, but have played with both and APL is much easier to experiment with and less hard for me to grok than Haskell. Both have REPLs, but there is a lot of additional ceremony with Haskell (for good and bad). I don't see a huge amount of the APL crowd going to Haskell. Yeah it has terse operators and points-free, but it is more the sum of the whole kind of thing.

I agree and don't mean to imply Haskell has an out-of-the-box K/APL experience. More that with it's syntactic flexibility, one can imagine offering a k-like DSL/library in Haskell which would then give you access to its ecosystem, freely distributable apps, etc.

Re: Stages of denial in encountering K

#373

Post by wglb » Mon, Mar 09, 2020, 11:03 PM UTC

kazinator wrote: post #340

gerikson wrote: post #207

Earlier quoted context omitted.

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++).

I could never figure out how Java is in any sense halfway to Lisp.

Python, maybe.

Re: Stages of denial in encountering K

#374

Post by skybrian » Mon, Mar 09, 2020, 11:24 PM UTC

geocar wrote: post #309

skybrian wrote: post #295

Earlier quoted context omitted.

If the comments were good (more like you wrote) then the ratio of comments to text would be even higher. And as with writing assembly, the risk of comments getting out of sync with the code is higher, too.

Thank you. The narration is what happens in my brain when I read it. I don't need it in the source files. Keeping the file short is the best way to keep it consistent (what you refer to "getting out of sync")

This seems similar to how Unix commands have both short and long names for flags. Single-character flags are easier to type, but also easier to mistype or misread since there is less redundancy.

It seems like K would be a particularly suitable language for having more than one syntax. The short syntax, once you get used to it, would be better for keyboard input and expert whiteboard discussions, but it might also be nice if there were also a standard syntax that was longer and closer to what most people expect? An editor could automatically translate between short and long syntax, and this would be helpful for making sure you typed what you think you did.

Re: Stages of denial in encountering K

#375

Post by kick » Mon, Mar 09, 2020, 11:27 PM UTC

spopejoy wrote: post #338

7thaccount wrote: post #319

Earlier quoted context omitted.

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…

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

It's not too hard to grok: if they freed it, they'd lose money. $200,000,000 in revenue last year from Kx alone. Goodwill compared to cash, executive picks cash every time.

I have no idea what Shakti's doing, but they, too, are probably making a substantial amount of money.

Re: Stages of denial in encountering K

#376

Post by wpietri » Mon, Mar 09, 2020, 11:42 PM UTC

geocar wrote: post #331

wpietri wrote: post #289

Earlier quoted context omitted.

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

You omitted a key piece of what I said. If you'd like to answer the question I actually asked, feel free. Bonus points if you demonstrate the values you claim to champion here, like open-mindedness and eagerness for sincere discussion.

Re: Stages of denial in encountering K

#377

Post by AnimalMuppet » Mon, Mar 09, 2020, 11:47 PM UTC

geocar wrote: post #331

wpietri wrote: post #289

Earlier quoted context omitted.

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

If you think Go is less useful than K, you might need to get out more. At least, it is actually used more than K is.

Re: Stages of denial in encountering K

#378

Post by lioeters » Tue, Mar 10, 2020, 12:50 AM UTC

smallnamespace wrote: post #241

yiyus wrote: post #187

Earlier quoted context omitted.

I love small languages (lisps, forths, apls) and think that there is much to learn from them, but you need an open mind. You need to start from zero and totally forget your ALGOL-mindset while you are learning the new paradigm. It's like learning Chinese. Everyone learns it in China, and everyone there will tell you that it's perfectly readable and you don't need to be extraordinarily intelligent to speak it. But if…

> Everyone learns it in China, and everyone there will tell you that it's perfectly readable and you don't need to be extraordinarily intelligent to speak it. I'm not sure Chinese is necessarily a good example for the point you're trying to make. Native Chinese speakers _probably_ spend more effort acquiring full competency in Chinese than native English speakers need to learn English. For one thing, reading and writ…

> English is generally easier to learn..for most people in the world

Ohoh, this line sparked a thought in my head:

"English is the JavaScript of human languages."

> ..slowly lost it's more difficult native features

That may be true of creole and English spoken as a second language (which, I believe, is more dominant in the world than English spoken by natives). Maybe also true about losing inflections, thank goodness, that surely must have made the language easier.

On the other hand, English as spoken by natives do contain plenty of quirks, exceptions, phrases that don't make sense explicitly (with implicit meaning you have to have learned/memorized)..

Re: Stages of denial in encountering K

#379

Post by 7thaccount » Tue, Mar 10, 2020, 1:52 AM UTC

kick wrote: post #375

spopejoy wrote: post #338

Earlier quoted context omitted.

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

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 It's not too hard to grok: if they freed it, they'd lose money. $200,000,000 in revenue last year from Kx alone. Goodwill compared to cash, executive picks cash every time. I have no idea what Shakti's doing, but they, too, are probably making a substantial amount of m…

This is the annoying thing about this software niche. I have zero information on Shakti. Their website just says some buzzwords and has a contact link. You can download it as an anaconda package or something, but I don't understand the license.

Re: Stages of denial in encountering K

#380

Post by 7thaccount » Tue, Mar 10, 2020, 1:55 AM UTC

spopejoy wrote: post #372

7thaccount wrote: post #363

Earlier quoted context omitted.

I'm not an expert in either language, but have played with both and APL is much easier to experiment with and less hard for me to grok than Haskell. Both have REPLs, but there is a lot of additional ceremony with Haskell (for good and bad). I don't see a huge amount of the APL crowd going to Haskell. Yeah it has terse operators and points-free, but it is more the sum of the whole kind of thing.

I agree and don't mean to imply Haskell has an out-of-the-box K/APL experience. More that with it's syntactic flexibility, one can imagine offering a k-like DSL/library in Haskell which would then give you access to its ecosystem, freely distributable apps, etc.

No problem and I like you're thinking, but honestly just want a free and open source APL or K language that is part of a lightweight download (a few MB) that can also create zero install executables that bundle the interpreter. There are a lot of toy projects out there, but nothing really close to what I want. I'd build it myself if I had the time and was significantly more talented :).