Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

motivation for not reusing cider? #16

Open
kidd opened this issue Jan 7, 2019 · 1 comment
Open

motivation for not reusing cider? #16

kidd opened this issue Jan 7, 2019 · 1 comment

Comments

@kidd
Copy link

kidd commented Jan 7, 2019

Hi, First of all, thanks for this module, I recently discovered gerbil and I'm super excited with it getting more tools.

I have some experience with slime, sly, and geiser (also cider but to a lesser degree), and I'm curious if you thought of starting off from some of those projects.

As you know, they all have tons of features and hours put into them. What's the motivation for starting from scratch? Fun? Learning? Are they hard to port?

@edw
Copy link
Member

edw commented Jan 13, 2019

When you look at development environments in use with programming language implementations that are not the focus of the design of those environments, there's generally an unpleasant mismatch. Back when I was using SLIME with Scheme48 -- this was a long time ago -- I found the complexity of SLIME distracting and confusing, especially because much of the complexity was due to a design that supported features that were either irrelevant or unsupported by the Scheme48 backend.

Something similar is true of Geiser in my experience, except that there's no particular Scheme implementation that has better support than every other Scheme implementation. For example, there are features supported only by Racket (image return values, IIRC) and features supported only be Guile.

Jupyter notebook is another thing I'm interested in, and it is an uphill climb unless you're programming in Python, though the pain is felt more by kernel writers than front end users. Or maybe it is felt by users, but I haven't been able to bring myself to write anything but "Hello world"-esque Python code in a notebook. In short, the kernel development process still shows its profound Pythonic roots.

There are enough differences in semantics between Gerbil and Clojure -- in the languages, runtimes, and extended ecosystems -- that porting CIDER to Gerbil would end up with a mess. I think programmers often think, "It wouldn't take a lot of effort to get this project ninety percent of the way done," but the difference between something that sort of, perhaps pretty much, works and something you want to use is in what I like to call the second ninety percent of a project. I think Fred Brooks talked about this in The Mythical Man-Month.

I wanted to write, "I almost wish no one knew about Treadmill, so then I could be free to experiment with it, because experimentation is what I'm most interested in at the moment." All that is true except the "almost." For example, I'm interested in the notebook model of programming, but I also find interesting similarities between it and the current fashion of containerizing things. Because what is a notebook but a container for thoughts?

Scheme Docker
Procedure Entry point
Procedure args Run args
Parameters and env vars Env vars
Ports File descriptors
Filesystem, network, etc. Filesystem, network, etc.

It's not a profound insight, but I am interested in the idea of programming by notebook, using the idea of binding notebook pages together to get code sharing. A literate programming-meets-mathematica-meets-Docker-meets-AWS-Lambda kind of thing. Coming up with something that feels good is going to take a lot of experimentation, which means Treadmill is more a series of design studies in my mind than a product that I have any interest in supporting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants