salotz (Samuel)

Introductions
1

I am a PhD student in Biochemistry at Michigan State for the time being, but basically my role is data scientist and software engineer. I am primarily in python because it is easy to get started and the data science libraries and support and adoption in academia/research is huge.

Interested in rebol for a variety of reasons, but primarily interested in solving problems related to what I like to call "exploratory" programming. Structured software engineering is a well covered topic but doesn't really help with what a data scientist does on a daily basis which is trying new things and iteratively building those into a real processing pipeline which may not have a very long lifetime but can still be overburdened with complexity. The intuition for what I mean is anything that you would either write a slew of unportable bash scripts with really long and overly specific names or maybe Jupyter notebooks or Mathematica. In my experience "scripting" (i.e. the UNIX tradition of bash, sed, awk, perl and other treacherous demons) OS facilities like filesystems and process management is the weakest link in the data scientist's toolbox, which has led to solutions like Jupyter and DataBricks. Which are unusable in a number of other ways. The block orientation of rebol IMO is the proper foundation for making this kind of work tractable and maybe even comfortable. My long term goal would be to use rebol as a document container format (replaces e.g. a "notebook" or filesystem "schema") that also allows for creation and orchestration of pipelines of blocks. Sort of like "literate programming" but the literate part is also programmable.

I am going to do a write up with real examples of where I think rebol could help; drawing from my personal emacs org-mode notebooks and project folders I use for doing my PhD work. Let me know if you are interested and it might come sooner.

Currently other interests include sane system configuration management (Nix, Guix, Genode), object capabilities systems for collaborative programming (Genode and Monte), language-oriented programming (rebol and racket), programming/operating assistants as I like to call them (e.g. emacs, DrRacket, Dark language, McCLIM), solid-state computers (e.g. Urbit and Smalltalk) and probabilistic programming. I'm also pretty interested in using Nim, if I can get over not having the python libraries, ReasonML, and Clojure for doing "real work".

4 Likes
2

Welcome Samuel!

Definitely interested. Having a handful of participants at this point offers us at least one perk: those who are here now are the ones who'll guide the first application domains. There is oil for the squeaky wheels that actually show up to squeak. :ferris_wheel: :mouse:

I'm serious about keeping the web in focus--specifically the thread-based WebAssembly build. That said: I'm personally willing to reorder what I work on a bit to serve those who commit to using the system day to day, even if it's not directly toward that goal. See for instance: ODBC work last week) (And as I discussed with @jhgorse last night, if he wants to send me some code outlining his hardware interface ideas then I'll work on that, too. We want to stay grounded in having low enough dependencies for doing good embedded systems--it may not be immediately obvious how that applies to WASM, but the dependency control is what permits the fluidity to jump into emerging platforms.)

In my experience "scripting" (i.e. the UNIX tradition of bash, sed, awk, perl and other treacherous demons) OS facilities like filesystems and process management is the weakest link in the data scientist's toolbox

I had predicted my likely move from C++ template metaprogramming to even more formality and rigor. Hence I thought I was going to be following my other friends like Dr. Bartosz into Haskell and other pure FP languages.

Maybe I'm too old and lazy to take up math as a cause. But even so, the day to day things we need to get done in programming don't really easily fit into that set of ideas. I used to listen to Haskell podcasts and even the devout--when they realized it wasn't a fit, just gave up and used bash as a matter of practicality.

I've gotten interested in that non-FP utility space; a better Swiss-Army-Knife caught my attention. And I also am very interested in code golf, hence Rebmu

So I do want to see what we can do to replace bash (you end CASE statements with ESAC?!?) with something where you really create languages as easily as you make functions. Another thing I said last night about Rebol is that "if you're not bending Rebol to create new language constructs and 'keywords', you're probably using the wrong language". If we can get to where we are the "other tool" that pure FP users reach for, that would be enough to float my boat.

In my experience "scripting" (i.e. the UNIX tradition of bash, sed, awk, perl and other treacherous demons) OS facilities like filesystems and process management is the weakest link in the data scientist's toolbox

Having someone who knows Clojure well around would be great--I am only very superficially familiar with it.

Again, welcome, please share your thoughts (or even better, code).

1 Like
3

I'm serious about keeping the web in focus--specifically the thread-based WebAssembly build. That said: I'm personally willing to reorder what I work on a bit to serve those who commit to using the system day to day, even if it's not directly toward that goal.

Please stay focused on what is important to you! I'm still in the explore around phase and would rather either contribute or continue lurking :slight_smile: . Also finishing PhD and forcibly have to stop myself from hobby coding.

Maybe I'm too old and lazy to take up math as a cause. But even so, the day to day things we need to get done in programming don't really easily fit into that set of ideas.

I like that there are people that are interested in the more rigorous stuff and I really enjoy Bartosz lectures and I see how fancy type systems are really important for large software projects. I think we are actually pretty strong in those areas in terms of maturity of the field and as such there is diminishing returns on how much impact you can contribute. Especially when you are not devout and not raised from a young age to worship the lambda god. Its in the fuzzy areas where those clean ideas can't help us as much is where I think the biggest arbitrage opportunities are.

Not sure if I posted this here but darklang seems to going in a useful direction which is to replace all the fancy metaprogramming stuff (like monads) with something like editor tooling. My own take on this would be less editor tooling and more like versioned source transformation build system. I also predict that gradual typing will eventually become very mature making it a lot easier to go from duck to algebraic types (e.g. Hackett, ADTs in Racket, Clojure spec, and contracts in general). Programming languages should grow with the programmer and YOLO should be as popular an acronym as KISS.

4

Yes, I hate to say it but that is one of the reasons I feel a bit reticent to be involved... not sure how much an impact I can make on something that is so heavily studied by academics. Whereas with Rebol, it's this big open space where I keep finding uncharted territory. One feels one can invent.

I'm still trying to cover ground in theory, check out this sibling tail call recursion for instance :slight_smile: I've been bringing a lot of this kind of stuff to the table, and function composition is getting progressively stronger too...