3 ms·

That’s a very trivial example though. For a more real-world example, consider multiple different delimiters for matching. The C/Java/Python version is still tri

That’s a very trivial example though. For a more real-world example, consider multiple different delimiters for matching. The C/Java/Python version is still trivial if you use a stack instead of a numeric counter, returning an error if you try to pop an empty stack or one whose top element does not correspond to the delimiter you’re matching. How would you do this in K?

beagle3 7y ago
The stack makes it much less trivial than a counter in Python, and even less so in e.g. C which lacks a built in data type useful as a stack (leading many to allocate a fixed size stack and either reject valid strings going too deep or have buffer overflows) Indeed, a multi delimiter version is harder in K as well. I am writing this on a phone without K (as I did the prev post) so will not attempt a runnable example; but, I would implement it as a state machine, taking Stack and one char as input; and returning new stack as output; then reducing it on s; if final stack is empty, it is valid. It would still be one line. K loves state machines. When tokenizing/parsing in K, you’ll often see people write DFA tables by hand because it turns out to be simpler than writing a lex spec; also shift/reduce tables because it is simpler than yacc grammars. I would not recommend these if you want to write a C++ compiler, or you need yacc’s error reporting and recovery. But 95% of the time, yacc/lex are for simple calc or DSL expressions that ARE easier to code by hand in K. And that’s another place K/APL mindset differs significantly from common practice: Avoid solving the general form of your problem if you can solve the particular one in one line (which you often can, and is often enough)
- chongli 7y ago
  It’s not very hard to code up a dynamically allocated stack in C. I think it’s of fundamental importance for a programming language to let you easily implement lots of different data structures efficiently. Are you saying K has a stack built-in (or another structure that can easily implement a stack)? Okay then how about a problem for which K lacks a built in data structure? I would google it myself but I can’t seem to get any results on K.
  - beagle3 7y ago
    K has lists somewhat comparable to Python’s, which is what i’d use to implement a stack in either (append to push, shorten/pop to pop) You are moving the goalposts. You can construct problems where eventually K cannot be shorter/simpler - this is a consequence of Turing equivalence and kolmogorov complexity. The claim I made was that, for problems that people actually need to solve, K And APL often have a short, simple, elegant and usually performant solution. I stress that I am talking about the actual problems - that is, creating a mapping from an input set to a respective output set - I am NOT claiming that the solutions people reach for in language $x can be expressed more elegantly in K/APL. Another example is “flatten” - expressed as ,// in K, and which could be read “join over until-converged”. This is not how you would implement it in Lisp or Python likely - and it is likely less efficient at runtime than how you WOULD implement it in Lisp. But it is arguably short, simple, elegant and (depending on implementation and input structures) likely acceptably efficient. Added p.s: it is not hard to code a dynamically allocated stack in list, but it is about as complicated as checking the balance, which makes the balanced parentheses problem twice as complicated in C compared to even Python; which is why so many C buffer overflows exist - the buffer Management was accidental Complexity and therefore gets less attention than the security implications of a buffer overflow would warrant.
    - chongli 7y ago
      The reason I'm asking about further problems is not because I want to "move the goalposts" but because I (and likely other people) are skeptical about the ability of K (and other APL family languages) scale beyond simple problems or specific niches (such as finance). It's fine if it can't though. Different languages have different niches. You wouldn't write an operating system in python. I'd just like to know if there is a use case for K outside of finance (or other sorts of math on large data sets). Has anyone written a video game in K?
      - clarry 7y ago
        > The reason I'm asking about further problems is not because I want to "move the goalposts" but because I (and likely other people) are skeptical about the ability of K (and other APL family languages) scale beyond simple problems or specific niches (such as finance). Yeah and I've become wary of languages that are an island where everything is nice as long as you can change the problem until it has a nice solution in the language. Forth is a bit like that. The risk is that all these nice and elegant things fall apart like a house of cards once you try to merge the island with the ugly nasty real world, where legacy compatibility and rigid requirements from various stakeholders define the problem. I think most people out there are primarily interested in general purpose languages that they can learn, master, and use to attack just about every problem, ugly or not. In that case, it's only natural to be reserved about proposals that are sold as very elegant but the demonstrations of which are quite removed from the ugly real world problems. I'm kind of on the edge. I can tell that a bunch of cool stuff has been done in APL and derivatives, but I'm still not sure whether it'd hold up e.g. in my day-to-day job (which involves lots of networking, async i/o, timers & callbacks, parsing, message passing, crypto, etc). And I still feel like there aren't enough relevant real world examples (or I'm just not able to find them much).
