6 ms·
I don't really understand these array based J/K/APL languages but from a distance it would seem like they would primarily be useful for numerical based work suc
by zests 6y ago
I don't really understand these array based J/K/APL languages but from a distance it would seem like they would primarily be useful for numerical based work such as finance or calculating patterns on 2d arrays (game of life). The languages seem more mathematical than software engineering based.
It reminds me about when I was learning my first programming language. The book had a ton of example with simple numerical computations (e.g., calculate leap years) and I soon became competent with the language's facility for basic mathematical operations. But as a programmer now I have very little use for these operations so when I learn a new language I have only a rudimentary understanding of how to do math in that language.
Is this correct or am I misunderstanding the usefulness of array based languages?
- dTal 6y agoAPL is best thought of, not as a "programming language", but as a DSL for array manipulation. The syntax is sadly dead. The semantics live on in the most mainstream of places, notably Numpy. Trying to write entire full-features programs in APL should be thought of as roughly the same as doing so in Awk. Possible, and even beautiful - but not a serious endeavor. We'd be better off if other languages incorporated APL as a first class DSL, the same way they incorporated regex.
- mncharity 6y ago> Numpy https://analyzethedatanotthedrivel.org/2018/03/31/numpy-another-iverson-ghost/ https://analyzethedatanotthedrivel.org/2018/03/31/numpy-anot... . https://news.ycombinator.com/item?id=16982086 https://news.ycombinator.com/item?id=16982086 . > if other languages incorporated APL as a first class DSL, the same way they incorporated regex April for Common Lisp et al? https://news.ycombinator.com/item?id=22225136 https://news.ycombinator.com/item?id=22225136
- kd0amg 6y agoNumpy has a very rough approximation of APL's semantics. The broadcasting rules are quite different, and it's missing some rather fundamental things like automatically lifting functions with argument rank other than 0.
- beagle3 6y agoIt requires a different mindset. You might not need leap year calculation often, but many things you do have a short, simple, efficient J/K/APL implementation entirely different from how you’d do it in other languages. E.g. to check if a text string s has balanced parantheses in C/Java/Python, you would have a loop to increase/decrease depth based on character, error if negative at any point, and balanced if zero at end. In k, you would compute the running balance at each point b:+\(s=“(“)-(s=“)”) And then check the minimum of it &/b to see if it is negative, and the last element *|b To see if it is zero. This is a text parsing problem, but has an elegant vector solution. Most things do, whether it is graphics, database, whatever - but it’s rarely intuitive if you are not used to thinking in vectors. Also, the expression for b above can be half as long, but you would really need to be versed in k to understand it.
- chongli 6y agoThat’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 6y agoThe 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)
- smartmic 6y agoI agree that array based programming languages are especially useful for solving mathematical problems. For anyone new to the field, a very approachable introduction to array programming is in the Klong book, here an excerpt: http://t3x.org/klong/ap-excerpt.pdf http://t3x.org/klong/ap-excerpt.pdf
- zhte415 6y agoNot just 2d, nd, three, four, five, whatever dimensions, a bit agnostic in this, as is algebra. I can't claim to have dabbled in the language but was somewhat aware in the 80s and 90s. An APL magazine from the 90s was called Vector if I recall correctly. Yes quite mathematical, and an interesting community then of some quite smart melding of math heads, still a huge focus on performance, played with it on a VAX.
- kick 6y agoThey're useful for a lot more than math, certainly. APL has a lot of world-firsts that wouldn't really make sense for a language useful for nothing more than math; looking at the history of IPSA and similar will probably give you some good ideas. The user 'dTal in this thread is far from giving you an accurate story.