[kbelder]

How does that scale up to program that's thousands of lines? What if you have a hundred different vectors? You're not going to be calling them v1, v2, ...

So does it end up as

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

Or, do you just not do that sort of stuff in these languages? I'm not very familiar with them, but I have ended up with some pretty long programs using Pandas in Python.

[kelas]

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

[RodgerTheGreat]

very important things should have short names. locals you're immediately operating upon should have short names. short names should be used in a consistent way.

less important things can have longer names. variables in a broader scope can have longer names.

if you have a hundred different vectors, don't just dump them in a pile; put them in dictionaries, tables, namespaces, or scopes.

[kelas]

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.