Hacker News Reader

Comment by saagarjha | Hacker News Reader

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 not really about the language itself: it's more about how it's promoted in the article, by the people in this thread, and in general. Specifically, the claims it's perfectly readable, and anyone who says anything otherwise is either stupid, lying, or too poor to understand it are not useful. (Yes, you know who you are for that last one. You're not helping your case.) The fact of the matter is that most programmers are used to ALGOL-esque syntax, and there is significant value in being able to lift concepts and interoperate between those languages at a superficial level. Every "inspired" languages hits these issues, depending on how "strange" it is: Objective-C is ugly, Lisp is alien, and on the far end APL derivatives are simply labelled as unreadable. That doesn't mean they're bad languages, but to those promoting it: drop the attitude, and understand why we have reservations. Your language isn't the "true" way to program, that only the chosen elect can understand and lecture us on. Don't ignore or gloss over languages that have similar features to yours. We want to hear what the interesting things are that you can do in the language, actual guidance for how we can adapt to the language (not: "one-letter identifiers are just what we do; deal with it"). Thanks.

View on HN

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 you expect to figure it out based on your knowledge of English, it will be terribly frustrating. This does not mean that German or Dutch (which share roots with English) are better languages, or even easier to learn. Do not expect your Chinese teacher to give you a different answer from "these weird symbols are just what we do; deal with it".

