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

341–350 of 432 posts

Re: Stages of denial in encountering K

#341

Post by geocar »

qayxc wrote: post #274
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?

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

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

Re: Stages of denial in encountering K

#342

Post by chrispsn »

wpietri wrote: post #291
chrispsn wrote: post #108

Earlier quoted context omitted.

Arthur tries to choose primitives carefully so that the amount of steps is smaller than other languages (see the 'product' quote in another comment). So even if you give each symbol an English name, the code will often end up smaller.

In which case it seems like two things are being conflated a lot here: terseness and better primitives. I'm opposed to the first, but very interested in the second. Is there a language you think focuses on approachability and readability but keeps the good parts of K?

k9 (from Shakti) will have optional word equivalents for some symbols (or at least common compositions) by default.

Have you looked at q?

numpy has a lot of k/APLish primitives built in.

fml was also interesting but never made it past the spec stage:

https://www.reddit.com/r/apljk/comments/etpbbf/fml_an_optimi...

Re: Stages of denial in encountering K

#343

Post by earenndil »

LessDmesg wrote: post #337

I have the same question for K aficionados as I have for Forth ones: what real-world, human-usable, important software has been written in it? A GUI framework, a web browser, a window manager, a text editor, etc. Anything? I'm asking because the article is poking at C-like languages, i.e. implying that K is good for general-purpose use. Yet all I hear about is that K is good at multiplying numbers and matrices, which…

Arthur wrote an OS in k with some c. Not public, but geocar can probably talk more about it if he shows up.

Re: Stages of denial in encountering K

#344

Post by gjm11 »

gjulianm wrote: post #288
geocar wrote: post #279

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

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

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

Re: Stages of denial in encountering K

#345

Post by oddthink »

snicker7 wrote: post #282

I use to program financial applications in K/Q for a stint. Very elegant and orthogonal language. And very well documented. One major issue I had with it and other APL-ish languages: lack of skimmability. I can easily skim thousands of lines of Perl and Java in seconds and have a rough idea of what the code does. Reading K, however, requires careful and deliberate attention to every single character. I found it usefu…

Yeah, I agree. I wrote some mortgage prepayment models in q for a while, but didn't dip into K itself. Q is fantastic as a database query language (assuming you have time-series databases and are mostly doing fairly simple operations.) Implementing a full model in it is fine, but can get hard to maintain.

Also it has (or had, maybe they fixed it) a bunch of weird quirks, like "sum foo" skipping all the NAs in a list while "+/foo" didn't, resulting in NaN. (Or maybe it was +/ over an int array didn't work while a double array did. I forget.) Arrays of dicts were immediately turned into tables, which didn't work the same as an array of dicts, etc.

But, yeah, it's not crazy implementing things in q/K, as long as they're mostly linear things. Trees are hard, iterative methods are hard, and it's really hard to skim code, other than to just rely on names and comments.

Re: Stages of denial in encountering K

#346

Post by loeg »

kick wrote: post #287
loeg wrote: post #153

Earlier quoted context omitted.

This 100 or 1000x claim is extraordinary. Do you have any factual basis for repeatedly asserting it?

Contrived Debian shootout benchmarks: http://www.kparc.com/z/comp.k https://web.archive.org/web/http://shootout.alioth.debian.or... Note that the relevant k program here is contained entirely on the last line of code and denoted by a comment telling you what it does: http://www.kparc.com/z/fun.k http://c2.com/cgi-bin/wiki?WardNumberInManyProgrammingLangua... Most Joy people are also k people, and Joy appears to be th…

So maybe 40x in line count if you compare an extremely verbose language like Java to K in this contrived example? That's not close to 100x and especially not close to 1000x.

Re: Stages of denial in encountering K

#347

Post by Nursie »

carapace wrote: post #312

This article should end with something like, "...and then you find out about arcfide's Co-dfns compiler..." https://github.com/Co-dfns/Co-dfns You don't have to like it, but the existence of K, et. al. shows that most of us are wasting a huge amount of time and energy using bad tools. These things are so powerful and not that hard to learn.

It shows no such thing. It shows that you have found something you think you can be productive in and that you like, not that the rest of us are on the wrong track.

Re: Stages of denial in encountering K

#348

Post by Nursie »

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…

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.

Re: Stages of denial in encountering K

#349

Post by magicalhippo »

PeCaN wrote: post #72
kazinator wrote: post #44

> When the entire system fits in a page of code you can understand everything about it from the top down. I'm sorry, but that sounds like the juvenile fantasy of someone who is still in their programming puberty. Good luck fitting an operating system, web browser or air traffic control system into a page of code.

Maybe I should've said a "screen" instead of a "page" (if you have two files open side-by-side and they both fit on your screen it's the same benefit). And I admit it is slightly hyperbolic (to make a point about the virtues of being able to see a significant portion of your project at once). Large projects will be more than one screen of code, although perhaps surprisingly few. (This actually influences how I organi…

> This K text editor is way less than one screen

Where's the handling of encoding when loading and saving? Where's the handling of different line-endings? Where's the error handling?

Would have been nice to see something approaching real-life code rather than these toy samples.

Re: Stages of denial in encountering K

#350

Post by aw1621107 »

7thaccount wrote: post #319
aw1621107 wrote: post #261

I've seen a few posts here and there over the years about array languages, but I can't recall any (or any discussion in their comments) that have mentioned any disadvantages beyond more human factors. So for the k/q/APL/array language gurus out there: in what situations would I not want to use k or another array language, if the relative obscurity of the syntax and mental model were not a factor (e.g., assuming you,…

Performance depending on your use case. APL/J/K can be very fast for an interpreted language, but they won't beat C, C++, Fortran, and Java in most cases. Also, think about distribution. With most of the array languages, it is commercial, so I'd be cautious about building a business around it. With other languages, it is free to use and deploy as you see fit and some have binary executables that don't need a runtime.…

> APL/J/K can be very fast for an interpreted language, but they won't beat C, C++, Fortran, and Java in most cases.

Do APL/j/k/q work well for some performance-sensitive situations but not others? Some of the comments here by people who appear to be very familiar with the language make it seem like it performs quite well compared to the traditional high-performance languages.

Distribution is definitely something I hadn't considered; I guess I've been spoiled by the variety of free/open languages available these days.

I've always wanted to try to pick up an array language to expand my horizons a bit (e.g., that one bit of advice that programmers should learn one of the four main types of languages --- ALGOL-based, Lisp, functional, array-based), but I just haven't had the time.

Post reply on HN