4 ms·

Good question! You're generally quick to ask questions in any threads of any APL variant, so I'll answer for both it and k: Workspaces are the answer for APL.

by kick 6y ago

Good question! You're generally quick to ask questions in any threads of any APL variant, so I'll answer for both it and k: Workspaces are the answer for APL. This one is generally more-agreeable to your average person. Here's a quick explainer of them, from a now-dead implementation: http://www.microapl.com/apl/apl_concepts_chapter2.html http://www.microapl.com/apl/apl_concepts_chapter2.html However, the mindset for k doesn't really align with 'complex programs': simplicity is generally more useful than complexity, and it's not like there's a difference in how much you can get done with either. Consider this two-page IM implementation: http://nsl.com/papers/instant.htm http://nsl.com/papers/instant.htm Now, it's obviously just a silly demo, but in how many other languages could you get a graphical client and server in two pages of code? (Alternatively, in five lines but not graphical: http://www.kparc.com/$/chat.k http://www.kparc.com/$/chat.k ) Or a graphical spreadsheet program in one: http://nsl.com/k/s/s.k http://nsl.com/k/s/s.k I'm not trying to imply that these are particularly-complex programs, but I'd argue that in most cases, trying to organize programs more than what's obvious (generally a directory) just makes them more complex for no benefit. This goes for many languages, not just k. Consider Apter's SLACK, a SASL-like (direct Haskell/Miranda precursor) functional (k) programming language, written in k: http://www.nsl.com/k/slack/ http://www.nsl.com/k/slack/ You'll notice that it's pretty complex as far as these things go, but the organization of it is far less complex than most programs of a similar level of complexity. I'd argue that it actually works to the benefit of the reader, though I can see how you might disagree.

saagarjha 6y ago
To be clear, I'm not sure I could ever call an inability to write complex programs a feature, but I do recognize that there are many useful languages with this property; Bash comes to mind. Thanks for the links, by the way; I am sure I'll get a kick out of them when I eventually do know how to read k ;)
- kick 6y ago
  It's not an inability. It's just that there's no reason for complexity. C++, for example, is a language built around managing complexity. k, on the other hand, is a language built around avoiding complexity. SLACK is an actual language! It does all of the things you really need an actual language to do! And yet the implementation's not particularly complex. bash isn't really at all similar; bash is actually more like Swift or Javascript than k is like bash. bash is for extremely complex programs: programs that are other programs taped together. k takes the reverse position: there's absolutely no reason you should ever, ever, ever create something complex if a simple solution will do. If you can create a programming language, an operating system, a windowing system, a database that can handle millions of terabytes of data without flinching, etc. all without complexity, why would you opt for the more-complex solution? Complexity kills manageability, clarity & fun. Simplicity allows you to do the same things, faster, and without sacrifices. EDIT: In some ways, you can consider this very similar to Chuck Moore's philosophy on programming, although taking a different approach to it. I'm paraphrasing here, so forgive me if I get the quote wrong, but something along the lines of 'FORTH will do anything you could possibly want, but it won't do everything'. If you accept the premise that a language shouldn't be infinite, which isn't particularly controversial[1], it becomes much less of a leap to think, "Wait, why not allow the programmer to expand where they need, and just not throw in what they don't? It'll take less overall cognitive load!" Now, that's why FORTH is pretty interesting as a language. k, on the other hand, doesn't really lend itself to being expanded (there are solutions to expanding the language itself; many people & companies do). However, it takes the same philosophy externally rather than internally: "We're not going to give you everything, we're going to give you a method of creating anything in a highly-efficient way." An analogy that I think works fine: k is LEGO to your average programming language's pre-built kits of Lincoln Logs. [1] This is why Lisp is dead (Common Lisp killed it) and C is still going strong, despite the former being great (except Common Lisp) and the latter being...highly-controversial, and why when a simple Lisp was released it blew up for quite a while despite absolute mismanagement (Clojure).

by kick 6y ago

saagarjha 6y ago

To be clear, I'm not sure I could ever call an inability to write complex programs a feature, but I do recognize that there are many useful languages with this property; Bash comes to mind. Thanks for the links, by the way; I am sure I'll get a kick out of them when I eventually do know how to read k ;)

kick 6y ago
It's not an inability. It's just that there's no reason for complexity. C++, for example, is a language built around managing complexity. k, on the other hand, is a language built around avoiding complexity. SLACK is an actual language! It does all of the things you really need an actual language to do! And yet the implementation's not particularly complex. bash isn't really at all similar; bash is actually more like Swift or Javascript than k is like bash. bash is for extremely complex programs: programs that are other programs taped together. k takes the reverse position: there's absolutely no reason you should ever, ever, ever create something complex if a simple solution will do. If you can create a programming language, an operating system, a windowing system, a database that can handle millions of terabytes of data without flinching, etc. all without complexity, why would you opt for the more-complex solution? Complexity kills manageability, clarity & fun. Simplicity allows you to do the same things, faster, and without sacrifices. EDIT: In some ways, you can consider this very similar to Chuck Moore's philosophy on programming, although taking a different approach to it. I'm paraphrasing here, so forgive me if I get the quote wrong, but something along the lines of 'FORTH will do anything you could possibly want, but it won't do everything'. If you accept the premise that a language shouldn't be infinite, which isn't particularly controversial[1], it becomes much less of a leap to think, "Wait, why not allow the programmer to expand where they need, and just not throw in what they don't? It'll take less overall cognitive load!" Now, that's why FORTH is pretty interesting as a language. k, on the other hand, doesn't really lend itself to being expanded (there are solutions to expanding the language itself; many people & companies do). However, it takes the same philosophy externally rather than internally: "We're not going to give you everything, we're going to give you a method of creating anything in a highly-efficient way." An analogy that I think works fine: k is LEGO to your average programming language's pre-built kits of Lincoln Logs. [1] This is why Lisp is dead (Common Lisp killed it) and C is still going strong, despite the former being great (except Common Lisp) and the latter being...highly-controversial, and why when a simple Lisp was released it blew up for quite a while despite absolute mismanagement (Clojure).