icen

And Intercal on Interstates: http://intercaloninterstates.org/

I can't speak to j, but using q, its cousin, at work looks quite a lot more like the graph APL posted above. It's spread out over several lines, and heavily commented.

Most problems are also much simpler, and don't require any heavy one-liners.

> But what you're describing there should be a concept known to anyone familiar with a functional language. It seems you've just described what I would call mapping a function over an array.

The other powerful notion is that arrays become mapping functions over their index.

There's a decent tutorial now at shakti.com:

https://shakti.com/tutorial/

Yes of course. If you balanced the parentheses it would be syntactically valid k. It assumes a bunch of names, and would be unlikely to do anything useful, but it would be legal.

The k7/shakti tutorial playfully notes that running one's finger along the shifted top row of the keyboard is syntactically valid.

> alt-command-blah-blah-blah

C-h f

And then I type sort of what I want (with helm or ivy, it's a fuzzy match) and select it from the list, which brings up it's documentation and what keystrokes call it.

There is also `where-is` if you remember the name, or `M-x` (or `M-:`) if you don't mind typing it out.

Why would you expect a k.c? This is b. There's a b.c.

A related operator is group (=), which creates a map between the unique elements of a list to their locations.

     x: 10 ? `a`b`c
     x
    `a`c`c`c`c`a`b`a`a`c
     =x
    a|0 5 7 8  
    b|,6       
    c|1 2 3 4 9

I think that this is a matter of practice. I write k/q almost daily, and don't struggle to read other people's code, or my own.

Most code isn't clever oneliners, and is quite readable.

GNU APL is a perfectly reasonable APL implementation.

There are open source implementations of some K versions - Kona, which is K3, and oK, which is ~K5.

J is available under GPL3.

In terms of semantics, sure. However a real part of the charm of APL (and J, and K) are in the syntax, and how notating your program causes you to think about it differently. Something like or/and outer product in the game-of-life oneliner is very straightforward APL, but is much clunkier to write in numpy.

tolower and related things I'm comfortable with - the main question I can't answer is where do you run the weidu mod?

Not OP, but for me it works flawlessly. Load times are instant, lots of nice quality of life features.

Not tried multiplayer, but it's hard to make that worse.

Also never worked out how to mod things, but if you're just after the vanilla experience, it's very good.

The proof of the incompleteness theorem only shows you that recursively-enumerable arithmetic systems are always missing something, because the construction always holds. It doesn't make any grand statements about the structure or nature of things that are true and without proof.

The second incompleteness theorem gives an example of something undecidable that's probably more interesting that the uselessly paradoxical statement in the first: it says that no system can consistently prove its own consistency.

emacs -Q is instantaneous for me. If you're querying MELPA and sychronising packages that might be a cause of the slowness.

Why does having my vote's power scale with my salary make me treat it more responsibly?

There are two key ideas: one is notation as a tool of thought, and thus the symbols are incredibly important (or, if not using symbols, to use similarly lightweight notation as in j/k).

In a semantic sense, the key idea is that you compose operations on array indices. A good example of this is k's where operator, &, which converts an array of booleans into an array of indices where it is true. It's very common to take & of some predicate on your inputs, manipulate that for a while, and then index into something else at the end.

There are also ideas of rank/shape ambivalence, which naturally encompasses broadcasting (so scalar + vector broadcasts the scalar, vector + matrix broadcasts the vector row-wise, etc).

You certainly can implement something with APL's semantics as a library - Numpy does this. The magic of using APL comes from having all these features at once.

You can extend kdb with c functions, but they need to take/return their internal K structures, so you'll need to wrap functions. `2:` is the thing to look at.

Otherwise there's ipc clients, and a very nice native python integration now.

Do some deep learning. It's very straightfoward, and you only need some trivial IO.

Writing a programming language in APL is not for the faint of heart - co-dfns is, alongside it's performance goals, to show that compilers aren't necessarily a bad fit for APL.

There's plenty of nice modern classical music. Lots of it sounds 'normal' - you might like to try something by Thomas Ades, like Asyla or Totentanz.

There's a maximum amount of stuff a single function/code unit can do before becoming unreadable. When writing code, there's a tension between the semantic size of the implementation, and the semantic size of the constituent parts of the problem: very few problems are broken down into clean chunks of code. Quite often, when trying to subjugate the problem to the language, you end up with lots of 'features' of the modular parts: lots of parameters, parameters being complex non-data objects, and so forth.

Breaking stuff down costs, as well - you have to make it clear how something is going to be used. You might write a helper function for one bit in particular, and then rely on additional levels of abstraction to make it clear how this function should be used.

Instead, if you can allow your functions to become semantically larger, you don't need to explain and protect your modularisation. Helper functions with one use are inlined (it's very common that these things have names longer than their definition). Instead of a large tower of abstraction, you just have two levels: the level of the data, and the level of the problem. Your entire program is written as functions, each of which does something in the problem domain, and for each, each definition is immediately clear about what it is doing with the data.

There was an article here, a while ago, called 'smaller code, better code', and with accompanying comments, that explain this better than I can.

This syntax is very readable. The maximum semantic size of a function that's still easy to read is much larger. Functions that do entire things in one go are more common, and make reading about the entire program much easier - the game of life in one line is idiomatic and elegant APL, but it would be an inelegant mess in other languages.

Can't be used commercially.

If you want to try out K, you can either go to Kx and download the 32bit version of kdb+. \ at the prompt (on its own) will enter K mode. This uses K4.

Alternatively, there's the free and open source Kona, which is an implementation of K3, the preceding version.

https://kx.com/download

https://github.com/kevinlawler/kona

> That includes absurdities like "We should write a compiler from JavaScript to wasm to make all our JS faster!"

Is this this absurd? Given you can compile WASM whilst streaming, you should really precompile your JS into WASM if you can.

In the worst case, it is commonly thought (this is P vs NP) that you will have to test a super-polynomial number of solutions. It doesn't have to be all of them.

A problem is in NP if a Turing machine, given the problem, can verify a given solution (assuming that the size of the solution is polynomial in the size of the problem) in a number of steps polynomial in the size of the problem.

An example would be 3-SAT, which takes a boolean predicate of a particular form (that it is conjunctions of disjunctions of 3 variables), and then an assignment of the variables, and checks if it satisfies the predicate. You can do this in polynomial time, so 3-SAT is in NP.

The games themselves are fixed size. They can't be NP-hard, since NP-hardness is a property of difficulty with respect to input size.

They show that you can generalise them and build levels that are NP-hard: for example, in the case of Pokemon, they build systems requiring that the player have a specific team (one that is very unlikely to ever actually be used).

Emacs has Tramp, and you can do the same thing!

One of the things that the GP complains about is evaluation order - in k it follows a simple rule very consistently - programs are evaluated top to bottom, and each expression is evaluated right to left. There are no precedence rules. The instance that I see trip people up all the time is the cast operator $ - people coming from other languages like C or Java expect this to bind more tightly than other operators, but doesn't.