4 ms·

Disingenious and unconvincing, like a sales pitch for a product that is actually bad for you. Yes, that kind of syntax can be wonderfully terse when doing simp

by brazzy 7y ago

Disingenious and unconvincing, like a sales pitch for a product that is actually bad for you. Yes, that kind of syntax can be wonderfully terse when doing simple arithmetic operations on lists of integers. Most programming work does not consist of doing simple arithmetic operations on lists of integers. If you want to convince me that this languagy useable for anything but toy problems specially chosen to demonstrate the language's strengths, show me how it can be used to handle an HTTP request with some special cases for certain headers, or to parse a custom date format with variants, or to implement a game with realtime user input.

chrispsn 7y ago
How about an OS? https://gist.github.com/chrispsn/da00835bb122c42f429a084df83fd746 https://gist.github.com/chrispsn/da00835bb122c42f429a084df83...
- Drakar1903 7y ago
  This is what - I presume - is their implementation of sending an e-mail E:[u:();e:{a::?[a;x;y];J(x)+#y};cz:{$[#u;e/_`u;]};kx:{u,:,(j,j+#x;k_a);e[k]x};kb:{$[=/k;J j-1 0;];kx""};cx:{kx cc`};cv:{kx@9'`}] A:[w::_W%F;j::k;k:0 0;J:{k::2#0|x&#a};lx:{J j+x};y::V+F0,j;z::1'(V;w[1]$a)],E U:{(`Z,'!Z).'+x};V:0;i:0;I::`Z,(!Z)(#Z)!i;y:{I .`y};zf:{$[`kt=x;i+:1;^`W`F?x;I . x;. x]};u::F[0]!#Z;W:{U`V,,u,'0;U`W,,(-':1_u,x),'x 1};z:{U`z;1'(V;U[`a]{$[#x;"";y]}'$!Z;3)} Z:`to`cc`subj`!A$/:4#() This looks like an exercise in obtuseness.
  - bartread 7y ago
    I tend to agree: falls into the category of "just because you can, doesn't mean you should." Actually, that's perhaps a bit harsh. I have some pretty obscure hobbies, and there's certainly nothing wrong with doing this sort of thing if you want to. Still, having done so it's a bit rich to then look askance at the rest of us like we're all idiots for not choosing to go down a similar route with our own systems.
    - TheOtherHobbes 7y ago
      I suspect everyone would love K if they had an extra 30 IQ points to work with. The reason we have Python, Javascript, and Java is because most people (including me) just aren't bright enough to work fluently in these terse APL-alike idioms. They fail because it's hard for most people to keep that many terse symbols and symbolic relationships in memory at the same time, without English labelling and all the other usual memory aids. (In fact basic functional programming is a bit of a stretch for the average commercial developer.) An interesting hypothetical is what a language would look like if it needed an extra 60 IQ points...
      - rtikulit 7y ago
        In the 70's, in high school, I taught myself APL (mostly TOPS-10 APL SF and a bit of IBM APL SV) well enough to grasp the fundamental functional approach and write real programs (and the obligatory game of life in 1 line :-)) At the time I was also using PL/I and the difference was mind expanding. I'm quite sure I don't have an 30 extra IQ points. Mostly I was just mildly obsessed (and these days I find persistence is a workable substitute). It is incredibly valuable to have experience across the range of programming paradigms.
      - bartread 7y ago
        IQ points aren't really anything to do with it: I suspect most programmers, and certainly those who are average or better, could learn to be proficient with K if they invested the time. The real issue is knowing your userbase. Example: we have this in-house DSL that's been around for years and uses a symbolic representation not a million miles from K that we use for automating reports. The problem is it's a pain to onboard people who, whilst they're bright enough, aren't programmers and in any case have many other responsibilities to attend to. Giving them something more readable rather than arcane makes life easier for everyone. And fundamentally we want to make it easy for everyone, not just the top quartile or the top 10%, to quickly crank out high quality automated reports across different market sectors, geos, etc., as well as to modify and maintain these reports into the future.
  - brazzy 7y ago
    A bit more convincing: http://www.kparc.com/edit.k http://www.kparc.com/edit.k Properly formatted and with comments, it almost looks readable. The insistence to use one- or two-letter identifiers that you then have to look up the meaning of in a comment makes it look pretty childish, though. "Look ma, it's still super terse even when doing something real!" Yes kid, it is when you refuse to do the one obvious thing that could actually make it readable.
    - dang 7y ago
      Single-letter identifiers are a natural thing to object to when coming from other language paradigms, i.e. nearly every programming background out there, but this is a category error. What seems ridiculous in one context can be sensible in another. The objection turns out to be parochial. It reminds me of how people think that parentheses are a significant aspect of Lisp, when in practice they're not. The parens look grotesque at first, but once past the novice stage they fade completely into the background and impose no cognitive overhead. Because of their regularity, the parens free you to program without thinking about syntax, allowing you to think more about the problem at hand—a highly liberating experience—yet to someone who hasn't worked with the language long enough to get that experience into muscle memory, they look absurd. Short identifiers are preferred in APL-style languages because longer ones obscure the code. As you get familiar with the idioms of the language, you can pick them out in visual chunks to grok what a program is doing. You're not reading the program operator-by-operator, but phrase-by-phrase. That wouldn't work if the programs used longer identifiers, because then the programs would consist mostly of identifiers, making it harder to scan the phrases, making it harder to grok the code. That's why people don't do it. You can simulate that in more familiar languages: for (ridiculously_long_name = 0; ridiculously_long_name < 100; ridiculously_long_name++) No one writes like that because beyond a certain length, the identifiers distort the code. That's what's going on in APL languages too; it's just that the "certain length" turns out to be 1 or 2. In other words, the reason why APL-style programs adopt this style is not because the programmers are childish, but because the ergonomics of the language make it optimal. This is hard to understand, but only because mainstream languages have completely different ergonomics.
      - 7y ago
bartread 7y ago
> Most programming work does not consist of doing simple arithmetic operations on lists of integers. This^^^. And even when doing simple arithmetic operations on lists of integers it's hard to read unless you've become very familiar with it. This is no good. We actually have an in-house DSL with a symbolic representation that looks very similar to K for our reporting system. It's one of my many missions to gradually phase it out in favour of something with either Python or SQL syntax. This will ease onboarding and drive adoption. The advantage of a language like Python, for example, is that although I wouldn't say I know it, I can read it and understand what's going on most of the time. Same with SQL or Ruby or various other languages. This makes it easy for people to understand what something is doing just by reading it, and opens up the possibility of learning along the lines of "How did Susan do that?", look at Susan's code, and see something that's fairly easy to read, understand, and remember, as opposed to a screed of arcane looking symbols.
kick 7y ago
XML parser: https://a.kx.com/a/k/examples/xml.k https://a.kx.com/a/k/examples/xml.k
- kick 7y ago
  Ray-tracer: http://www.nsl.com/k/ray/raya.k http://www.nsl.com/k/ray/raya.k
  - kick 7y ago
    Graphical spreadsheet application: http://www.nsl.com/papers/spreadsheet.htm http://www.nsl.com/papers/spreadsheet.htm
    - brazzy 7y ago
      With 5 to 10 lines of comment per one line of code, it starts to become readable. You're still left constantly wondering "what do a and x mean in this context, again?" 3/10, would definitely not want to use for any kind of real work.
      - kick 7y ago
        John Earnest links to his tutorial in the Stages of Denial post; if you click it and give it a read, you'll probably understand much easier. But you shouldn't feel pressured to use k: people who advocate for k play the role of a Cassandra who can drown her tears in dollar bills.
        brazzy 7y ago
        A Cassandra... or a victim of Stockholm Syndrome.
  - magicalhippo 7y ago
    So how would this look like if it also needed to handle triangles? And we want textures, so we need texture coordinates and a way to specify per-object materials. Also, the original code just uses bounding spheres, we probably want something better like a kd-tree. In the original code[1] these changes are trivial to make, even for someone new to the code base. How would they look in k? As others I struggle to see past the terseness, but maybe it would make more sense if I could see the program evolve. [1]: https://web.archive.org/web/20070822025008/http://www.ffconsultancy.com/languages/ray_tracer/comparison.html https://web.archive.org/web/20070822025008/http://www.ffcons...

by brazzy 7y ago

chrispsn 7y ago

How about an OS? https://gist.github.com/chrispsn/da00835bb122c42f429a084df83fd746 https://gist.github.com/chrispsn/da00835bb122c42f429a084df83...

Drakar1903 7y ago
This is what - I presume - is their implementation of sending an e-mail E:[u:();e:{a::?[a;x;y];J(x)+#y};cz:{$[#u;e/_`u;]};kx:{u,:,(j,j+#x;k_a);e[k]x};kb:{$[=/k;J j-1 0;];kx""};cx:{kx cc`};cv:{kx@9'`}] A:[w::_W%F;j::k;k:0 0;J:{k::2#0|x&#a};lx:{J j+x};y::V+F0,j;z::1'(V;w[1]$a)],E U:{(`Z,'!Z).'+x};V:0;i:0;I::`Z,(!Z)(#Z)!i;y:{I .`y};zf:{$[`kt=x;i+:1;^`W`F?x;I . x;. x]};u::F[0]!#Z;W:{U`V,,u,'0;U`W,,(-':1_u,x),'x 1};z:{U`z;1'(V;U[`a]{$[#x;"";y]}'$!Z;3)} Z:`to`cc`subj`!A$/:4#() This looks like an exercise in obtuseness.
- bartread 7y ago
  I tend to agree: falls into the category of "just because you can, doesn't mean you should." Actually, that's perhaps a bit harsh. I have some pretty obscure hobbies, and there's certainly nothing wrong with doing this sort of thing if you want to. Still, having done so it's a bit rich to then look askance at the rest of us like we're all idiots for not choosing to go down a similar route with our own systems.
  - TheOtherHobbes 7y ago
    I suspect everyone would love K if they had an extra 30 IQ points to work with. The reason we have Python, Javascript, and Java is because most people (including me) just aren't bright enough to work fluently in these terse APL-alike idioms. They fail because it's hard for most people to keep that many terse symbols and symbolic relationships in memory at the same time, without English labelling and all the other usual memory aids. (In fact basic functional programming is a bit of a stretch for the average commercial developer.) An interesting hypothetical is what a language would look like if it needed an extra 60 IQ points...
    - rtikulit 7y ago
      In the 70's, in high school, I taught myself APL (mostly TOPS-10 APL SF and a bit of IBM APL SV) well enough to grasp the fundamental functional approach and write real programs (and the obligatory game of life in 1 line :-)) At the time I was also using PL/I and the difference was mind expanding. I'm quite sure I don't have an 30 extra IQ points. Mostly I was just mildly obsessed (and these days I find persistence is a workable substitute). It is incredibly valuable to have experience across the range of programming paradigms.
    - bartread 7y ago
      IQ points aren't really anything to do with it: I suspect most programmers, and certainly those who are average or better, could learn to be proficient with K if they invested the time. The real issue is knowing your userbase. Example: we have this in-house DSL that's been around for years and uses a symbolic representation not a million miles from K that we use for automating reports. The problem is it's a pain to onboard people who, whilst they're bright enough, aren't programmers and in any case have many other responsibilities to attend to. Giving them something more readable rather than arcane makes life easier for everyone. And fundamentally we want to make it easy for everyone, not just the top quartile or the top 10%, to quickly crank out high quality automated reports across different market sectors, geos, etc., as well as to modify and maintain these reports into the future.
- brazzy 7y ago
  A bit more convincing: http://www.kparc.com/edit.k http://www.kparc.com/edit.k Properly formatted and with comments, it almost looks readable. The insistence to use one- or two-letter identifiers that you then have to look up the meaning of in a comment makes it look pretty childish, though. "Look ma, it's still super terse even when doing something real!" Yes kid, it is when you refuse to do the one obvious thing that could actually make it readable.
  - dang 7y ago
    Single-letter identifiers are a natural thing to object to when coming from other language paradigms, i.e. nearly every programming background out there, but this is a category error. What seems ridiculous in one context can be sensible in another. The objection turns out to be parochial. It reminds me of how people think that parentheses are a significant aspect of Lisp, when in practice they're not. The parens look grotesque at first, but once past the novice stage they fade completely into the background and impose no cognitive overhead. Because of their regularity, the parens free you to program without thinking about syntax, allowing you to think more about the problem at hand—a highly liberating experience—yet to someone who hasn't worked with the language long enough to get that experience into muscle memory, they look absurd. Short identifiers are preferred in APL-style languages because longer ones obscure the code. As you get familiar with the idioms of the language, you can pick them out in visual chunks to grok what a program is doing. You're not reading the program operator-by-operator, but phrase-by-phrase. That wouldn't work if the programs used longer identifiers, because then the programs would consist mostly of identifiers, making it harder to scan the phrases, making it harder to grok the code. That's why people don't do it. You can simulate that in more familiar languages: for (ridiculously_long_name = 0; ridiculously_long_name < 100; ridiculously_long_name++) No one writes like that because beyond a certain length, the identifiers distort the code. That's what's going on in APL languages too; it's just that the "certain length" turns out to be 1 or 2. In other words, the reason why APL-style programs adopt this style is not because the programmers are childish, but because the ergonomics of the language make it optimal. This is hard to understand, but only because mainstream languages have completely different ergonomics.
    - 7y ago

bartread 7y ago

> Most programming work does not consist of doing simple arithmetic operations on lists of integers. This^^^. And even when doing simple arithmetic operations on lists of integers it's hard to read unless you've become very familiar with it. This is no good. We actually have an in-house DSL with a symbolic representation that looks very similar to K for our reporting system. It's one of my many missions to gradually phase it out in favour of something with either Python or SQL syntax. This will ease onboarding and drive adoption. The advantage of a language like Python, for example, is that although I wouldn't say I know it, I can read it and understand what's going on most of the time. Same with SQL or Ruby or various other languages. This makes it easy for people to understand what something is doing just by reading it, and opens up the possibility of learning along the lines of "How did Susan do that?", look at Susan's code, and see something that's fairly easy to read, understand, and remember, as opposed to a screed of arcane looking symbols.

kick 7y ago

XML parser: https://a.kx.com/a/k/examples/xml.k https://a.kx.com/a/k/examples/xml.k

kick 7y ago
Ray-tracer: http://www.nsl.com/k/ray/raya.k http://www.nsl.com/k/ray/raya.k
- kick 7y ago
  Graphical spreadsheet application: http://www.nsl.com/papers/spreadsheet.htm http://www.nsl.com/papers/spreadsheet.htm
  - brazzy 7y ago
    With 5 to 10 lines of comment per one line of code, it starts to become readable. You're still left constantly wondering "what do a and x mean in this context, again?" 3/10, would definitely not want to use for any kind of real work.
    - kick 7y ago
      John Earnest links to his tutorial in the Stages of Denial post; if you click it and give it a read, you'll probably understand much easier. But you shouldn't feel pressured to use k: people who advocate for k play the role of a Cassandra who can drown her tears in dollar bills.
      - brazzy 7y ago
        A Cassandra... or a victim of Stockholm Syndrome.
- magicalhippo 7y ago
  So how would this look like if it also needed to handle triangles? And we want textures, so we need texture coordinates and a way to specify per-object materials. Also, the original code just uses bounding spheres, we probably want something better like a kd-tree. In the original code[1] these changes are trivial to make, even for someone new to the code base. How would they look in k? As others I struggle to see past the terseness, but maybe it would make more sense if I could see the program evolve. [1]: https://web.archive.org/web/20070822025008/http://www.ffconsultancy.com/languages/ray_tracer/comparison.html https://web.archive.org/web/20070822025008/http://www.ffcons...