This article is quite good. Clearly the author understand your reservations and he is saying: give it a try and it will click. The learning material might be better, but it's there (start with Iverson and work from that). It's much easier than 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.

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 writing is harder to learn, even for natives (source: am Chinese and haven't acquired full literacy, despite years of half-hearted effort).

English is generally easier to learn, not only for German and Dutch speakers, but for most people in the world who speak languages that are unrelated to both of them.

One hypothesis[1] is that English has been learned by foreigners multiple times in the past and slowly lost it's more difficult native features (noun declension, many forms of inflection). Chinese has tones, which are rare amongst world languages and, as many learners will tell you, difficult to achieve proficiency with as as an adult.

On a practical level, the British and Americans have had hegemonic influence over the world for about 2-3 centuries, so many idioms and concepts in the language will be familiar to a learner; less so Chinese, which is far more coupled to the culture of China and its history.

Like, every schoolchild in China learns a bit of Tang poetry as part of their education, and 成語 idioms are part of daily speech across all social classes.

https://en.wikipedia.org/wiki/Middle_English_creole_hypothes...

> hypothesis[1] is that English has been learned by foreigners multiple times in the past and slowly lost it's more difficult native features (noun declension, many forms of inflection).

The claim that noun declension and inflection is harder to learn isn't well founded. If your native language has these, it'll be more natural for you. All languages have semantic declension and inflection, in the sense that context signals the kind of each word even if it's not syntactically inflected. For example in English the position of the word can signal whether a word is an object or subject "John hit Sally" vs "Sally hit John", the order of John and Sally signals who hit whom. In an agglutinate language you could signal this by putting a prefix like "John hit Sallyum" or "Sallyum hit John" would be parsed the same. My native language is Turkish, I've been learning English since I was 5 years old, but this "order matters" thing eternally confused me. It doesn't make sense to me when people say suffixes are more confusing than this order thing.

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

Lisps (the real ones, at least that rightfully use the name) do not belong into this lunatic fringe category; they support Algol-style programming. Aside from the prefix syntax, a lot of the concepts are familiar.

Microsoft's sample application "Your First Windows Program", written in C, using Win32 calls, can be translated into TXR Lisp literally, almost expression for expression:

https://docs.microsoft.com/en-us/windows/win32/learnwin32/yo...

The "meat" part, without the FFI declarations that precede it:

  (defun WindowProc (hwnd uMsg wParam lParam)
    (caseql* uMsg
      (WM_DESTROY
        (PostQuitMessage 0)
        0)
      (WM_PAINT
        (let* ((ps (new PAINTSTRUCT))
               (hdc (BeginPaint hwnd ps)))
          (FillRect hdc ps.rcPaint (cptr-int (succ COLOR_WINDOW) 'HBRUSH))
          (EndPaint hwnd ps)
          0))
      (t (DefWindowProc hwnd uMsg wParam lParam))))

  (let* ((hInstance (GetModuleHandle nil))
         (wc (new WNDCLASS
                  lpfnWndProc [wndproc-fn WindowProc]
                  hInstance hInstance
                  lpszClassName "Sample Window Class")))
    (RegisterClass wc)
    (let ((hwnd (CreateWindowEx 0 wc.lpszClassName "Learn to Program Windows"
                                WS_OVERLAPPEDWINDOW
                                CW_USEDEFAULT CW_USEDEFAULT
                                CW_USEDEFAULT CW_USEDEFAULT
                                NULL NULL hInstance NULL)))
      (unless (equal hwnd NULL)
        (ShowWindow hwnd SW_SHOWDEFAULT)

        (let ((msg (new MSG)))
          (while (GetMessage msg NULL 0 0)
            (TranslateMessage msg)
            (DispatchMessage msg))))))

Full code here: https://www.nongnu.org/txr/rosetta-solutions-main.html#Windo...

If you look at this and the C side by side, you can easily see where the parts match up.

That's a very convenient analogy for your argument, but it doesn't make sense for programming languages in general.

It's not really meaningful to compare the readability of sentences in English versus Chinese. On the other hand, it's both meaningful and important to compare readability of program snippets - and readability is more than just the first-time learning burden.

Overly-concise code being difficult to maintain is a well-accepted fact. The response shouldn't be to demand fluency - that's just sticking your head in the sand.

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 learning about array languages and think it is a fascinating topic, so I tried to give some advice (based on my own experience) to those who want to make the same journey. My point is not that you need fluency (you need some fluency to understand anything complicated), it is that the fluency you have in other languages may be counterproductive. Your comment is an excellent example of this.

Try to read a tutorial. Rewrite it using "meaningful names". All we have done that at some point, and all we started finding the sort names more comfortable to work with after a while. Don't take my word, give it a try.

> 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 as it is, by the historical accidents that have gotten us to where we are.

If this is a recreational activity, not meant to be practical, then great. I know people who teach themselves Esperanto and Klingon, and they seem to have a good time. Extreme Ironing looks fun, too. But if it's going to have some bearing on my profession, then I'm unlikely to forget what I already know, because in practice the people I will work with already know quite a bit, and brains being what they are, they won't be forgetting it.

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

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.

How did he not answer the question?

You asked why you should keep an open mind when encountering and talking about a strange language. He pointed out that it's necessary for a good discussion on it. He's not wrong.

You've dismissed every point he made while not knowing a single thing about the topic at hand. That's not grounds for a proper discussion.

That is not what I asked.

What I'm responding to in the thread is a question of pragmatism. In particular, I'm taking issue with the notion that one can only approach this "forgetting what you already know from other languages".

That's very much distinct from the notion of an open mind. And it's especially distinct when we're talking about tools that must fit into a professional context that involves decades of history, millions of people, and a complicated set of economic factors.

For example, Imagine that you were working in a machine shop and I came to you excited about a new screw-head. If you dismissed it out of hand, I might ask you to keep an open mind while I explained why I thought it was better. But if my explanation ignored that the Phillips head was the dominant choice, with billions of drivers and hundreds of billions or perhaps trillions of screws in existence, that would be another thing entirely.

The same logic applies to conlangs like Esperanto and Klingon. Is it possible it would be better if we switched the whole world to Klingon? Sure. Might I learn interesting concepts if I studied Klingon? It's possible. Should Klingon be considered for a moment as an important thing for most people to learn? No, not at all. It's utterly impractical.

So yes, keeping an open mind is valuable. But that's not something I've ever heard seriously disputed, so editing me down to saying that is constructing a straw man. Which also isn't grounds for a proper discussion.

I read the sum of wpietri's question as saying "so sell K then". As a reader I then looked on to what might be a better selling of K than all the comments I've read so far.

Instead I found silly prose examination.

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.

> Overly-concise code being difficult to maintain is a well-accepted fact.

Many seasoned APL/J/K programmers state that conciseness is an asset. I would trust their judgment on that. There are ways in which that and the quoted statement could both be true at the same time.

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 fitting as much content as you can into one eyeball when working memory can’t consume a whole page of a non-succinct language like Python?

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

Layers of abstractions are useful though, they allow you to concentrate on what matters for the code in question.

In many cases I'd agree, but the author I'm referring to has a neat example. His APL GPU compiler doesn't have modules and multiple layers of abstractions. He has few named variables. Just a few pages of entirely data flow/parallel APL where you can see everything at the macro level. He did a show HN and several YouTube lectures on this. The abstractions hurt the ability to understand the code and made it take longer to make changes.

> It's not really meaningful to compare the readability of sentences in English versus Chinese.

it is if one speaks both languages and is qualified to comment. part of 'overconciseness' is domain/cultural experience - what is overconcise in one context is not in another.

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 (< and >), 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.

If you're going to use a language (call it X; we're not just talking about K), then you really have to know X's syntax and primitives. There's just no other way.

You also would be much better off learning X's idioms. These are standard ways of saying something. They're standard for a reason - because they work, and because everybody understands them. If you can't read them, then a lot of code is going to be difficult to understand.

That's just table stakes for using X. If you want to use X, but don't want to learn the syntax and the primitives, then you don't really want to use X. You may want the benefits that you think X would get you, but you don't actually want X.

Now for the other side: If you're a proponent of X, you need to remember that many languages are magic within certain domains, and anywhere from "meh" to horrible outside it. Take K, for instance. I'm pretty sure it wouldn't be a good fit for most embedded systems. I'm fairly sure it wouldn't be a good fit for web programming. I'm not sure I'd want to do text processing in K. So it's not "the one way" (except possibly within certain domains). It's not "the way of the future" (except possibly within certain domains). It's not "what all the smart and enlightened people are using" (except possibly within certain domains). And, unless we're working in those certain domains, it really isn't all that important whether the rest of us learn it or understand it.

The one specific concern I have is that some languages are readable without you knowing about the language's syntax and primitives, because it apes them from somewhere else; K is different and thus you can't apply your past knowledge to read it like you might usually be able to do.

That's fair. On the other hand, if a language is from a different paradigm than mainstream languages, there's not much "aping from somewhere else" that can be done. I mean, K could ape things from APL, but that doesn't help most of us. (I guess it helps those that know APL...)

I suspect that looking like C or ALGOL would not be all that useful for K (or Lisp, or Haskell, or Forth). The semantics are too different. A surface similarity in syntax isn't enough to bridge the gap in a meaningful way.

> the claims it's perfectly readable, and anyone who says anything otherwise is either stupid, lying, or too poor to understand it are not useful.

Yes: It is perfectly readable once you know how, and anyone who says anything otherwise is just plain wrong. Including you 58 days ago.

I don't know if you are wrong because you are lying, or you believe this because you are stupid. I wrote off at the time that it was well-meaning ignorance, but it doesn't really matter: The key thing, that is, the thing holding you back from reading it, is you.

I believe you can learn to read it and read it as well as me as quickly as with a few months of study. If you think anyone else is telling you otherwise, ignore them.

I don't believe you need to not be "poor" to do it - everything you need is available to you.

It's all about whether you want to do this or not.

> Every "inspired" languages hits these issues, depending on how "strange" it is: Objective-C is ugly, Lisp is alien, and on the far end APL derivatives are simply labelled as unreadable. That doesn't mean they're bad languages, but to those promoting it: drop the attitude, and understand why we have reservations.

We understand because we were once you: Every X-evangelist you're talking to (where X is Lisp, or Objective-C, or in this case K) was once like you in at least the way of not knowing X, so we know you are wrong in a way (as we now know X) that you simply cannot comprehend yet. Think about that. Maybe re-read Paul Graham's blub article and appreciate really what it means to be the blub programmer.

Many K programmers have some familiarity with APL. Some (like myself) have used Objective-C and Common Lisp (I've got over a decade of professional history in CL), and loads of other languages. Until you learn K, all you have is our testimony; our gospel that this is worth learning. You can literally do anything in blub, being able to do it easier is the point.

Take a break from K (or any other shorthand language of your choosing) for a year or five, then come back and try to figure out what the code you wrote when you were using it frequently is actually doing.

Now do the same with well-written, verbose C-style or Python code (no shorthand/abbreviations, no lambdas, no ternary notation, etc.).

Shorthand code in any language is bad in the long run because it's unmaintainable except by people who work with it on a regular basis. You are making the same arguments as Perl fanatics who used every possible abbreviation in their language 25 years ago. How much of that is even comprehensible now without a major reverse-engineering effort?

> You are making the same arguments as Perl fanatics who used every possible abbreviation in their language 25 years ago. How much of that is even comprehensible now without a major reverse-engineering effort?

Perl is inscrutable in a different way: It is impossible to insert an instruction reliably into a statement allows the student to observe what is going on without changing it: Program flow can change mid-sentence. This isn't true of K.

> Take a break from K (or any other shorthand language of your choosing) for a year or five, then come back and try to figure out what the code you wrote when you were using it frequently is actually doing.

I've been looking at K code for more than five years at this point, and I don't have any problems reading code written by K programmers a decade ago or more.

I think you're completely wrong about this.

> I've been looking at K code for more than five years at this point, and I don't have any problems reading code written by K programmers a decade ago or more.

I think you're completely missing the point here. The assumption wasn't that old code is unreadable, but that you have trouble understanding it after NOT looking at ANY K code for five years.

If that's true it's a trade-off which may or may not be worth it. It's not inherently bad or unacceptable.

Many other skills require a period of re-learning after a five year gap. Where do you believe K sits on the scale of re-learning effort involved, riding-a-bike seconds to minutes, or months to years of effort?

I've only learned a little APL so far, and that really didn't take much effort so I'd be surprised if it would take me more than a month of dedicated learning to get fluent in the language. If that's what it takes to learn from scratch (the language, not the concepts common to maths and many programming languages), I would expect re-learning to be possible in less than a week. That does not strike me as too big an obstacle in many cases.

> I think you're completely missing the point here. The assumption wasn't that old code is unreadable, but that you have trouble understanding it after NOT looking at ANY K code for five years.

Fair enough.

I don't see any evidence why that would be true, or even more true than other languages.

Do you have any?

I don't have a horse in the race here but guess that a big part would be things like single-character identifiers rather than descriptive names.

A slightly weaker but maybe more realistic example, albeit in mathy terms: pick a language L from the set of all programming languages as your next language, according to a probability distribution of commonality of use in 2020 or so, possibly skewed for your field/interests, and work on it exclusively for 5 years.

If your initial language (before L) was K, you're not terribly likely to have picked a successor language that has any relation to K. If your initial language was C, your successor is likely ALGOL-like, and you probably won't have rewired your brain totally. So coming back to old work after 5 years will likely be less of a shock.

Granted, this is like saying "k is different!", but it ties it to a real-world situation where it could even bother a dedicated k programmer.

I think that's an interesting experiment, but I don't believe it will produce the results you predict: I haven't written in Postscript for over ten years, but I just picked up some random postscript code and have no problem reading it. Why would I expect other programmers to be different in this regard?

However even if it's true for most programmers, why does this definition of "readability" have value?

It's a fair point that you have that ability and hope others will too. They might! I don't know that I would, but I might! I'm pretty stupid sometimes though.

My other comment on the nearby thread likely best-addresses why I think coming back "cold" is useful, based on an assumption that being a novice and being cold are similar, and maybe they're not.

With regard to picking up postscript specifically: I'm not intimately familiar with the language, but the bits I found in a quick search look a) less approachable than javascript to me, so fair point on that, but b) somewhat algol-like. At a glance I felt like I could pick up the flow-of-execution without a lot of work, though I could be wrong.

If it is kind of algol-like, I feel like that plays in favour of my argument a bit -- algol-like languages are so ubiquitous as to be hard to really not use the mental model for 5 years, so we're probably not really coming in "cold" to one.

Postscript is a concatenative (stack-based) language, not algol-like at all. Just as array languages, concatenative ones are terse and regular, but reversed (left-to-right evaluation instead of right-to-left).

In my opinion, it is a fair comparison.

> Do you have any?

Excellent question! Personally, I'd argue that a language cannot be viewed in isolation from the problems it's trying to solve.

5 years ago I maintained decades old HLASM programs for IBM mainframes during a consulting gig and haven't touched anything like it since.

I'd have very little issues reading and understanding the source code today. I couldn't say the same about the domain logic and business processes behind it, because it was very specific to the company and I worked in a totally different field since then.

This leads me to think that it's a combination of working with similar languages or in comparable application domains that makes coming back "cold" easier.

IMHO people tend to underestimate the influence of domain knowledge in the programming world and greatly overestimate the value of particular language and framework choices...

> Excellent question! Personally, I'd argue that a language cannot be viewed in isolation from the problems it's trying to solve.

I'm not sure I'd agree with that, at least not entirely.

A language is a tool for thinking. It doesn't solve problems by itself, but it is a good language if it makes thinking easier. k is a great tool for thinking! With only 25 (or so) easily accessible symbols, it's amazing we got about a hundred primitive operations out of them, but what's really incredible is how tastefully Arthur selected those primitive operations such that the symbol could indicate an entire class of operations.

Some work well: - means subtraction and negation. Others are cute: < means grade (ascending) and less-than (and the grade of a grade turns out to be pretty useful!). Some are (however) unfortunate: + means flip and addition (which aren't the same thing at all), and I don't think + would be flip if flipping wasn't so useful.

And it's the tool that matters to me: I don't think I ever used array_flip in php until I learned flip in k, and now it's "obvious" (although PHP's array_flip is limited to a single use-case and requires other functions for other use cases, oh well). And I'll probably know how flip works until the day I die, and if I need it (in another language), I'll probably just make it again.

The tool has survived! And it's the tool that I go rooting in languages to find.

Lisp and Erlang have some really great tools (concepts) like this.

> 5 years ago I maintained decades old HLASM programs for IBM mainframes during a consulting gig and haven't touched anything like it since.

How funny!

I've had almost the same exposure to HLASM (although it was more than a decade ago)- consulting gig, never again. Any language designer who thinks comments can begin only on the first column needs to be taken out and shot.

However I think having to refresh myself on exactly how BALR works, or what types dyadic ! takes isn't going to waste much time. Are these real concerns you have about forgetting the tools you learn?

> I believe you can learn to read it and read it as well as me as quickly as with a few months of study.

Then it's not perfectly readable. That, or your definition of readable is useless because then any programming language is readable given enough study time.

> being able to do it easier is the point.

I still haven't seen any example where it is actually easier. Shorter? Yes. Easier? Very debatable.

> Then it's not perfectly readable. That, or your definition of readable is useless because then any programming language is readable given enough study time.

Given a fragment of Chinese, if you do not know Chinese, would you say it is unreadable?

What possible definition of "unreadable" could you have that would make that a useful statement?

No, I don't think speaking to a language as being "unreadable" is particularly helpful. A very careful reader might interpret your claim that "K is unreadable" as "gjulianm can't read K" but I wonder what exactly is the point of even saying it in the first place? Maybe you mean "approachable" -- a fully reasonable statement, but one reflecting your inability to say anything else meaningful about it.

On the other hand, if I know Chinese, it's entirely possible for me to point to a gibberish statement (for example, on a tattoo), and say that it's unreadable. I'm definitely referring to something else here.

Now maybe we just accept having two different definitions for "readable", but I think yours has real harm. I think referring to something that you do not understand with the same word that means nobody can understand it might confuse people, and I just cannot understand for the life of me, why so many programmers would want to intentionally confuse people like this.

If I pick up some random K code, I can read it. I could make a change to it, and other K programmers will understand what I did and why. That's good enough for me.

> I still haven't seen any example where it is actually easier. Shorter? Yes. Easier? Very debatable.

I think the max of list example is a good one. I've also previously observed some examples that might be less mathematical.

[1]: https://news.ycombinator.com/item?id=22467866 - Here I beat a custom "database" by 50x with one line of q (a very similar language to k)

[2]: https://news.ycombinator.com/item?id=21799376 - A six-character solution to the rock-paper-scissors game, using q to analyse the creation of the solution

[3]: https://news.ycombinator.com/item?id=21680743 - Here's our friend the bin operator again, showing how it appears in production.

[4]: https://news.ycombinator.com/item?id=19659590 - One of my favourite k/q features is views.

[5]: https://news.ycombinator.com/item?id=16851862 - String parsing is "obvious" in k/q where it isn't in other languages

In these cases (and many others) q/k is "easier" because it gets the job done faster. If you can beat my k with your JavaScript then good for you (And I'd like to see it! I can always get better!), but I usually can't. I find the solution faster with k, the program runs faster with k, and those are the things that matter to me when I say "easier".

I absolutely do not mean "more approachable".

Sorry to start popping up on all of your threads!

Your points are really good here, and writing code that runs faster and finding a solution yourself faster are clear wins for a language. I think the value of those wins is subjective, though.

If you need speed of execution, or if you're working in a green-field scenario and need to get your work done super fast, your wins are the most valuable ones.

But for example, if you work on a CRUD application that handles edge cases for specific customers that someone wrote 11 years ago when you used a different ORM but that still matter today, concision and execution speed aren't really the triumphal traits of the code. Clarity to others who may not be as well-versed as I am is the key thing I care about.

Does Javascript, or Python, or whatever else achieve that? Gosh, I don't know. But I'm scared of thinking about k as a total novice, so... I think they win against it up to some point. Maybe the level at which I'd know enough k to not be bothered by it is low enough that this doesn't matter, but ... it's still scary!

If I feel that way, why would I choose to use it knowing that I'd need to find the rare someone who overcame that fear, just to work on my CRUD app? This isn't k's fault, but k is not the right choice here, and so k has lost on this attribute of approachability, which is "readability for novices", and is the most valuable for a huge number of people.

I mean, if you work on a CRUD application, you're kindof stuck where you are. If it's written in Python, I think it's naive to think that your JavaScript knowledge will be very helpful: So many things are just too different. The JavaScript developer is looking for promises and maybe event streams, but 11 years ago, Python asyncio was uncommon, so you've got a thread-per-worker model. It's terrible any way you cut it!

What you've got that's similar: Block structure, single dispatch, everything's an atom, and a few seemingly familiar keywords like "for" and "if" that despite working differently, often appear in familiar patterns. I mean, how different is for k in x: than x.forEach(k =>? It seems like enough of these things dominate those first few steps into the unknown that they provide a comforting handrail into the descent into the coming madness, but it's difficult for me to believe it provides anything more than that.

And it's my experience that kind of comfort can be a lie: To read a fragment of well-documented code, to be amazed in the work and thought that clearly has gone into it, only to discover that fragment contained a bug I skipped over (since that area was so well tested and so clearly good) simply because I didn't bother to actually read it. So now I read. And maybe I read JavaScript and Python a little slower than others, what's important to me is that I also read JavaScript and Python slower than I read k.

I think that's a valuable trade.

But I think you're touching on something important: It's very difficult to mix in a little bit of k into an existing application to "try it out". I hope that there may be things we can do to the environment to make k more accessible and approachable that don't involve trying to cut out this valuable thing, because this thing that makes k unique is just so good I don't want to give it up.

I'm not sure many people use K to write crud applications in the way you're thinking.

Kdb+ is fully integrated K and a K-like query language running on an SSD array database built for array languages and stock/banking usage. Can you write a web app in it? Sure, but I doubt very many do and those that do probably just use K as the numerical engine and JS for everything else.

The comparison with languages as Chinese is not very appropriate because everybody has a native language. In that sense, programmers have more of a 'tabula rasa' (not completely, of course) that makes for more appropriate comparisons of readability. Usually, when people talk about "readable programming languages" the definition is taken as the amount of effort an average programmer needs to read a certain "standard" piece of code. You can of course categorize (readability of mathematical programs, or of system interactions?) and specify (for general programmers? for data scientists? for functional programmers?) but overall that's it.

Regarding your examples:

1. If you are using a database then it's not an argument for the language, I think. 3. A binary search is hardly a selling point of a language. 4. Views are cool, I reckon that. Although K is not unique in that regard. 5. That solution is, from my point of view, suboptimal and non-obvious. It's not only harder to understand than the naive search but it also performs algorithmically worse in all situations: it always performs nm comparisons (n, m being string, substring lengths resp.) plus the hidden cost of the rotation (which could be zero, could be not-zero depending on how is that implemented) plus the AND of every bit, plus the search of the match position.

I also left the second one as the last, because that, to me, is an anti-example. See the things I need to have "in-memory" in order to understand the snippet `Paper`Rock`Scissors@&/"ki"?

"ki"? means search for "k" or for "i"? I have to assume it's what that is, but I can't reconcile that with the documentation of the find function https://code.kx.com/q/ref/find/ because I don't know where comes the function argument.

* / means 'over'. Together with '&' (which somehow is both 'and' and less than? that's very confusing) it looks like it takes the minimum? I honestly do not know what it's meant to do at this point because I don't know what kind of object is "ki"?.

* @ means 'apply' and here I don't get how you are applying three actions to a what, a list? Because I get that ` means 'print'. Knowing what the code does I assume that when it finds 'k' (index 0) does the first action (paper) and so on. Looks like the 'find' function returns the length of the list when an element is not found (weird, because it is a very good way to facilitate mistakes and induce race conditions) so that's how you get 'scissors' in the other cases.

To me it's weird that you put this as an example. A code example that, despite being pretty simple (if the input has k, return Paper, if it has i, return Rock, else return Scissors) I am not able to understand it even with the documentation at hand. Given this example, I find hard to believe that you can find any K code and understand it quicker that you'd do with other programming languages. And I honestly doubt that it's faster than a for-loop in C.

Yeah, you can say you understand it. But you need a bigger "translation table" than in other languages, which adds to the mental concepts that you also need to keep in mind with programming. It's not to say that it's impossible, but it's more mental work for, as far as I have seen, very little benefit. It can work better for you, yes, but it's very possible that it's just that you're used to it and you don't notice the extra burden of dealing with that code.

> The comparison with languages as Chinese is not very appropriate because everybody has a native language. In that sense, programmers have more of a 'tabula rasa' (not completely, of course) that makes for more appropriate comparisons of readability.

How do you figure? Programmers too, have a "native language" (usually the one they use the most, or that has the most powerful features they know how to implement).

> Usually, when people talk about "readable programming languages" the definition is taken as the amount of effort an average programmer needs to read a certain "standard" piece of code.

I think that's a load of shit. What would be the point of communicating such an opinion to others?

> 1. If you are using a database then it's not an argument for the language, I think.

It's built-in to the language. You don't call Python a database because it can unpickle things.

> 4. Views are cool, I reckon that. Although K is not unique in that regard.

Excel has views. I'm not aware of any other language that has them. Do you have some examples?

> I can't reconcile that with the documentation of the find function https://code.kx.com/q/ref/find/ because I don't know where comes the function argument.

See the first example under type-specific uses of find. x (the left argument as given in the example) is a simple list.

> / means 'over'. Together with '&' (which somehow is both 'and' and less than? that's very confusing)

https://code.kx.com/q/ref/accumulators/#unary-application

https://code.kx.com/q/ref/lesser/

To x&y is the lesser of x and y. You can see in binary this harmonises with logical and:

    00001110b&11110111b
    00000110b

> I get that ` means 'print'.

No. `foo is a symbol foo. A symbol by itself is an atom, but `a`list`of`symbols can be written just by writing them together.

https://code.kx.com/q/basics/datatypes/#symbols

> code example that, despite being pretty simple (if the input has k, return Paper, if it has i, return Rock, else return Scissors) I am not able to understand it even with the documentation at hand.

Actually the point is to look at the analysis to see how I chose k and i. If you already know you can solve the game by searching for "k" and "i" then you've missed the point: Array programming languages make this obvious.

> How do you figure? Programmers too, have a "native language"

Unless everybody is born learning a language, no we don't. Even 'The one they use the most' varies over time.

> What would be the point of communicating such an opinion to others?

An easy use case: you're in your company and you need to do a simple script for some computation. The more readable the language you use is, the more coworkers will be able to find a bug/reuse it/modify it without requiring your help.

> It's built-in to the language. You don't call Python a database because it can unpickle things.

I read more of the parent comments on that link. I didn't notice that the OP started with an unsorted dataset, you did binary search on a sorted one. I thought that it the "kdb native format" meant more database magic that just serialization.

> Excel has views. I'm not aware of any other language that has them. Do you have some examples?

--C++ has string_view at least. I think C# had also views of some sort but whenever I search 'C# list/string view' I get MVC or WPF examples about unrelated things.--

Misunderstood what a view was, IDK why I thought it was string/list views.

> To x&y is the lesser of x and y. You can see in binary this harmonises with logical

"harmonises" in the sense that it takes one of the most common programming symbols and changes it? I don't know of anyone that sees "2 & 3 = 2" and thinks "yeah this makes sense".

> Array programming languages make this obvious.

How? First, your analysis line is even more cryptic than the resulting code. And I don't think the idea "find the minimum distinguishing characteristics between the outputs" can only be born out of array programming languages. Don't get me wrong, I think it's smart, but I don't see how the language makes that obvious.

Edit: Sorry, I misunderstood what a view was.

> Unless everybody is born learning a language, no we don't. Even 'The one they use the most' varies over time.

Nobody is born having learned a language. It's something even babies have to learn and they know nothing!

People can even "switch" their native spoken language up to a point although it seems to get much harder as they get older and more experienced with one language, as they're constantly comparing their aptitude to their "native" one -- just as they do with programming.

> An easy use case: you're in your company and you need to do a simple script for some computation. The more readable the language you use is, the more coworkers will be able to find a bug/reuse it/modify it without requiring your help.

The decision to bring another language into a company requires different considerations for every company. The one I work for has a lot of q/k programmers, so this isn't a problem for me. I like programming in k, so it makes sense I might want to be around other k programmers.

I think if you decided to write your "simple script" in even a well-known language like JavaScript, you'd cause some grumbles in a Python+C# shop; k isn't special in this regard.

> I read more of the parent comments on that link. I didn't notice that the OP started with an unsorted dataset, you did binary search on a sorted one.

HIBP offers the data pre-sorted, so I used that. I could have used asc (actually sort) instead of `s# (an assertion that it is already sorted) if I'd used a different file, but I value my time.

> I thought that it the "kdb native format" meant more database magic that just serialization.

No. It's literally just mmap. There's a header on the file describing the array shape, and indicating that it is sorted (so bin will be accelerated), but that's it.

kdb is a database in exactly the same way that Python could be if you just pickle/unpickle everything, except it's actually fast enough that people do this, even for large data sets.

> "harmonises" in the sense that it takes one of the most common programming symbols and changes it? I don't know of anyone that sees "2 & 3 = 2" and thinks "yeah this makes sense".

If you write something like (f=42)&(g=69) you expect "&" to mean "and" here, right? Well if f is an atom, then f=42 returns either a 0b or a 1b based on whether f is 42. What if f is a vector? Well, let's see:

    f:1 42 2
    g:4 69 4

f=42 returns 010b and g=69 returns 010b -- do you see why? Now 010b & 010b should return 010b for the same reason that 1b & 1b should return 1b (and 1b&0b should return 0b).

"&" is just generalised from here to work the same way non-binary values. Having it convert to binary-and would be very confusing for vectors, and although I can see a consistent way it could work, I don't see the value in that operation.

> Nobody is born having learned a language. It's something even babies have to learn and they know nothing!

I meant a programming language (it gets confusing, sorry). But anyways, our native language is much more embedded in the brain than programming languages.

> I think if you decided to write your "simple script" in even a well-known language like JavaScript, you'd cause some grumbles in a Python+C# shop; k isn't special in this regard.

Yes. And I'd cause even more grumbles if it was written in Haskell, and even more if it was on K. That's the point.

> HIBP offers the data pre-sorted, so I used that.

Yes, and that changes how you access the data. So the evaluation was not fair, as the OP was not using sorted data.

> db is a database in exactly the same way that Python could be if you just pickle/unpickle everything, except it's actually fast enough that people do this, even for large data sets.

That's nice, I'd actually wish Python had better serialization facilities.

> f=42 returns 010b and g=69 returns 010b -- do you see why

What if "f:42 1 2"? f=42 returns 100b (is that a value or a vector?) so under the common "and" definition "(f=42)&(g=69)" should return 000b, under the "less than" returns 010b?

> our native language is much more embedded in the brain than programming languages.

I think it's possible that might have more to do with the fact we use "our native language" more.

> Yes. And I'd cause even more grumbles if it was written in Haskell, and even more if it was on K. That's the point.

I don't know. I work in a place with a lot of q/k programmers, so this isn't a problem I face.

> Yes, and that changes how you access the data. So the evaluation was not fair, as the OP was not using sorted data.

You're mistaken. They did use sorted data, they just didn't know about the presorted file so they also wrote code to sort it.

> is 100b a value or a vector?

It's a vector of three elements (bits: zeros or ones).

> What if "f:42 1 2"? f=42 returns 100b … so under the common "and" definition "(f=42)&(g=69)" should return 000b

Yes that's right, and q/k would return 000b in that case.

> under the "less than" returns 010b?

100b<010b is 010b. We need something that gives us 000b and that operation is "and". Say I have a table that looks like this:

    f  g  k 
    --------
    10 9  kf
    20 8  je
    42 69 kf
    42 0  lk

That's written like this:

    t:+`f`g`k!(10 20 42 42;9 8 69 0;`kf`je`kf`lk);

k has tables as a data type. You can think of them as a list of dictionaries if you want:

    q)a:`f`g`k!(10;9;`kf);
    q)b:`f`g`k!(20;8;`je);
    q)c:`f`g`k!(42;69;`kf);
    q)d:`f`g`k!(42;0;`lf);
    q)(a;b;c;d)

    f  g  k 
    --------
    10 9  kf
    20 8  je
    42 69 kf
    42 0  lf

