kelas

oh no, not really.

this is not writing in assembly, and definitely not in bytecode.

but if you are indeed an elite intel(R) assembly coder, and old enough for eax and rax to have taken too much toll on you, or your time away from your family, and of your career as a computer programmer in general - you should probably consider a more modern, more simple and elegant isa, which is now omnipresent, royalty-free, has a huge encoding margin for custom extenstions, and spares you from the childhood trauma of 16 GPRs. it is called riscv.

k family languages isn't asm. it doesn't expect you to hardly ever need anything other than x,y,z in terms of function arguments. this is why they are so conveniently implicitly auto-declared for you in your function - just reference them, done.

it is useful, man. it works.

> If you're arguing that "Read-Eval-Print cycle" doesn't count as REPL, then it pretty strongly undercuts your argument that "dialog approach".

no, thankfully, it doesn't, and here's why. as i elucidated above, PDP-1 was indeed a revolutionary "el cheapo" computer, which DEC managed to ship over 50 units of. it gave birth to hacker culture, just because it had to be hacked with all kinds of peg legs in order to be useful. now, to the point:

1. PDP-1 is mostly remembered for Spacewar!, a groundbreaking space combat game invented by a dude who also coincidentally invented large parts of LISP while on IBM payroll.

2. APL, after its debut in 1965-1966, had its first official application to teach formal methods in systems design at NASA Goddard Center.

My point should be obvious, but just in case:

in our line of work (between sessions on Hacker News) we are sometimes faced with the concept of "production" (usually on Friday afternoons). this idea really matters. it makes all the difference between fooling around and the real deal.

therefore, as it must follow, and as i mentioned much earlier, APL was and remains the very first real REPL system, although they didn't really use that terminology. all i meant is that in 21st century people take Chrome's devconsole, ipython, node, zsh for granted. with completions, hints, all that.

(in APL'esque family, by the way, there's hardly anything to hint or auto-complete. mathematics doesn't work that way. by the way, not coincidentally, one of the most successful modern descendants of APL is called Wolfram Mathematica)

are we on the same page?

this is a gross undeappreciation of a truly remarkable effort by my dear friend and associate. also, at least one of the languages presented is due to him. you can call him @ktye. he's too modest.

it is not a Kunstkamera or some computer cryptozoology extravaganza. many things are shown here, from different eras, but some are not - they are evolving. and progress takes sacrifice.

cheers k.

ps. we usually spell atw as atw :) he also goes by a. don't chicken out, send him an email. he's a very friendly guy. just like me.

(well, at least the mf is big in japan now lol)

julia is cool, hands down.

only typical k binary will be less than 200kb and doesn't need stdlib. it still needs a few syscalls, but we're working on that.

and julia has this small and insignificant dependency called llvm. i bullshit you not:

  kelas@prng ~ % cd /opt/llvm-project
  kelas@prng llvm-project % du -hd0
   14G .
  kelas@prng llvm-project %

> Or, do you just not do that sort of stuff in these languages?

i tell you more. it is very much recommended to avoid doing this sort of stuff in all languages.

  v_sepallength: 11 14 12
  v_sepallthickness: 1.3 1.5 1.2
  mul[v_sepallength;v_sepalthickness]

no:

   /sepal:lengths and stroke widths
   spl:[l:11 14 12;w:1.3 1.5 1.2]    /this is your "struct", if you will
  
   spl.w
  1.3 1.5 1.2    /proof

   */spl
  14.3 21. 14.4  /for mul, we don't even have to bother with field names

   */spl`l`w     /but if you insist, lets make it explicit
  14.3 21. 14.4

to produce a "factory" for well-formed spl objects is a no-brainer as well.

why we don't use v_ prefix:

  1. everything what can be a vector should be a vector.
  2. we can't use underscore anyway - it is an operator.

exactly.

