Samak - 사막

“No doubt you are wondering what you will find, out there.’ The Commandant said it for me. ‘Well, it would be useless for me to try and tell you. The desert tells a different story every time one ventures on it…”

― Robert Edison Fulton Jr., One Man Caravan

How to run

$ npm install # or yarn, you know, whatever

$ lein build-all

# samak-cli for console programs
$ ./samak-cli examples/basic.sk

# samak-ui for electron based ui programs

$ ./samak-ui examples/chuck_norris.sk

In case you don’t have electron installed globally, run npm run start.

Roadmaps

Samak

• Get repl somewhat stable release
• Rework functions to take a vector or map of arguments, no nested combinators except for datastructures (CANCELED)
• Separate definition of graphs from running them
  • Pipe configs instead of parameters, to allow different settings for testing etc.
• Server support, remote runtime
• Deployments to other runtimes
• Type checker (Either piggybacking on core.typed or hand-rolled with core.logic, haven’t decided) -> It’s actually either spectrum or hand-rolled now.
• Typed pipes (related)
• More backends, python, maybe Go, everything that’s easy to generate and has channels (-> Rust experiment underway)
• Auto conversion between languages, e.g. input pipe from python, output to browser, should be easy to automatically link
• Allow fat pipes (title is work in progress ;) ), like e.g. a pipe that not only provides a client to a db but also runs a docker image for it
• Assisted pipeline synthesis from tests a la barliman
• Disallow lambda, only backus style function composition ✔
• Better state cleanup for reloading ✔
• Persistence (Should be very easy with datascript) ✔
• Actually store state in db ✔
• Allow sending of messages to channels for testing/debugging ✔
• Improved single arg function support, e.g. #{:foo id} -> (fn [x] {:foo x}) ✔
• async requests, easy to model with core.async’s “pipeline-async” ✔ needs zero type annotations with this change ✔
• Get rid of multiple react versions -.- ✔

Oasis

• Could show latest channel state with comment boxes.
• Improve layout
• Program structure graph (Pipe layout with e.g. klayjs). ✔

Rationale

Samak is a collection of ideas around changing the way we program. For better or worse, you decide. The core ideas of Samak are:

Are files and libraries really the best basic units of code?

• In Samak, libraries are abstract collections of functions. Thats where Samak (Korean for desert) gets its name, because it fluidly recombines small grains in infinite variations.
• When you work on something, you want to see what it affects, and what affects it, not what happens to be above and below in the same file
• If someone writes a nice helper, or a useful interface and some functions that work on that interface, why should you have to download and worry about all the rest of his library?
• Text has very, very limited use for visualizing what’s going on in your program.

Stream or event based systems allow for great flexibility

• Samak is not a classical stream based language, actually it isn’t a traditional language at all, but since all programs essentially transform input into output, Samak strongly emphasizes sources, sinks and stores as well as what happens between them.
• Events are great for instrumentation, like logging everything, or even rewinding and replaying a program.

Is traditional scoping of variables still necessary?

• If a considerable effort in design is spent on transporting data from a to b, something is going wrong. Maybe this is just another instance of place oriented programming we need to reconsider.

The mind is not a turing machine.

• The less we have to replay changing states mentally, the better.
• If something can be represented as a stream transformation, it should be. That doesn’t mean that branching is unnecessary, but that map/reduce/filter can structure programs on a high level.
• Additionally, streams scale well

What if we had only a few simple but powerful interfaces for IO?

• Can we define an abstraction to access databases in a unified manner?
• More generally: Is there a good abstraction for stateful external dependencies?

Tools to understand code are abysmal

• Complicated syntax is part of the problem: If I can’t write or easily access a parser, how can I write an analyzer?
• What are better ways to see a complex programs structure? Call graphs, automatic examples, searchable tests…?