Well - I will say I like the general concept. I just wish it wasn't implemented in Scheme (only because I am not familiar with the language; looking at the source, though - I'm not sure I want to go there - it looks like a mashup of Pascal, Lisp, and RPN).
It seems like today - and maybe I am wrong - but that data science and deep learning in general has pretty much "blessed" Python and C++ as the languages for such tasks. Had this been implemented in either, it might receive a wider audience.
But maybe the concept itself is more important than the implementation? I can see that as possibly being the case...
Great job in creating it; the end-tool by itself looks fun and promising!
Author here; thanks for the feedback. The path to Scheme was a bit haphazard - I got into Clojure a few years ago after exposure to some nice Clojure-based tools at work, and then worked on implementing several classical machine learning techniques in Clojure for fun.
When I came up with the idea of chaining and piping neural network layers on the command line, I also came across CHICKEN Scheme which promised to be portable and well-suited for translating the Clojure-based implementation I had previously done. As you can probably imagine, the porting process was a lot more involved than I expected, but nevertheless I had a BLASt (pun intended) hacking on it.
Clojure is ideal for Unix-style pipeline programming. Few people will use the command line for neural network inference, I think it would be better to use clojure to implement.
[The Pure Function Pipeline Data Flow](https://github.com/linpengcheng/PurefunctionPipelineDataflow)
> looking at the source, though - I'm not sure I want to go there - [Scheme] looks like a mashup of Pascal, Lisp, and RPN
Cool, you got to discover Scheme today! It's one of the classical languages that defines the programming world we live in.
> data science and deep learning in general has pretty much "blessed" Python and C++ as the languages for such tasks.
It's reasonable to expect that the languages a community uses for its programs bear some proportionality to the broader programming community unless you have a very severe historical isolation of that community (i.e., MUMPS in medical informatics). Python and C++ are extremely common languages. You should expect the usual long tail of other languages as well. And under the hood, it's really all about CUDA anyway.
There's nothing wrong with implementing the tool in Scheme, but the problem is that typical ML frameworks implemented in Python use Python as their "glue" language (which already can be somewhat problematic performance wise). This approach is using a text serialization and sh as the glue language.
Sure, it's conceptually neat, but for exploration, it's not even competitive with regular Python, let alone e.g. Python in a Jupyter notebook.
I could see an approach using scheme itself as the exploratory glue language being quite competitive. Dropping down into shell pipelines is decidedly worse.
I think the pipelines are absurd, too (actually, I think the entire Unix shell is a Rube Goldberg contraption that we would be better off without), but that's not the focus of the comment I was replying to.
>I just wish it wasn't implemented in Scheme (only because I am not familiar with the language
It is a functional-first, small and clean variety of lisp. A much more beefed-up cousin is Racket, but some implementations of scheme (in particular Guile and CHICKEN) have excellent ecosystems.
Scheme is a language that deserves to be used more. It simplicity is deceptive. It is extremely powerful because although the basic components are simple, there is virtually no limitation on how they may be composed.
There is literally only a single drawback to using Scheme (it might appear that being dynamically typed is a weakness, but both CHICKEN and Racket offer typed variants), is that it is sadly extremely unportable. The specification for Scheme is very small, and a large number of implementations exist which go beyond this standard - so basically none are compatible with eachother.
Quite to the contrary, the limitations of functional languages are intended to make code easier to reason about for humans. Making small programs is one thing, but the combinatorial explosion in potential states as you approach large programs and systems of programs make it difficult to near impossible for humans to reason about software. You can only keep so much in your head at any given time.
Even so, you can write code imperatively in scheme, it's just a bit less natural. The keyword 'begin' has the same semantics as common lisp's 'progn', which allows imperative code to be written.
I was careful to say "functional-first". Racket has a fully-fledged object system, too.
I find I am a much "better" programmer in Scheme than in any other language, in the sense that idioms that I would normally struggle to express (at all, let alone cleanly) simply flow out as if I had invented them myself. Programming in Scheme is hugely fun.
If it were true that humans thought "imperatively", then we'd all still be using languages with GOTO.
Your profile says you’re interested in the history of computing (even going so far as to learn PHP and BASIC). I’d say this is a perfect opportunity to learn Scheme, which is not only a great language but one of the most important languages in the history of the field.
I wouldn't say that Python and C++ are the end all languages for ML. They do have a critical mass but I still think projects like OPs can still help us figure out what's a good interface for ML and learnings from smaller projects can inform the design and interface of larger projects (e.g: Keras API helped inform the new TF API).
Also I'm suspicious that Tensorflow will be the Deep Learning library we'll use 5-10 years down the line so it's always nice to see smaller projects that try to do something different.
You're not the only one who has said something to this effect, so maybe I do need to look into it more. Lisp is something I've tried to get into, but never went much beyond simple "hello world" implementations. So maybe I need to give it another shot.
It seems like today - and maybe I am wrong - but that data science and deep learning in general has pretty much "blessed" Python and C++ as the languages for such tasks. Had this been implemented in either, it might receive a wider audience.
But maybe the concept itself is more important than the implementation? I can see that as possibly being the case...
Great job in creating it; the end-tool by itself looks fun and promising!