> Excellent question! Personally, I'd argue that a language cannot be viewed in isolation from the problems it's trying to solve.
I'm not sure I'd agree with that, at least not entirely.
A language is a tool for thinking. It doesn't solve problems by itself, but it is a good language if it makes thinking easier. k is a great tool for thinking! With only 25 (or so) easily accessible symbols, it's amazing we got about a hundred primitive operations out of them, but what's really incredible is how tastefully Arthur selected those primitive operations such that the symbol could indicate an entire class of operations.
Some work well: - means subtraction and negation. Others are cute: < means grade (ascending) and less-than (and the grade of a grade turns out to be pretty useful!). Some are (however) unfortunate: + means flip and addition (which aren't the same thing at all), and I don't think + would be flip if flipping wasn't so useful.
And it's the tool that matters to me: I don't think I ever used array_flip in php until I learned flip in k, and now it's "obvious" (although PHP's array_flip is limited to a single use-case and requires other functions for other use cases, oh well). And I'll probably know how flip works until the day I die, and if I need it (in another language), I'll probably just make it again.
The tool has survived! And it's the tool that I go rooting in languages to find.
Lisp and Erlang have some really great tools (concepts) like this.
> 5 years ago I maintained decades old HLASM programs for IBM mainframes during a consulting gig and haven't touched anything like it since.
How funny!
I've had almost the same exposure to HLASM (although it was more than a decade ago)- consulting gig, never again. Any language designer who thinks comments can begin only on the first column needs to be taken out and shot.
However I think having to refresh myself on exactly how BALR works, or what types dyadic ! takes isn't going to waste much time. Are these real concerns you have about forgetting the tools you learn?
I'm not sure I'd agree with that, at least not entirely.
A language is a tool for thinking. It doesn't solve problems by itself, but it is a good language if it makes thinking easier. k is a great tool for thinking! With only 25 (or so) easily accessible symbols, it's amazing we got about a hundred primitive operations out of them, but what's really incredible is how tastefully Arthur selected those primitive operations such that the symbol could indicate an entire class of operations.
Some work well: - means subtraction and negation. Others are cute: < means grade (ascending) and less-than (and the grade of a grade turns out to be pretty useful!). Some are (however) unfortunate: + means flip and addition (which aren't the same thing at all), and I don't think + would be flip if flipping wasn't so useful.
And it's the tool that matters to me: I don't think I ever used array_flip in php until I learned flip in k, and now it's "obvious" (although PHP's array_flip is limited to a single use-case and requires other functions for other use cases, oh well). And I'll probably know how flip works until the day I die, and if I need it (in another language), I'll probably just make it again.
The tool has survived! And it's the tool that I go rooting in languages to find.
Lisp and Erlang have some really great tools (concepts) like this.
> 5 years ago I maintained decades old HLASM programs for IBM mainframes during a consulting gig and haven't touched anything like it since.
How funny!
I've had almost the same exposure to HLASM (although it was more than a decade ago)- consulting gig, never again. Any language designer who thinks comments can begin only on the first column needs to be taken out and shot.
However I think having to refresh myself on exactly how BALR works, or what types dyadic ! takes isn't going to waste much time. Are these real concerns you have about forgetting the tools you learn?