APL, (which is the array language I had some exposure to), had three
interesting characteristics:
1. It implements an algebra: Operators take arrays as input and yield
arrays as output.
2. The special characters bound to those array operators.
3. It is functional.
#2 definitely gave APL programs a distinct and elegant personality,
but probably didn't help with widespread adoption.
But #1 and #3 are powerful ideas, and have showed up in other
forms. SETL was a set-oriented language from the late 70s/early 80s. I
took compiler courses from the guy behind it, R. B. K. Dewar (of
Spitbol fame). Fantastic teacher. SETL programs were concise and
powerful like APL programs, exactly because of #1 and #3.
Later in my grad school career, I got into relational algebra, which
also has these characteristics. My advisor was T. H. Merrett who
engaged on a many-years, quixotic quest to explore relational algebra
as the basis of a general-purpose programming language. I didn't buy
into all of that, but as a database guy, I find relational algebra to
be powerful and useful on a day-to-day basis.
Finally, I really like functional stream approaches as a great way to
bridge set-at-a-time programming (for lack of a better term) with
ordinary, low-level programming. Java 8 streams and lambdas is a great
(if flawed) example of this approach. Even Map/Reduce is, under the
vast amounts of complexity.
I like this approach so much that I built a command-line tool, osh
(http://github.com/geophile/osh) based on it. The idea there is the
Unix idea of composing simple commands using pipes, except in osh, the
pipes carry streams of Python objects. And the commands that operate
on the objects in these streams are Python. E.g., to print the pids
and commands of processes whose commandline contains "emacs":
I read your post, thought 'hmm sort of powershelly with a bit of awk', clicked on your Github project page and saw Powershell was listed as the first 'Software with Similar Goals to Osh'.
I've been searching for the 'panacea' of shells (and/or auxilary shell tools/hacks that dup() fd's 0,1,2 to enhance existing shells) that hits that same 'sweet spot' you describe. As such, over the last ~15 years I've been through a litany of setups, ranging from:
- the standard "bash/zsh/fish" approach (where you extend the shell) to
- the "scsh/ipython/eshell" approach (where you bring an inferior shell's functionality into a language) to,
- the screen/tmux approach (where you take a shell and then layer functionality over it). I.e., for directory navigation,
I'd written my own f-recency+bookmark system that would hook 'cd <tab>' and generate a pane sort of like Midnight Commander to nav around
I'm not sure where I'm going with this other than, I feel your pain and I'd imagine tons of other people do/did as well. Powershell is painfully slow and RAM heavy but the ability to add custom properties(!), providers, access the registry, and manipulate all of these objects as you'd like. Your project definitely looks like an interesting take on things as well. At least we're making some progress, I suppose ;)
===
(!) This is incredibly powerful since you can take a path, like C:\users\foo\downloads\video\, take file item, and then have Powershell invoke an executable to extend functionality out. If Windows doesn't have "Length" or "Encoder" as a property on the file out-of-the-box, you can just use an auxilary tool (say, ffprobe), "mapcar" the exec to the list-of-files, grep out the Length: field, and bam, that file now has Length. ``ls|where Length -gt 15'' ends up being pretty magical.
osh gets extensibility by reading a file on startup (~/.oshrc by default). That file is Python, and contains both configuration (e.g. database login info, ssh login info), and functions that can be used in osh commands.
"Dewar, a professor emeritus of computer science at New York University, believes that U.S. colleges are turning out programmers who are - there's no nice way to say this - essentially incompetent."
"A lot of it is, `Let's make this all more fun.' You know, `Math is not fun, let's reduce math requirements. Algorithms are not fun, let's get rid of them. Ewww - graphic libraries, they're fun. Let's have people mess with libraries. And [forget] all this business about `command line' - we'll have people use nice visual interfaces where they can point and click and do fancy graphic stuff and have fun."
I am both an APL user (k) and a spitbol user but still not a Python user. Regarding the later, I think I suffer from the Dewar perspective[1]: it's too easy and too focused on libraries. Perhaps this is misplaced, but for myself I feel k and spitbol are more "educational" than Python.
1. In truth, I have no idea if Dewar saw Python as he did Java and PHP.
That's questionable. APL doesn't treat functions as first-class values. Its higher-order functions are limited to "operators", i.e. second-order and no higher.
I don't recall SETL, and relational algebra doesn't have functions.
I meant functional in the sense that the 1st-class objects (arrays, sets, relations) are not mutable. (My memory of APL and SETL is fuzzy, so maybe there is some way to alter state, but that certainly isn't the emphasis.)
1. It implements an algebra: Operators take arrays as input and yield arrays as output.
2. The special characters bound to those array operators.
3. It is functional.
#2 definitely gave APL programs a distinct and elegant personality, but probably didn't help with widespread adoption.
But #1 and #3 are powerful ideas, and have showed up in other forms. SETL was a set-oriented language from the late 70s/early 80s. I took compiler courses from the guy behind it, R. B. K. Dewar (of Spitbol fame). Fantastic teacher. SETL programs were concise and powerful like APL programs, exactly because of #1 and #3.
Later in my grad school career, I got into relational algebra, which also has these characteristics. My advisor was T. H. Merrett who engaged on a many-years, quixotic quest to explore relational algebra as the basis of a general-purpose programming language. I didn't buy into all of that, but as a database guy, I find relational algebra to be powerful and useful on a day-to-day basis.
Finally, I really like functional stream approaches as a great way to bridge set-at-a-time programming (for lack of a better term) with ordinary, low-level programming. Java 8 streams and lambdas is a great (if flawed) example of this approach. Even Map/Reduce is, under the vast amounts of complexity.
I like this approach so much that I built a command-line tool, osh (http://github.com/geophile/osh) based on it. The idea there is the Unix idea of composing simple commands using pipes, except in osh, the pipes carry streams of Python objects. And the commands that operate on the objects in these streams are Python. E.g., to print the pids and commands of processes whose commandline contains "emacs":