but I only do this to reinforce the idea this is a basic data type in k.

I can write t.f=42 and get 0011b and t.g=69 and get 0010b. I can do queries like this:

    q)select from t where (f=42)&(g=69)

and that's basically the same as this:

      t@&:(t.f=42)&(t.g=69)
    +`f`g`k!(,42;,69;,`en)

(&: is "where" and not to be confused with &)

And from there it should be clear why we need this "and" behaviour. The question is what should a&b do when they're not bit vectors that would be compatible with this behaviour? 42&69 should return 42 because it's the lesser; 0b&1b returns 0b because it's the lesser... Mathematics is already quite comfortable with the relationship between logical-and and min, so this has a precedent.

Just as a datapoint: I have never written any code in APL, J, K, Q, etc., and I think & = min is perfectly defensible. If I had to switch regularly between K and (say) C or Python where & is bitwise (also perfectly defensible, of course) I'd probably find it irksome and make mistakes from time to time, but I don't think it's an unreasonable choice.

(But: I am a pure mathematician by background, and the idea that logical AND is a special case of MIN is pretty familiar to us. The thing whose only values are TRUE and FALSE is a particular Boolean algebra. A Boolean algebra is a particular kind of lattice, and lattices have MIN and MAX operations, though we usually call them MEET and JOIN instead. I would expect & = min to be less comfortable to people with different backgrounds.)

