Stages of denial in encountering K • Hacker News Board

Re: Stages of denial in encountering K

#251

Post by magicalhippo » Mon, Mar 09, 2020, 1:33 PM UTC

PeterisP wrote: post #227

magicalhippo wrote: post #188

Earlier quoted context omitted.

> I know several major languages and this program looks like noise to me. That's because it is. As pointed out repeatedly, one of the main goals of the program is to minimize the program size, in terms of bytes. Thus the source code is essentially compressed code and, as we know, compression makes thing more random hence more noise-like.

"one of the main goals of the program is to minimize the program size, in terms of bytes." -> so, you're claiming that code-golf is actually the intended goal? It seems that there's a fundamental disconnect of values here. It seems to me that you're optimizing for something that's nearly insignificant (to me) at the expense of qualities that actually matter for me and almost everyone else. In essence, if that code co…

Indeed, my feeling is also that K optimizes for the wrong things, at least as a general purpose language.

Re: Stages of denial in encountering K

#252

Post by wcarss » Mon, Mar 09, 2020, 1:34 PM UTC

geocar wrote: post #226

gjulianm wrote: post #209

Earlier quoted context omitted.

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

Re: Stages of denial in encountering K

#253

Post by magicalhippo » Mon, Mar 09, 2020, 1:36 PM UTC

7thaccount wrote: post #224

Firadeoclus wrote: post #220

Earlier quoted context omitted.

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

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

Re: Stages of denial in encountering K

#254

Post by rtikulit » Mon, Mar 09, 2020, 1:40 PM UTC

TheOtherHobbes wrote: post #157

bartread wrote: post #90

Earlier quoted context omitted.

I tend to agree: falls into the category of "just because you can, doesn't mean you should." Actually, that's perhaps a bit harsh. I have some pretty obscure hobbies, and there's certainly nothing wrong with doing this sort of thing if you want to. Still, having done so it's a bit rich to then look askance at the rest of us like we're all idiots for not choosing to go down a similar route with our own systems.

I suspect everyone would love K if they had an extra 30 IQ points to work with. The reason we have Python, Javascript, and Java is because most people (including me) just aren't bright enough to work fluently in these terse APL-alike idioms. They fail because it's hard for most people to keep that many terse symbols and symbolic relationships in memory at the same time, without English labelling and all the other usu…

In the 70's, in high school, I taught myself APL (mostly TOPS-10 APL SF and a bit of IBM APL SV) well enough to grasp the fundamental functional approach and write real programs (and the obligatory game of life in 1 line :-)) At the time I was also using PL/I and the difference was mind expanding.

I'm quite sure I don't have an 30 extra IQ points. Mostly I was just mildly obsessed (and these days I find persistence is a workable substitute).

It is incredibly valuable to have experience across the range of programming paradigms.

Re: Stages of denial in encountering K

#255

Post by kick » Mon, Mar 09, 2020, 1:42 PM UTC

virgilp wrote: post #167

kick wrote: post #97

Earlier quoted context omitted.

k costs $20,000 per-core (less accurate now than it used to be but I'm pretty sure it's still true for commercial uses). It has a billion-dollar company based entirely around it (Kx/FD) and a smaller multimillion one, so it worked out well, I guess. J is free, but J has never had an advertising budget, and was only freed recently. APL's current leading implementation is really bad in comparison to how nice the langua…

A language doesn't cost... the environment might. Why did nobody pick up on the ideas? C# is not inspired by K, Go is not, Swift is not, Rust is not, Clojure is not... I mean, take any big or small company that decided "we need a new programming language" - I'm not aware of many taking inspiration from K. I get it, there are people who love K, and are productive in it. And I'm not even claiming the ideas of K are inh…

Go was, by the author's own admission, a language for the lowest common denominator (the computer science undergrad). In many ways, the computer science undergrad is less competent than someone with no formal backing at all: it takes less time to teach a new skillset to a blank slate than repair the damage done to undergrads. Rob Pike's hobby is working on an APL interpreter.

C# was Microsoft's answer to Java after getting sued for cloning Java.

Rust is by C++ devs, for C++ devs.

Swift was Apple's successor to Objective-C.

Clojure is another language doing the "Lisp but with a bootstrapped ecosystem" thing, by a guy who had been active in the Java, .net, and CL communities.

All languages build on something, and when the mainstay languages are all ripping off ALGOL-60, ALGOL-60 clone after ALGOL-60 clone is what you will get.