the complexity is built differently in k.

  * namespaces do exist, and are just as useful as they are in c++ and especially my beloved *sun.misc.unsafe*. i recommend.

  * instead of passing 20 arguments to a function (which is impossible - the limit is lower), we pass a dictionary if we have to. k **pretends** that everything is passed by value, but in reality it is much smarter than that.

  * notion of *scopes* is a bit of a non-sequitur here, but it is fundamentally important that there is no *lexical scoping* in k. the only two scopes which are available from the scope of a lambda are exactly *local* and *global*. and for as long as your function doesn't mess around with global scope or i/o (which is essentially the same thing), it remains pure, which is super cool. this design is not just for simplicity - it is for a good reason, and more than one.

  * the above doesn't mean that it is impossible to create a *closure* in k and pass it around as a value.

  * functions take up to three implicit arguments - named x,y and z (they can be renamed explicitly, but why not just document their semantics instead, in-situ?). all you need to do to declare xyz is reference them in the function definition. in competent k code, you'll rarely see a function with more than xyz.

 * in k community, we don't use upper case unless the apartment is on fire. god forbid.

 * shorter names and more documentation, and there will be joy.

> t=\:t:!x

this is of course obvious first idea, but the recipe from above is actually from the official k4 cookbook. t=t is less innocent than it seems, i'm afraid.

in k7/k9, we can:

  10^@[100#0.;11*!10;1.]    /just for more lulz

there's also a way to mutate it in place!

> That is wildly disingenuous.

assuming you're referring to numpy as to have anything to do with python spec, i totally agree with you. only it doesn't. so don't pytorch and pandas (and good so, poor python doesn't need any extra help to be completely f).

> you get an nxn identity matrix by...

no, man, that's how you get it. really advanced technique, kudos!

i get it by:

   id:{...}     /there are many ways to implement identity in k, and it's fun!
   id 3
  +1.00 +0.00 +0.00
  +0.00 +1.00 +0.00
  +0.00 +0.00 +1.00

but if you can keep a secret, more recently we've gotten so lazy and disingenuous in k land, and because we need them bloody matrices so often now, we just do it like so:

   &3
  +1.00 +1.00 +1.00
  +1.00 +1.00 +1.00
  +1.00 +1.00 +1.00

   =3
  +1.00 +0.00 +0.00
  +0.00 +1.00 +0.00
  +0.00 +0.00 +1.00

(but of course before we do that we first install python4, numpy, pytorch, pandas and polars - not because we need them, just to feel like seasoned professionals who know what they're doing)

for that matter, i always wonder how people mistake python for numpy :) they have surprisingly little in common.

but enough talking about languages that suck. let's talk about python!

i'm not some braniac on a nerd patrol, i'm a simple guy and i write simple programs, so i need simple things. let's say i want an identity matrix of order x*x.

nothing simpler. i just chose one of 6 versions of python found on my system, create a venv, activate it, pip install numpy (and a terabyte of its dependencies), and that's it - i got my matrix straight away. i absolutely love it:

  np.tile(np.concatenate([[1],x*[0]]),x)[:x*x].reshape(*2*[x])

and now lets see just how obscure and unreadable exactly the same thing looks in k:

  (2#x)#1,x#0

no wonder innocent people end up with brain aneurisms and nervous breakdowns.

> without it being tacit, it would probably be more readable

definitely. tacit can be taken a bit too far sometimes, but when a certain discipline is observed (just like in any language, really) it is no less readable than... let me see. oh, lets take some typical pandas/polars heroics - no, those things don't give me brain aneurisms and not too shocking either. they just make wanna vomit no less than the poor people who were forced to write it and contemplate what they've done.

> tacit is "bad"

not at all. it takes one time to see how avg looks in explicit notation to understand that the idea of trains is totally justified.

> the question of how to thread data around without naming it is an interesting one to me.

good question. see above - yes indeed, things can be taken to extremes. when an apl/k program is a oneliner 80 chars long, that's just not cool. there is no reason not to break it down a bit into moving parts with names (and ample space on the right margin for annotations). in no way APL and friends are somehow exempt from commenting their code. but that's not really endemic to array languages, you'd agree.

> seems to disagree

no, actually i think Wikipedia got it right:

  "The 1974 Maclisp reference manual by David A. Moon attests "Read-eval-print loop" on page 89, but does not use the acronym REPL.[7]
  Since at least the 1980s, the abbreviations REP Loop and REPL are attested in the context of Scheme.[8][9]"

The first APL interpreter was implemented on System/360 in 1965. Iverson got a Turing in 1979.