[EDITED to fix an inconsequential typo.]

> "harmonises" in the sense that it takes one of the most common programming symbols and changes it? I don't know of anyone that sees "2 & 3 = 2" and thinks "yeah this makes sense".

There are a few of us in this thread, trying to explain why.

You find outrageous that 2&3=2, almost everyone (all the non-programmers of the world) will find more outrageous that i=i+1. You get used to it quite fast. It's obvious as soon as you realize that, with booleans, min is and, and max is or.

> will find more outrageous that i=i+1

Yep, it is hard to understand. That's precisely why I don't like having even more unintuitive things.

> It's obvious as soon as you realize that, with booleans, min is and, and max is or.

But it's not min and max with the rest of types.

> But it's not min and max with the rest of types.

Yes it is: & is min for all types including boolean, where it is "and" as we can see above. Similarly | is max for all types including boolean, where it is "or". You can convince yourself in binary, or pick up

> it is hard to understand. That's precisely why I don't like having even more unintuitive things.

If I tell you something is "intuitive" I do not mean you should find this approachable knowing what you know. Just as statements on "readability" I find this personalised definition doesn't promote a meaningful discussion, as it depends too heavily on social factors.

Now I don't deny those social factors are important, but if you really mean that, you're basically rejecting learning anything about X because (as at least as a factor) nobody else knows it.

