Xs: a concatenative array language inspired by kdb+ and FORTH
cryptm.org
cryptm.org
Python has Numpy to satisfy most array programming needs, for example.
But for regexes, it has been a success: they are rarely used, but when they are, you are glad you have them.
In fact you probably need to do both: re in Python is a library. A library that implements the regex DSL.
Maybe there is a way to create an API around numpy that translates a J/K/APL like DSL into numpy operations.
Just like regexes, this is not something you want to use often.
But I assume that, just like I don't want to describe a whole parser when I just need to match/split/extract text, people doing array processing probably don't want to describe every single steps for very common operations in some cases.
TL;DR: if the language is permissive enough, a library may well provide a DSL for whatever it's doing, it's not an "either lib or DSL" situation.
If you just use the flexibility of your language syntax, you just create an API, not a DSL.
The L in DSL stands for language, which numpy is, IMO, not.
> The L in DSL stands for language
I think you use a too narrow definition of a language, then. Any (sub)set of semantics can be called a language, with or without syntax. DSLs encode a set of semantic rules which are best suited for expressing solutions to problems in a given domain. Once you have semantics worked out, you have to think about the environment where the language will be used. Sometimes it's useful to have the DSL code separate, in which case you end up with an external DSL, like HTML or YAML. On the other hand, sometimes you need tighter integration with some environment, in which case you end up with an internal DSL, like JSX, Datalog, Kanren, Rake, Gradle, Gulp, various URL dispatchers, BDD testing frameworks, and yes, Numpy.
The syntax of a DSL ("a different parser" vs. not) is secondary at best, and the implementation strategy (macros vs. runtime code generation vs. reflection and syntax overloading) is simply irrelevant to something being a DSL or not.
Take a look at PyParsing or LPEG (for Lua) or scala.util.parsing or Parsec (for Haskell). These are all embedded DSLs meant for creating parsers. You work with them in exactly the same way you'd use YACC: you describe the grammar and get a parser for that grammar. That grammar description is done with a language, in all cases. That language - implemented either externally, or internally with host language features - is a DSL.
(Incidentally, I tried to C&P the relevant section from the documentation, and I can't highlight in the text at all. How does that work, and why?)
Well, Xs looks very early in the development, so I think the large list of dependencies is due to an initial effort for getting something up and running quickly. It'll probably get better over time. I think production build of Haxe (also written in OCaml) was about 2Mb, so there's definitely room for improvement :)
Comparing NumPy to APL it looks that way.
https://analyzethedatanotthedrivel.org/2018/03/31/numpy-anot...
Good (professional) APL though, will intersperse those primitives with meaningful variable names.
Whether one thinks it's worth the effort to know the symbols vs know the keywords is matter of opinion. But if one dares calling oneself let's say a python programmer, I'd argue that anybody would expect that you'd know the keywords anyways.
APL is a terrific language that is terse. It might not be the right tool for a job where you are constantly recruiting interns to hack on a massive code base, but it’s a fine language for its designed purposes.
Which tells me that terseness in-and-of-itself is not a problem. It presents a tradeoff that may not be right for everyone.
I'd recommend reading Iverson's "Notation as a Tool of Thought" for a new perspective.
Plenty of people, from Richard Stallman to Alan Perlis, have found great value in APL. Even if just looking at terseness, Chuck Moore, the creator of FORTH, is considered to be one of the best, if not the best, programmers of all time. He credits it all to terseness.
> what is this obsession with terse languages
It's not an obsession at all. It's a recognition of the fact that there are certain areas where the terseness is helpful, sometimes exceptionally so. It doesn't fit everywhere, and indeed there are domains where it would be downright detrimental. Still, people who prefer compact languages know this and are sure to carefully evaluate the circumstances before choosing APL or Forth. There are "rabid fans" - who would like to rewrite the whole world itself in their beloved language - in every language community, but in my experience, they're scarce among APL, J, or Forth users.
> that look like a composition of random characters,
Most of the tersest programming languages are meant for interactive, REPL-driven development. In PLs like APL, Forth, J, K, Cat, and now Xs, you are supposed to build your programs as a series of short expressions that you create and evaluate interactively in the interpreter. In such a setting, where you're likely to rewrite and evaluate every expression often, it's faster and more convenient to work with as concise syntax as possible. It's simply a different development mode, and it has its strengths, and - like every other programming model - its weaknesses.
> didn't we learn from Perl
First, Perl is nowhere near the terseness of APL or J, so I'm not sure what it is you think we should have learned from it. Further, Perl sigils are actually an elegant solution to the problem of type conversions in a dynamically typed language. Take a look at JavaScript and PHP, with all their implicit type-related shenanigans, then come back to Perl - chances are you'll appreciate the sigils quite a lot.
The most important thing with APL descendants is that they all have a minimal amount of core operations, which compose incredibly well. Xs is at a very early stage of development, and it will undoubtedly grow, but for now, it has but 5 functions bound to single-character symbols. You can check out the J vocabulary to see a mature, well-developed array language: https://code.jsoftware.com/wiki/NuVoc
It might look overwhelming at first, but it's essential to realize that what you see on that page is the entirety of J - there's nothing more to the whole language. It's not English-based, but math notation also isn't, and it's similarly concise. Plus, for a significant portion of the planet's inhabitants, English-based languages are just as foreign as J is to you.
To sum it all up: the conciseness of the APL-related languages, which comes from both heavy use of symbols for function names and the tiny amount of core concepts which compose effortlessly, opens the door to a style of programming which fits certain domains and circumstances very well. It may be hard to grasp without first putting some effort and playing with them for a bit... Still, the array and concatenative languages are powerful, and in the right circumstances, can provide an indispensable boost to programmers' productivity.