Programming languages are just now starting to become influenced by Prolog despite the benefits of Prolog for certain tasks being apparent; the entire result of the field right now can roughly be traced entirely to UT Austin.

The point of the article was not to claim anything about the superiority of k programmers, it was to point out that the rest of the world was extremely close-minded to anything with different syntax in a comical way, along with demonstrating that a common criticism (of which there are many, 99% of which unfounded, as you can see by checking any thread on Hacker News that even briefly touches upon k or APL) was hypocritical, which I think it did a great job at.

It was a reference to the Kübler-Ross model, which does seem to apply to people who find APL/J/K at some point.

Re: Stages of denial in encountering K

#256

Post by kick » Mon, Mar 09, 2020, 1:48 PM UTC

magicalhippo wrote: post #188

brokensegue wrote: post #113

Earlier quoted context omitted.

literally any of it. I don't know perl but I can read and modify well written perl scripts in a pinch with maybe a little googling. I know several major languages and this program looks like noise to me. is it standard to give functions terrible names? and to not pull out constants to make things understandable? i'm unclear what semi-colons, colons and commas do here or why the lines are so long.

> I know several major languages and this program looks like noise to me. That's because it is. As pointed out repeatedly, one of the main goals of the program is to minimize the program size, in terms of bytes. Thus the source code is essentially compressed code and, as we know, compression makes thing more random hence more noise-like.

Thus the source code is essentially compressed code and, as we know, compression makes thing more random hence more noise-like.

This is wrong. k programs aren't really random at all. It's not even that complicated; it has less than thirty primitives. It's a notation for representing ideas, and it excels at that.

Dyalog APL is similarly terse, although less so, and the goal of it isn't to be terse. This criticism still gets thrown at it, and is representative of an unwillingness to accept something that mathematics has known for years: notation isn't golfing, it's a convenient way to express thought.

Re: Stages of denial in encountering K

#257

Post by wcarss » Mon, Mar 09, 2020, 1:53 PM UTC

geocar wrote: post #250

wcarss wrote: post #247

Earlier quoted context omitted.

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…

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.

Re: Stages of denial in encountering K

#258

Post by qayxc » Mon, Mar 09, 2020, 1:56 PM UTC

kaminari wrote: post #174

ehsankia wrote: post #31

Earlier quoted context omitted.

range(100).reduce(plus, 0) isn't cryptic, what's cryptic is single character symbols. Looking at that line, unless you know K specifically, it's very difficult to figure out it's a reduce. Where as `sum(range(100))` is pretty self explanatory to most programmers who don't know python.

I don't know K but "+/" immediately stood out to me as "add over", so I think they made a good choice in using "/" for fold. "!", on the other hand...

There's no good (or bad) choices for mapping abstract concepts like ranges, mapping, reducing, or combining to common (ASCII-) symbols. Every choice is inherently arbitrary and carries no meaning whatsoever (besides maybe ergonomics). One could just as well argue that "/" is the ISO 8000-2:2009 2-9.6 recommended symbol for division. The same source also shows why symbols alone are inadequate for an explicit representation of abstract concepts: the Nabla symbol alone represents 5 different operations depending on context according to the ISO standard.

Re: Stages of denial in encountering K

#259

Post by kick » Mon, Mar 09, 2020, 1:56 PM UTC

kortex wrote: post #235

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…

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

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

Re: Stages of denial in encountering K

#260

Post by tluyben2 » Mon, Mar 09, 2020, 2:00 PM UTC

jmnicolas wrote: post #248

iateanapple wrote: post #199

Earlier quoted context omitted.

> That is perhaps a factor 5 not a factor 1000. I’ve personally found 20-30x compared to Java - admittedly not the most compact language.

I'd rather read 30 lines of Java (yes Java !) than try to decipher one line of K !

Matter of taste; I cannot imagine having to program Java (give me Clojure/Scala any time if jvm is required) for a living anymore; deciphering a lovely 200000 class codebase where every call in every 30 lines bring you into a deep spelunking trying to figure out where/how/what and hoping it's not in some ancient undocumented .jar etc. So I have very much the opposite of what you have. Then again, I have been doing k/j/apl for a long enough time that I would not call reading it deciphering, most of the time. While for Java (& C#) it is always deciphering, even after 20+ years (which was when I became a professional Java programmer) because, unlike with k, you simply cannot know all the libraries and files or the brilliant imagination of people who like to use design patterns 'just a bit' wrong for everything.