Are you sure you want to be that person? Does anyone?

No of course not. We want to be scientists and evaluate these tools on their own merits. If they are truly new and novel, then we would not expect them to be popular, and so we cannot (if we are to be good scientists) reject them for that reason.

It is for this reason I recommend when someone says "it is readable" we always interpret it to mean if one knows how, and similarly, "it is intuitive", should have an implicit when you are thinking a certain way.

If we do not do this, then we cannot get any value whatsoever from what the other person is saying; if I truly imagine this is what the mean -- that they mean they do not have any interest in being a good scientist and having a discussion about the merits, then they're definitely not worth talking to.

So let me say something about "intuition" under this definition: To me, it is important to understand the relationship between the intuition I can have (or generate) about something, and the memorisation and taxonomy that something requires. "&" is extremely intuitive in this sense because it always has the same definition for every type (It always means the lesser). Most things in k are intuitive like that, and those things that are not, tend to be useful enough that they're worth memorising.

An example of something like the other is "?" which usually means "draw" (As in, that's the most common meaning). You might say 10?100 to draw ten numbers from 0-99. But what would `x?`y? How many is an `x? So k gives another definition to this form (enumerate). This is not intuitive, but if the definition is useful, we will memorise it. This one turns out to be useful.

For the most part, and in the way that I mean, k is very intuitive, and where it is not, it tends to be useful. These are good things!

1. If you are using a database then it's not an argument for the language, I think.

The database is a piece of the language, though, and the language ships with it. Python has a lot of very complex things in its standard library; C without a standard library is foreign to most programmers. Why do they get a pass while k doesn't?

It can work better for you, yes, but it's very possible that it's just that you're used to it and you don't notice the extra burden of dealing with that code.

It's not like 'geocar is foreign to writing in other languages. His GitHub (github.com/geocar) is full of projects in other languages, some fairly recent. This may make sense as an accusation for someone who doesn't write any other code, but I don't think it's a fair accusation here.

If there was some intense burden from writing k in comparison to ALGOL-like languages, would 'geocar have written an operating system in it rather than C? That doesn't seem apparent to me.

> Why do they get a pass while k doesn't?

When we are discussing languages, they don't get a pass. Python has a great math library with Numpy, but it doesn't mean that the language itself is optimal for math-related problems. And specifically in that example, using an external database when defending the speed of the language... meh. It's as if I said that Python is very fast and showed a Numpy calculation.

> This may make sense as an accusation for someone who doesn't write any other code, but I don't think it's a fair accusation here.

It's not about writing or not other languages. It's about being so used to something that you don't notice the burden. I am very familiar with some of the projects and languages I work in and I feel comfortable with the codebase, and I get used to the mental burden of working with them and I end up not noticing it. It doesn't mean it is not there.

> would 'geocar have written an operating system in it rather than C?

Has he? Couldn't find anything (I'd like to see it, honestly, seems a fun experiment).

