Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why your REPL experience sucks

srasu.srht.site

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Why your REPL experience sucks

#31

Post by all2 »

PaulHoule wrote: post #2

Workspace-based programming environments have always struggled. When I use Jupyter I rerun the whole book pretty frequently. If the book takes 30 seconds to run it is a big annoyance but saves time relative to the randomly irreproducible problems I see other people have. If the book takes 3 hours to run it is a different story.

The idea of "book" and the linear visual in a "book" limit the interaction of the user.

What if, in addition to the "book", you had a visual representation of the environment? Further, what if you had a function application visualization?

Say you start with

    with open(your_csv_here) as my_csv:
        ... some actions
In the function application viz you'd see something like

    your_csv_here
      |
    open as
      |
    my_csv
In the environment visualization you'd see two variables

    your_csv_here
    my_csv
Ideally, you'd be able to grab either of those in the "book"'s linear representation of code blocks using auto-complete.

---

When I've played with data sets in Pandas DFs, for example, having some awareness of my environment and the available states of data -- and how that data has been mutated -- would be extremely helpful.

---

I've taken the view that a Jupyter notebook or similar environment represents a filter for one or more streams of data. Ideally, you need to be able to quickly visualize the execution environment and previous actions/filters applied to your data streams. I'll admit, this does nothing for working with logic (except that you'd be able to inspect inputs and outputs pretty quickly).

Re: Why your REPL experience sucks

#32

Post by runevault »

I used to be a big REPL head, especially in my time with Clojure. But in recent years since most of my programming was c# I got away from thinking in REPLs. However these days I'm doing personal work in F# so I have access to the REPL again, I just keep not thinking to take advantage of it. I guess this is my reminder to use ALL the tools a language/environment gives me.

Re: Why your REPL experience sucks

#33

Post by iLemming »

nikanj wrote: post #3

We keep on making fun of php, but it had this problem solved in the 90s. Hit F5 in the browser, get the latest version of your software. No waiting 30s for a rebuild, no stale versions in caches, no headaches.

> Hit F5 in the browser, get the latest version of your software.

What about the state though? If I'm building a sophisticated app, let's say an e-commerce thing, imagine having to develop a shopping cart experience, where a user has to make multiple choices before getting to the shopping cart view. Every time you hit F5, you'd have to click a bunch of buttons, fill out fields, etc. Or you're gonna have to write a script that takes you there and restores the state, which is still time-consuming and annoying to have to do. With Clojurescript, I can change things in the code, eval it and the change would be reflected in the app immediately, without having to reload the entire app.

> it had this problem solved in the 90s

We weren't building many complex web apps back in the 90s, so the problems associated with hot-reloading weren't so apparent back then.

Re: Why your REPL experience sucks

#34

Post by cess11 »

iLemming wrote: post #33
nikanj wrote: post #3

We keep on making fun of php, but it had this problem solved in the 90s. Hit F5 in the browser, get the latest version of your software. No waiting 30s for a rebuild, no stale versions in caches, no headaches.

> Hit F5 in the browser, get the latest version of your software. What about the state though? If I'm building a sophisticated app, let's say an e-commerce thing, imagine having to develop a shopping cart experience, where a user has to make multiple choices before getting to the shopping cart view. Every time you hit F5, you'd have to click a bunch of buttons, fill out fields, etc. Or you're gonna have to write a sc…

You could put some state in the session to keep it persistent across page reloads and get a result similar to continuations or however you're keeping that state on the JVM.

Re: Why your REPL experience sucks

#35

Post by cutler »

runevault wrote: post #32

I used to be a big REPL head, especially in my time with Clojure. But in recent years since most of my programming was c# I got away from thinking in REPLs. However these days I'm doing personal work in F# so I have access to the REPL again, I just keep not thinking to take advantage of it. I guess this is my reminder to use ALL the tools a language/environment gives me.

The kind of repl the author refers to is strictly Lisp-based. Your F# repl wouldn't be any different from a Python or Ruby repl and falls well short of the Lisp/Clojure repl experience which is based on the code-as-data feature of Lisps.

Re: Why your REPL experience sucks

#36

Post by cutler »

tonetheman wrote: post #12
nikanj wrote: post #3

We keep on making fun of php, but it had this problem solved in the 90s. Hit F5 in the browser, get the latest version of your software. No waiting 30s for a rebuild, no stale versions in caches, no headaches.

PHP was and still is great. Make a change and hit refresh. Simple and easy.

The Clojure repl allows you to eval changes within a live application. Try that in PHP and I don't think you'll get very far.

Re: Why your REPL experience sucks

#37

Post by cess11 »

cutler wrote: post #36
tonetheman wrote: post #12

Earlier quoted context omitted.

PHP was and still is great. Make a change and hit refresh. Simple and easy.

The Clojure repl allows you to eval changes within a live application. Try that in PHP and I don't think you'll get very far.

What do you mean by "live application"? Is a PHP application under nginx "live" or not?

If it is "live", changing a file will immediately be reflected in the application on the next "eval", i.e. require or execution by the interpreter.

Re: Why your REPL experience sucks

#38

Post by nerdponx »

PaulHoule wrote: post #2

Workspace-based programming environments have always struggled. When I use Jupyter I rerun the whole book pretty frequently. If the book takes 30 seconds to run it is a big annoyance but saves time relative to the randomly irreproducible problems I see other people have. If the book takes 3 hours to run it is a different story.

Fixing this situation is supposed to be the promise of "reactive" notebooks like Julia's Pluto.

Re: Why your REPL experience sucks

#39

Post by cpursley »

onetom wrote: post #30
cpursley wrote: post #29

I've only used a few REPLs so far but Ruby and Elixir are great (and I assume inspired by Lisp). I cut my teeth developing with REPLs and actually struggle a lot with trying to use language environments without them. Like, how can I just experiment and run a little one-of bit of code and data before starting the actual implementation? Or call and play around with the function I just wrote?

Have a look at Fred0verflow's videos, for example: * https://www.youtube.com/watch?v=St0_jsPnGAw - analyze some SO HTTP API responses * https://www.youtube.com/watch?v=TaazvSJvBaw - transducers from the ground up I think they are great, crystal-clear examples of REPL-based development.

Oh, I think you misunderstood. I'm literally in the Elixir repl all day every day and do know how I'd don't know how I'd manage without one.

Re: Why your REPL experience sucks

#40

Post by klibertp »

cess11 wrote: post #37
cutler wrote: post #36

Earlier quoted context omitted.

The Clojure repl allows you to eval changes within a live application. Try that in PHP and I don't think you'll get very far.

What do you mean by "live application"? Is a PHP application under nginx "live" or not? If it is "live", changing a file will immediately be reflected in the application on the next "eval", i.e. require or execution by the interpreter.

Nope. That's not what the GP means. I'm not sure how it works currently with PHP, but what was meant was a long-running process that can change its behavior/be updated by evaluating new code without ever being restarted. Think of it like this: you have a page that never stops rendering, ie. you send some HTML but instead of finishing processing, you go into an infinite loop. "Live" system, in that situation, would still be updatable - you could change the body of the loop and make it produce another bit of HTML, without reloading the page.

Again, I'm sure modern PHP was already optimized far from the initial "execute all the code on each request" model, but unless there's a long-running process that can be updated in memory without restart (and I don't mean doing `exec` on itself, that's cheating!) - it's not "live" by this definition.

It's not that clear-cut a distinction, either. For example Elixir and Phoenix are definitely live, in that there's a process that responds to requests on one hand, and can be updated without restarting it on the other - but page reload is still required in many cases, even if triggered via websocket.

This idea of liveness predates both PHP and the Web by 2 decades at least and comes from Lisp and Smalltalk. It's been incorporated by Erlang and later Elixir, and by Clojure. Other than that, some embedded scripting languages support this kind of development, for example Awesome WM is scripted in Lua, and you can evaluate arbitrary Lua code while it's running. Emacs is another system that is meant to be used this way.

Good to read: https://gbracha.blogspot.com/2020/01/the-build-is-always-bro...

Post reply on HN