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

241–250 of 432 posts

Re: Stages of denial in encountering K

#241

Post by smallnamespace »

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

> Everyone learns it in China, and everyone there will tell you that it's perfectly readable and you don't need to be extraordinarily intelligent to speak it.

I'm not sure Chinese is necessarily a good example for the point you're trying to make.

Native Chinese speakers _probably_ spend more effort acquiring full competency in Chinese than native English speakers need to learn English. For one thing, reading and 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...

Re: Stages of denial in encountering K

#242

Post by Firadeoclus »

fragmede wrote: post #204
7777fps wrote: post #149

Earlier quoted context omitted.

You've got me wondering about the utility of a genuinely write-only language. As a thought experiment, would there be benefit to letting functions only be written once? No-one could come along and break code by changing a function. If you wanted to fix a bug in a function you would have to write a new copy and explicitly update callers to use the new version. A lot of maintenance overhead? Possibly, but tooling would…

What an absolutely fascinating idea! As the field of software engineering matures, how million line repos get maintained is going to become a subject of academic study. > If you wanted to fix a bug in a function you would have to write a new copy and explicitly update callers to use the new version. Finding all callers is the hard part though! And in modern languages, that need to be addressed both at compile (or "co…

> Finding all callers is the hard part though!

Only because we made it hard by storing code in files instead of a database.

Re: Stages of denial in encountering K

#243

Post by neo2006 »

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…

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

Re: Stages of denial in encountering K

#244

Post by clarry »

lmm wrote: post #15
kick wrote: post #5

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. None of the languages you listed are quite as readable as k to someone who knows it. All of the languages you listed are significantly slower and feature none of the benefits of a concise notation, even with fast.ai's Python style guide made to imitate Arthur Whitney. http://www.eecg.t…

> 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 unreadable." By the same token, Greek, Russian, Japanes, Korean, and many many other languages must be unreadable, along with like mathematics.

Meanwhile, I'm happy that we have concise syntax for mathematics, even if you have to go out of your way to learn to read all these fancy symbols. Notation as a tool of thought and all that.

Re: Stages of denial in encountering K

#245

Post by kick »

saagarjha wrote: post #147
kick wrote: post #59

Earlier quoted context omitted.

You added more criteria to this high school student. Almost every one of them will have to use and program spreadsheets, few learn to program using an ALGOL-like language. The idea you put forth disqualifies any programming language that isn't derivative of ALGOL: it's exactly the sort of thing used against Lisp dialects, and many other languages that have shown themselves to be quite wonderful ("What's cdr? That's s…

Somewhat; there's a number of things about K which make it uniquely difficult to understand. One is of course that it is unpopular and nobody has really seen it before: while this isn't an inherent issue with the language, it is a practical one, since K exists in a world where other programming languages exist and people with experience in those languages exist. Something that can be understood by more of them is gen…

I would have to disagree with your assertion that APL's derivatives are fundamentally better and/or faster to learn actual computer science

Have you tried learning any of them? I think this is an unfair thing to say without having at least given it a try.

Re: Stages of denial in encountering K

#246

Post by kick »

virgilp wrote: post #170
vnorilo wrote: post #168

Earlier quoted context omitted.

Why is it strange? Think of languages like Lisp, Smalltalk, Haskell. You may not find them on top of TIOBE, but their innovations do trickle down to mainstream, indicating that the designers of mainstream languages find them worthwhile. Array languages are very much poised to do the same, if they did not already: numpy is essentially a poor (and verbose) man's array language embedded in python. Or consider Matlab.

> "A LISP programmer knows the value of everything and the cost of nothing." Here, a very old quote that tells you directly what is wrong with FP - the performance on old hardware sucked. For a very long while compilers/interpreters were not good enough. The cost/benefit equation changed in recent years, and sure enough, FP ideas are becoming mainstream. Again, I'm not saying that array languages don't have fundament…

(k is competitive with C by most measures, and most k programs are faster than the equivalent C programs.)

Re: Stages of denial in encountering K

#247

Post by wcarss »

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?

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.

Re: Stages of denial in encountering K

#248

Post by jmnicolas »

iateanapple wrote: post #199
goto11 wrote: post #136

Earlier quoted context omitted.

I doubt that K can reduce line count by a factor 1000 though. The examples in the article is mostly about shorter identifiers like "!" instead of "range" and a compact notation. That is perhaps a factor 5 not a factor 1000. The example with a for-loop for summing a range is a blatant strawman. In which modern language would that be idiomatic? Furthermore the examples only show a particular use case: Processing lists…

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

Re: Stages of denial in encountering K

#249

Post by geocar »

neo2006 wrote: post #243
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…

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

> I also don't see the point of optimizing on the number of line of code if the complexity per character is increased (did I just invented a kpi here?)

It doesn't increase linearly though. #:'=: is seven characters that mean as much as 68 separate lexemes in lisp:

    (defun count (list)
      (let ((hash (make-hash-table)))
        (dolist (el list)
          (incf (gethash (cadr el) hash 0) (car el)))
        (let (result)
          (maphash (lambda (key val)
                     (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.

Re: Stages of denial in encountering K

#250

Post by geocar »

wcarss wrote: post #247
geocar wrote: post #229

Earlier quoted context omitted.

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

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?

Post reply on HN