And specifically in that example, using an external database when defending the speed of the language

kdb isn't written in an external language.

Has he? Couldn't find anything (I'd like to see it, honestly, seems a fun experiment).

Not entirely him, of course. There are a few remaining files on kparc.com:

kparc.com/z/ kparc.com/$/

so on.

Not free software, and they seem reluctant to show it off. 'geocar has done a live demo of a primitive version, though: https://www.youtube.com/watch?v=kTrOg19gzP4 (2014)

The archive is more interesting:

https://web.archive.org/web/20130830071750/http://kparc.com:...

> kdb isn't written in an external language.

But it's an external database with its code and its optimizations. In this case it seemed that it was just doing a binary search, but it was using an already sorted dataset that the OP of that comment wasn't using.

> kparc.com/$/

Well, I can't get anything out of this. See http://kparc.com/$/file.k. The language is cryptic and the variable names are even more cryptic. It's really hard to see what does this code even do. I can't honestly believe anyone that says that's a good way to create code.

> But it's an external database with its code and its optimizations.

You're completely mistaken. It's not an "external database". That's a regular, ~600kb interpreter download from kx.com

Those lines are all the lines typed into a q) prompt one at a time on my laptop (A 1.6ghz macbook air).

> In this case it seemed that it was just doing a binary search,

