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

271–280 of 432 posts

Re: Stages of denial in encountering K

#271

Post by geocar »

wcarss wrote: post #252
geocar wrote: post #226

Earlier quoted context omitted.

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

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

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.

Re: Stages of denial in encountering K

#272

Post by yiyus »

wcarss wrote: post #257
geocar wrote: post #250

Earlier quoted context omitted.

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

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.

Re: Stages of denial in encountering K

#273

Post by agumonkey »

saagarjha wrote: post #139

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

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

Re: Stages of denial in encountering K

#274

Post by qayxc »

geocar wrote: post #229
qayxc wrote: post #216

Earlier quoted context omitted.

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

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

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

Re: Stages of denial in encountering K

#275

Post by lmm »

clarry wrote: post #244
lmm wrote: post #15

Earlier quoted context omitted.

> k is perfectly readable. That's like, one of the biggest points of the post. The post mocks the mindset featured within your comment. It mocks it, but it doesn't present a convincing argument. Switching from an imperative language to K is making several changes at once, so we can't really conclude anything about the details of which changes are good or bad. The closest I've seen to a controlled experiment is someth…

> But I remain unconvinced that it's worth going all the way to code that can't be communicated verbally. Symbols can be communicated verbally. You can make up new symbols and give them a verbal meaning. I think the big issue here is that programmers are lazy and whine about anything they aren't able to pick up within a weekend with their prior experience and some hard staring. "I looked and I didn't get it so it's u…

> I think the big issue here is that programmers are lazy and whine about anything they aren't able to pick up within a weekend with their prior experience and some hard staring. "I looked and I didn't get it so it's unreadable." By the same token, Greek, Russian, Japanes, Korean, and many many other languages must be unreadable, along with like mathematics.

Language design would be easy if it weren't for those pesky programmers :). I don't think you're wrong, exactly, but I'd note that few companies fully support people learning any of those (rather they rely on hiring people who studied them in university). Most programmers, quite rightly, aren't willing to commit a significant chunk of personal time to learning something with little immediate benefit, and most employers won't adopt a language that requires a significant training programme, and I'm not convinced they're wrong either.

Re: Stages of denial in encountering K

#276

Post by pfraze »

agumonkey wrote: post #273
saagarjha wrote: post #139

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

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

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.

Re: Stages of denial in encountering K

#277

Post by uryga »

uryga wrote: post #140

what is ` the closest i got to finding some pattern is this: >>> xs '34210' >>> grade(xs) [4, 3, 2, 0, 1] >>> grade(grade(xs)) [3, 4, 2, 1, 0] # :O where grade = lambda xs: ( [i for (i,_) in sorted(enumerate(xs), key=swap)] ) swap = lambda p: (p[1], p[0]) no clue what it means though. (i guess "ordinal" really is too ambiguous...) EDIT alright, i see it now - `<<xs` is "for each item x of xs, where does x land when y…

one cool explanation i found is that grading a permutation list effectively gives you its inverse:

  xs = "cab"
which is exactly what "ordinal" is supposed to do! it kinda makes sense - grading the indexes given by `[0,1,2]). or at least it seems that way if you stare long enough, would be good if someone could confirm!

Re: Stages of denial in encountering K

#278

Post by gjulianm »

kick wrote: post #268
gjulianm wrote: post #262

Earlier quoted context omitted.

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

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

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

Re: Stages of denial in encountering K

#279

Post by geocar »

gjulianm wrote: post #262
geocar wrote: post #226

Earlier quoted context omitted.

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

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

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

Re: Stages of denial in encountering K

#280

Post by agumonkey »

sriram_malhar wrote: post #202

I love the brevity of regular expressions and use them on a daily basis. It is the same argument that keeps me returning to K: the syntax is terse and compact, the semantics are simple and composable, and your eyes get used to it. Beyond a point however, I cannot read my own regex's after a month's absence. Which is why I use perl's /x modifier extensively to split up regex components onto multiple lines and to docum…

Slight reversal.

I've read a lot of human oriented, commented code which meant nothing to me, because the overall state space / architecture was fuzzy.

Whether it's a oneliner or a framework, readability is quite secondary IMO

ps: this also connect to the mathematician views about naming vs structure.. names are mostly arbitrary, it's the structure that drives the logic and the device.

Post reply on HN