Live data from Hacker News

Stages of denial in encountering K

nsl.com

281–290 of 432 posts

Re: Stages of denial in encountering K

#281
post #201

Earlier quoted context omitted.

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

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

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.

Re: Stages of denial in encountering K

#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 useful to maintain documentation on how to /read/ the code (almost a literate programming approach).

Re: Stages of denial in encountering K

#283
post #217

Earlier quoted context omitted.

I find that in these discussions people think that complexity can be escaped. A program cannot be less complex than the problem it solves. Of course you can add even more complexity if the programmers are not good, but that lower bound cannot be surpassed. In your example, assuming that a million-line program is well done in its language, you'd have exactly the same complexity but now in a thousand lines, meaning tha…

In your example, assuming that a million-line program is well done in its language, you'd have exactly the same complexity but now in a thousand lines, meaning that now each line does more, is more complex and changing it/understanding it is more difficult and prone to errors. It would be equally (if not more) impossible to understand. Disagreed. Reductio ad absurdum: It's not a good idea to force everyone to program…

Ok, you're right. It's not so clear-cut, but there's definitely a balance to find.

Of course, assembly is far better than machine code. C is almost always better than assembly, because it maps better the mental ideas to code than assembly. After that, you have higher-level languages and then the change is not that clear. High-level languages tend to hide the complexity of dealing with the computer: in Python, JS, Haskell or K you don't need to worry about memory allocations, or how objects are defined, or how to pass arguments to functions. Sometimes you need to worry about that, and having a language that does that for you makes your program harder to understand (how does JS work with parallelism? When is an object an object and not a copy? Suddenly you need to know how does JS do certain things and that complexity reappears in your program).

Now, for the example, when I said that the million-line program is well done, I was thinking about some JS, Python, C++, or Java application without too much unnecessary cruft and that maps properly problem concepts to code concepts. If the 1000x line reduction (if that even exists) is done on the basis of smart one-liners, unreadable code and constructs and language-specific, it's not worth it. Say your application was a physics simulator of a certain situation. Most people would want the million-lines Python code where each function and each part is understandable and lets you focus on the problem at hand, instead of a thousand lines where you not only have a difficult problem but also a difficult code.

Re: Stages of denial in encountering K

#284
post #268

Earlier quoted context omitted.

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

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

Re: Stages of denial in encountering K

#285

Earlier quoted context omitted.

Regular expressions are a more concise way of writing string matching and extraction code, often exponentially more efficiently than without. They’re also usually more compact than spoken English can represent. For example, this proofreading regex detects possible issues in spelling: /(?<!c)i(?=e)/

Doesn't that regex detect correct spellings instead of wrong ones? I.e. it matches tier, tie, etc.

Yes. Good eye :) The other comment is also quite accurate: it doesn’t properly grasp phonetics.

Re: Stages of denial in encountering K

#286
post #161
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…

x: 10?A:"abcdefghijklmnopqrstuvwxyz" x "ysyselacwl" +`x`y`z!(x; So <x gives a sort index, <<x tells you how far each element is from the minimum in that sort index

yeah, i figured it out eventually. since you seem knowledgeable about K, would you mind taking a look at my second comment in this thread (about inverting permutations) and seeing if it makes sense? thanks!

Re: Stages of denial in encountering K

#287
post #153
post #111

Earlier quoted context omitted.

Yes, but as you multiply that difference 100 or 1000, the advantages of the concise notation become obvious.

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 the only one similar, although still very large.

The C++ program is lost to link rot now, but by the author's own admission, was substantially larger than even the substantially large examples within that page.

      1    2   29 k
     23   70  498 scheme
     25  111  768 otherhaskell
     44  135 1096 erlang
     53  125 1043 rb
     67  190 1419 ocaml
     74  346 1693 haskell
     80  357 2586 java
Keep in mind that by their own admission, everyone in the c2 thread's code was hard to read (outside of the Joy program), and many were buggy. Meanwhile, the k program is quite simple to read.

These are just some basic examples, though.

Re: Stages of denial in encountering K

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

Re: Stages of denial in encountering K

#289
post #269

Earlier quoted context omitted.

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

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

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

Re: Stages of denial in encountering K

#290
post #185

If you want to sell me a language do: - Explain what particular use cases the language is optimized for - Show its advantages compared to the alternatives - Tell me honestly what tasks it is not suited for do not: - Use blantant strawmen to make the alternatives look worse. - Tell me I am an idiot

I think the simple explanation here, per POSIWID, is that people who do the latter things do not in fact want to sell you on a language. It reminds me of the people who liked a band until it got popular. The point isn't the thing itself, it's having a reason to feel superior to other people.
Post reply on HN