Yes. That's all okon does as well, they just do it over a B-tree instead of a contiguous list. If you read the writeup you'll see the author actually eschewed using a contiguous list for reasons of random insertion then took to a B-tree generation algorithm that couldn't handle unsorted input. I suppose they just forgot what they were doing at some point.

> but it was using an already sorted dataset that the OP of that comment wasn't using.

Again, you're mistaken. The author (Stryku) might not have known the sorted file existed, but the first thing they tried to do was sort it. They just had a problem sorting a 22GB file because they were using terrible tools. They had to make tools because they didn't have any good ones. The rest of their algorithm took advantage of the fact the input (to these later stages) was sorted.

> Well, I can't get anything out of this.

> I can't honestly believe anyone that says that's a good way to create code.

I spent 5 minutes to write something (in q) someone else wrote over twenty days (in C++).

I can't honestly believe anyone that thinks spending twenty days on a problem is better than five minutes.

If you can't get there, it's going to be really hard to talk about what's amazing in k!

> I can't honestly believe anyone that thinks spending twenty days on a problem is better than five minutes.

Nobody thinks that and I didn't say that. I was talking about that specific file (although the rest of them are equally unapproachable).

> If you can't get there, it's going to be really hard to talk about what's amazing in k!

Well, the thing is that at this point the only amazing things that have been talked about is that it's fast (in some specific use cases of data queries) and extremely concise. What more there is to K? What more reasons are there to use it, and with which downsides does it come with?

