Live data from Hacker News

Stages of denial in encountering K

nsl.com

311–320 of 432 posts

Re: Stages of denial in encountering K

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

Re: Stages of denial in encountering K

#313
post #275
post #244

Earlier quoted context omitted.

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

> Language design would be easy if it weren't for those pesky programmers :).

What kind of a language would you make if time-to-learn-it were not a factor in it?

I've been thinking about language design for years but I still haven't arrived at anything specific. There are ideas floating in the air, but I haven't had the time to try them out in practice.

I think it'd be nice to see efforts like this, where language designers drop on the floor every concern about familiarity or similarity to existing languages and just find out what results in the most powerful language (in general, or in a particular domain).

It's a very difficult problem.

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

They might be pragmatic, but I feel like we're kinda stuck in local minimas on too many fronts, thanks to such shortsightedness.

But don't you think it's mind boggling, and perhaps even a little hypocritical, that we spend up to around two decades of our lives in education (with a bunch of fluff that somebody always argues might be useful some day). And then after that, learning a new tool that would require more than a few weekends is no-no? I find it quite absurd.

But yeah I'm not really expecting companies to care, even though I think they should. To be honest I don't care too much about companies; from what I've seen, the vast majority of them are just crap ;) Thankfully there's open source.

Long term, I think something about the system needs to change. We should have more flexibility to train people on demand without putting all the burden and cost on the individual alone (or their company). For all the talk about lifetime learning, I don't think we've done much yet.

Re: Stages of denial in encountering K

#315

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…

> Where are the comments?

While I can understand how that code can be intimidating to a programmer with a more “traditional” background… there are 26 (non-empty) lines of comments, and only 15 lines of code.

Re: Stages of denial in encountering K

#316
post #51

Earlier quoted context omitted.

Better: Free software K interpreter: https://bitbucket.org/ngn/k/ Arthur's K interpreter isn't actually that expensive for casual use anymore (it's free for most non-commercial use and you can download it off the Shakti website pretty easily), though. Not that I'd recommend it: Arthur's a genius, but nothing's worth using proprietary software for. What I usually recommend for learning the paradigm is J, largely becau…

There are a lot of books, tutorials, and papers on APL and APL2, which are applicable to GNU APL.

I don't believe so? I started out using APL2; GNU APL seems distinct in ways that are noticeable. Certainly not in a bad way, but I think enough to cause confusion for any newcomer reading said books, tutorials and papers.

Re: Stages of denial in encountering K

#319

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. K is very expensive. Dyalog APL is pretty reasonable, but still costs money to use and royalties in certain situations.

I think any decent developer can pickup array languages, but many won't want to as they'd rather have something more mainstream (Java, JS, C++, Python...etc) on their resume. So it might be difficult to hire.

Re: Stages of denial in encountering K

#320
post #107

A million-line program isn't readable by anybody, no matter how readable the language is. If the equivalent program can be written in, say, a thousand lines in some more concise language, that's more than worth the learning curve, even if the language is strange and off-putting.

The Kolmogorov complexity of the program, eh?

Alan Kay' VPRI's STEPS project used PEG parsers to create math-like DSLs to in their attempt to go "from the desktop to the metal in 20,000 lines of code."

Post reply on HN