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

41–50 of 58 posts

Re: Why your REPL experience sucks

#41

Post by PaulHoule »

nerdponx wrote: post #38
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.

That's one answer to the problem, but not the only answer or necessarily a complete answer... That is, people forget that the really special thing about spreadsheets is not the grid organization but the hidden graph organization of computations.

I would point to this as a product that was ahead of its time and still seems without peer

https://en.wikipedia.org/wiki/TK_Solver

Another challenge Jupyter has is the conflict between "a way to present a report" and "a way to write a script that generates a report" and everything in between.

Re: Why your REPL experience sucks

#42

Post by mm007emko »

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.

I upvoted your comment but I only partially agree. PHP is great in some ways and totally atrocious in other ways. It put bread on my table in the 2000s but I am not looking back. The language is horribly designed. Writing AJAX calls before Google Chrome was even released (let alone its V8 Engine which made JavaScript fast) was no fun either. Any non-trivial web app we developed was slow (everything had to start from scratch with each request) and flooded with a couple of layers of caching which often didn't get invalidated properly.

Now I am a purely backend&desktop developer, I leave web frontends to people who are willing to live in the JavaScript world where if no big framework is released every 5 minutes you have an impression that the Earth stopped spinning. I learnt the basics of React.js the other year and it's a far cry from what we had 20 years ago. ClojureScript+React even with its difficulties must be an ivory tower of modern web frontend development. I want to remember the good parts of PHP, frameworks Nette and Symfony with nostalgia. But I never want to re-live it again.

I mean Request/Response websites with a bit of AJAX still work today, I even develop one as a side project since I am part-time involved in academia (neural networks & nature-inspired algorithms simulator, in Common Lisp with cl-who, Parenscript and a couple of custom components based on HTML5 Canvas). But modern development? When you need to keep up with the latest trends? No way it can work.

Re: Why your REPL experience sucks

#44

Post by suskeyhose »

jwr wrote: post #7

A related question is why would you want to reload the entire file/namespace every time you make a change? Coming from a Common Lisp background, I am used to evaluating single forms/functions. I would sometimes re-evaluate the entire namespace, but that would be relatively rare. I switched to Clojure many years ago and followed the same workflow. Then ClojureScript and tools like figwheel came along and I was somewha…

So I am no stranger to CL, but the problem solved in the article isn't actually one that's solved by evaluating less than the whole file at once, and in fact I didn't tell anyone to re-evaluate the whole file at all in this article.

The critical idea here is it applies to long-running functions, like a loop, a server, or other things. These, when handed function objects, will not reflect new behavior if you re-evaluate a single function.

The article solves for this by explaining to intermediate programmers that there is a difference between using function objects and using vars, something that Common Lisp programmers learn too by using #' to retrieve function objects and passing symbols and using symbol-function to look up the associated function as needed.

Re: Why your REPL experience sucks

#45

Post by agumonkey »

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 exchanged restart time for debugging time

Re: Why your REPL experience sucks

#46

Post by runevault »

cutler wrote: post #35
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.

I'd have to check and see, but I know at least some of the features overlap (for example f# lets you send a single function/etc to the repl and update the existing definition. However to the specific point he brought up, I'm not sure if anything like the var capture issue comes into play.

Re: Why your REPL experience sucks

#47

Post by eigenspace »

PaulHoule wrote: post #41
nerdponx wrote: post #38

Earlier quoted context omitted.

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

That's one answer to the problem, but not the only answer or necessarily a complete answer... That is, people forget that the really special thing about spreadsheets is not the grid organization but the hidden graph organization of computations. I would point to this as a product that was ahead of its time and still seems without peer https://en.wikipedia.org/wiki/TK_Solver Another challenge Jupyter has is the confli…

> That's one answer to the problem, but not the only answer or necessarily a complete answer... That is, people forget that the really special thing about spreadsheets is not the grid organization but the hidden graph organization of computations.

Uh did you mean this the other way around or something? Reactive notebooks like Pluto only address the hidden graph organization of computations, they don't address grid organization at all.

Re: Why your REPL experience sucks

#48

Post by dmux »

suskeyhose wrote: post #44
jwr wrote: post #7

A related question is why would you want to reload the entire file/namespace every time you make a change? Coming from a Common Lisp background, I am used to evaluating single forms/functions. I would sometimes re-evaluate the entire namespace, but that would be relatively rare. I switched to Clojure many years ago and followed the same workflow. Then ClojureScript and tools like figwheel came along and I was somewha…

So I am no stranger to CL, but the problem solved in the article isn't actually one that's solved by evaluating less than the whole file at once, and in fact I didn't tell anyone to re-evaluate the whole file at all in this article. The critical idea here is it applies to long-running functions, like a loop, a server, or other things. These, when handed function objects, will not reflect new behavior if you re-evalua…

>The critical idea here is it applies to long-running functions, like a loop, a server, or other things. These, when handed function objects, will not reflect new behavior if you re-evaluate a single function.

Do you mind going into more details about what you mean here? In my experience, recursive loops will pick up a new function definition but non-recursive loops will only pick up the definition of a function upon entry.

Re: Why your REPL experience sucks

#50

Post by AceJohnny2 »

Non-Clojure user here (but with just enough Lisp experience to make a fool of themselves)...

> When Clojure evaluates the symbol router [(an argument)] here, it goes through almost the exact same process as it did for the symbol +, but without checking if it’s a special form. It looks for the var in the current namespace that maps to the symbol router, dereferences it, _and saves the function object it retrieves as the first argument before evaluating the second argument_, and then calling the function that run-jetty evaluated to.

Why does it save the resolved function object, which is an argument at that scope? That sounds counter-productive to the reloadable functionality.

Is it a performance optimization?

If anything, it demonstrates that reloadable code is inherently at odds with performance.

Post reply on HN