> Nobody thinks that and I didn't say that. I was talking about that specific file

I hope nobody thinks that, but unless you can come to terms with the fact that you're wrong, and that this is a completely fair comparison, you're going to be the guy who writes okon2 at some point instead of using a better tool.

> the only amazing things that have been talked about is that it's fast (in some specific use cases of data queries)

Those weasel words are preventing you from seeing what should be obvious:

The k program is faster, shorter, obviously correct, and it took less time to write.

That's the amazing thing. Who doesn't want that?

> What more reasons are there to use it?

This is the wrong way to think about things, because there's an infinity of such reasons. Instead, invert it: You should always use the best tool you can. If you don't know k, it can never be used even if it would otherwise be the best tool.

I don't recommend people use k (except when it works), but I recommend people learn k because it'll make them better programmers.

> which downsides does it come with?

The biggest downside is that you don't know it, and the only person who can fix that is you

I again point to the C standard library. Modern standard-compliant C can do almost nothing without it. I don't even think it can handle IO without it.

The language is cryptic and the variable names are even more cryptic.

You're thinking of it in a light that doesn't help you understand; don't think of it as a variable, think of it as a definition. "jk is defined as..."

> You're thinking of it in a light that doesn't help you understand; don't think of it as a variable, think of it as a definition. "jk is defined as..."

I was just trying to read the code for "file" and see if I understood a little bit of the implementation they did. In this case I don't even know where even is the function that opens a file or writes to a file. I don't think that's good code and I don't believe that thinking of it in terms of a definition is going to help.

Truly grokking Python as a first language also took me a few months of studying it and writing it, so the author is probably trying to say it's the same as any technology. The only caveat is once you learn something like Algol, you can kind of pick up similar ones fairly quick, while something like APL or K requires you to start over again.

Grokking a language in a few months is different from being able to just read a language in a few months. It's not just the paradigm change: Haskell, Julia, Mathematica or MATLAB for example are far, far more readable than K.

I think Julia, Mathematica, and Matlab aren't too bad, but have never had too much luck with Haskell despite spending time reading many blog posts and an entire book. APL was MUCH easier for me personally to start doing real things with quickly. Maybe because my experience is almost entirely with dynamic languages, I don't know. Point is, readability isn't an absolute. Haskell is easier for you, but APL is easier for others too.

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 increased (did I just invented a kpi here?)

> 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)
                     (push (list val key) result))
             hash)
          result)))

so you don't need all that. You don't even bother to create that "helper" function because you don't need it.

The choice of operators (and their definitions) was made with great care in an effort to maximise this effect.

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.

I think there are two worlds.

The one where shallow and social compatibility is seen as important.

The one where depth and seemingly looking sharp concepts is important.

If you care about your devs only be able to read some business logic then good, syntax familiarity is great. If you care about advanced problem solving, this is unimportant. And people prefer to iterate concise formulas presenting powerful concepts rather than instance-level readability (as in overlyVerboseNamingSchemes)

It might be simpler to view these languages from the perspective of "general purpose" or "specialized." General purpose languages rely on social compatibility because they're meant to handle a wide range of common development. Specialized languages can ignore familiarity because they're used by specialized teams for specific purposes. That appears to be the cases with K, which (AFAIK) gets a lot of use in financial modeling.

Could K become a general purpose language? Maybe, but it always strikes me as odd that that feasibility as a mainstream language comes up so frequently when K is discussed. It's not the high-order bit of the conversation.

No, if you care about advanced problem solving, you still want your solution to be readable and maintainable with as little fuss a possible.

The idea that concise formulas provide this (and that more modular solutions can't) appears to be a conceit.

Putting a space between discrete symbols would have helped the first example considerably

    + / ! 1000

> Specifically, the claims it's perfectly readable, and anyone who says anything otherwise is either stupid, lying, or too poor to understand it are not useful.

+1. All of these "compact" languages (I'd even extend it to Perl to some extent, the way some write it), are seriously lacking in the ergonomics department. Sure, J Leet Hacker might have no problem parsing pages of the stuff. What about the coworker with dyslexia, ADHD, vision problem, etc?

Even if you aren't, what are the real gains? It seems resistant to tabcomplete, git diffs are probably near-inscrutable, grepping for snippets is probably an exercise in judicious application of backslashes... it's cute, but I don't see where this holier-than-thou is coming from (not that ANY language justifies that attitude)

Edit: oops, touched a nerve, I see. I'll add to the above the 7 +/-2 rule [0]. Sure, lets say even you COULD write a program in 1/100th or 1/1000th of the lines in k. I don't WANT a source code that looks like that. Way too much information density.

I'll give them this: perhaps the criticism is that ALGOLikes are too sparse, could stand to be denser, and k is the manifestation of the far other end of the spectrum.

- https://en.m.wikipedia.org/wiki/The_Magical_Number_Seven,_Pl...

Dyslexic here! k is significantly easier to read than ALGOL-derivatives and most Lisp dialects.

Reply on news.ycombinator.com