- kmstout 7y ago
  > [...] a state machine, taking Stack and one char as input [...] https://en.wikipedia.org/wiki/Pushdown_automaton https://en.wikipedia.org/wiki/Pushdown_automaton

beagle3 7y ago

The stack makes it much less trivial than a counter in Python, and even less so in e.g. C which lacks a built in data type useful as a stack (leading many to allocate a fixed size stack and either reject valid strings going too deep or have buffer overflows) Indeed, a multi delimiter version is harder in K as well. I am writing this on a phone without K (as I did the prev post) so will not attempt a runnable example; but, I would implement it as a state machine, taking Stack and one char as input; and returning new stack as output; then reducing it on s; if final stack is empty, it is valid. It would still be one line. K loves state machines. When tokenizing/parsing in K, you’ll often see people write DFA tables by hand because it turns out to be simpler than writing a lex spec; also shift/reduce tables because it is simpler than yacc grammars. I would not recommend these if you want to write a C++ compiler, or you need yacc’s error reporting and recovery. But 95% of the time, yacc/lex are for simple calc or DSL expressions that ARE easier to code by hand in K. And that’s another place K/APL mindset differs significantly from common practice: Avoid solving the general form of your problem if you can solve the particular one in one line (which you often can, and is often enough)

chongli 7y ago
It’s not very hard to code up a dynamically allocated stack in C. I think it’s of fundamental importance for a programming language to let you easily implement lots of different data structures efficiently. Are you saying K has a stack built-in (or another structure that can easily implement a stack)? Okay then how about a problem for which K lacks a built in data structure? I would google it myself but I can’t seem to get any results on K.
- beagle3 7y ago
  K has lists somewhat comparable to Python’s, which is what i’d use to implement a stack in either (append to push, shorten/pop to pop) You are moving the goalposts. You can construct problems where eventually K cannot be shorter/simpler - this is a consequence of Turing equivalence and kolmogorov complexity. The claim I made was that, for problems that people actually need to solve, K And APL often have a short, simple, elegant and usually performant solution. I stress that I am talking about the actual problems - that is, creating a mapping from an input set to a respective output set - I am NOT claiming that the solutions people reach for in language $x can be expressed more elegantly in K/APL. Another example is “flatten” - expressed as ,// in K, and which could be read “join over until-converged”. This is not how you would implement it in Lisp or Python likely - and it is likely less efficient at runtime than how you WOULD implement it in Lisp. But it is arguably short, simple, elegant and (depending on implementation and input structures) likely acceptably efficient. Added p.s: it is not hard to code a dynamically allocated stack in list, but it is about as complicated as checking the balance, which makes the balanced parentheses problem twice as complicated in C compared to even Python; which is why so many C buffer overflows exist - the buffer Management was accidental Complexity and therefore gets less attention than the security implications of a buffer overflow would warrant.
  - chongli 7y ago
    The reason I'm asking about further problems is not because I want to "move the goalposts" but because I (and likely other people) are skeptical about the ability of K (and other APL family languages) scale beyond simple problems or specific niches (such as finance). It's fine if it can't though. Different languages have different niches. You wouldn't write an operating system in python. I'd just like to know if there is a use case for K outside of finance (or other sorts of math on large data sets). Has anyone written a video game in K?
    - clarry 7y ago
      > The reason I'm asking about further problems is not because I want to "move the goalposts" but because I (and likely other people) are skeptical about the ability of K (and other APL family languages) scale beyond simple problems or specific niches (such as finance). Yeah and I've become wary of languages that are an island where everything is nice as long as you can change the problem until it has a nice solution in the language. Forth is a bit like that. The risk is that all these nice and elegant things fall apart like a house of cards once you try to merge the island with the ugly nasty real world, where legacy compatibility and rigid requirements from various stakeholders define the problem. I think most people out there are primarily interested in general purpose languages that they can learn, master, and use to attack just about every problem, ugly or not. In that case, it's only natural to be reserved about proposals that are sold as very elegant but the demonstrations of which are quite removed from the ugly real world problems. I'm kind of on the edge. I can tell that a bunch of cool stuff has been done in APL and derivatives, but I'm still not sure whether it'd hold up e.g. in my day-to-day job (which involves lots of networking, async i/o, timers & callbacks, parsing, message passing, crypto, etc). And I still feel like there aren't enough relevant real world examples (or I'm just not able to find them much).
kmstout 7y ago
> [...] a state machine, taking Stack and one char as input [...] https://en.wikipedia.org/wiki/Pushdown_automaton https://en.wikipedia.org/wiki/Pushdown_automaton