4 ms·

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 goalp

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).
  - beagle3 7y ago
    > 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've had more of that experience with Java than with K in the late 1990s and early 2000s. Java wasn't new, and was well accepted, but the ecosystem was horrible and interfacing to other systems required great effort and was abysmal in general. The issue you are talking about is not a language issue, it's an ecosystem issue. K recognizes it by not trying to be all things to all people - it's incredibly easy to FFI directly, and to connect through various interprocess methods (including a native efficient KIPC well supported from just about every other language environment). Arthur also dropped native GUI in 2005, even though it was incredibly effective (by far the easiest way to get a GUI - way easier than VB6 for example; http://nsl.com http://nsl.com has a spreadsheet, calculator, and more showing just how easy). It was incredibly effective, but also incredibly unattractive (the term "milspec" was often used by users). This the issue you mention - users wanted beautiful GUIs, often web ones, that they could put their own touch to. The requirements are rigid and have inherent complexity that general elegance cannot help with. K is decoupled enough to not have to solve everything to be extremely useful. I don't know if it's still the case, but in 2004, if you called Kx systems (the people who sell K) and asked for an evaluation, they would send a person who would solve YOUR problems with K on YOUR system, working 1-2 weeks. Then you got 1-2 weeks of evaluation; and then they charged tens of thousands of $$$ for the solution if you wanted to keep using it. And many did. Most project specs today include requirements that are accidental complexity, rather than inherent. K/APL (and their philosophy) is about solving the inherent complexity elegantly. It's often possible, but rarely practiced, that you can solve the inherent complexity one way, and the accidental complexity another way, and it ends up being much simpler overall.
    - clarry 7y ago
      > The issue you are talking about is not a language issue, it's an ecosystem issue. K recognizes it by not trying to be all things to all people - it's incredibly easy to FFI directly, and to connect through various interprocess methods (including a native efficient KIPC well supported from just about every other language environment). I'm afraid this only makes my point stronger. If I'm pushing the ugly complexity outside of K with an FFI, I'll be stuck writing the ugly plumbing (a major part of the job) in some other language. For the uninitiated it is very difficult to say whether or how much will be left for K to handle, if anything. That kind of thing would make K look like a one-trick pony, and maybe not worth investing in. > Most project specs today include requirements that are accidental complexity, rather than inherent. I agree, and I'm afraid that in many projects (including my dayjob) the accidental complexity is the bigger job. Even if I could solve the inherent complexity of all we do in one beautiful line of code, we're still stuck with a mountain of crap from 2-3 decades of legacy and bad design that really can't be changed.
- RodgerTheGreat 7y ago
  How about a nice game of snaKe? http://johnearnest.github.io/ok/ike/ike.html?key=Sfm0ER_9 http://johnearnest.github.io/ok/ike/ike.html?key=Sfm0ER_9

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).
- beagle3 7y ago
  > 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've had more of that experience with Java than with K in the late 1990s and early 2000s. Java wasn't new, and was well accepted, but the ecosystem was horrible and interfacing to other systems required great effort and was abysmal in general. The issue you are talking about is not a language issue, it's an ecosystem issue. K recognizes it by not trying to be all things to all people - it's incredibly easy to FFI directly, and to connect through various interprocess methods (including a native efficient KIPC well supported from just about every other language environment). Arthur also dropped native GUI in 2005, even though it was incredibly effective (by far the easiest way to get a GUI - way easier than VB6 for example; http://nsl.com http://nsl.com has a spreadsheet, calculator, and more showing just how easy). It was incredibly effective, but also incredibly unattractive (the term "milspec" was often used by users). This the issue you mention - users wanted beautiful GUIs, often web ones, that they could put their own touch to. The requirements are rigid and have inherent complexity that general elegance cannot help with. K is decoupled enough to not have to solve everything to be extremely useful. I don't know if it's still the case, but in 2004, if you called Kx systems (the people who sell K) and asked for an evaluation, they would send a person who would solve YOUR problems with K on YOUR system, working 1-2 weeks. Then you got 1-2 weeks of evaluation; and then they charged tens of thousands of $$$ for the solution if you wanted to keep using it. And many did. Most project specs today include requirements that are accidental complexity, rather than inherent. K/APL (and their philosophy) is about solving the inherent complexity elegantly. It's often possible, but rarely practiced, that you can solve the inherent complexity one way, and the accidental complexity another way, and it ends up being much simpler overall.
  - clarry 7y ago
    > The issue you are talking about is not a language issue, it's an ecosystem issue. K recognizes it by not trying to be all things to all people - it's incredibly easy to FFI directly, and to connect through various interprocess methods (including a native efficient KIPC well supported from just about every other language environment). I'm afraid this only makes my point stronger. If I'm pushing the ugly complexity outside of K with an FFI, I'll be stuck writing the ugly plumbing (a major part of the job) in some other language. For the uninitiated it is very difficult to say whether or how much will be left for K to handle, if anything. That kind of thing would make K look like a one-trick pony, and maybe not worth investing in. > Most project specs today include requirements that are accidental complexity, rather than inherent. I agree, and I'm afraid that in many projects (including my dayjob) the accidental complexity is the bigger job. Even if I could solve the inherent complexity of all we do in one beautiful line of code, we're still stuck with a mountain of crap from 2-3 decades of legacy and bad design that really can't be changed.
RodgerTheGreat 7y ago
How about a nice game of snaKe? http://johnearnest.github.io/ok/ike/ike.html?key=Sfm0ER_9 http://johnearnest.github.io/ok/ike/ike.html?key=Sfm0ER_9