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

REPL vs CLI: IDE wars

vlaaad.github.io

Post reply on HN
Print view View original

21–30 of 110 posts

Re: REPL vs CLI: IDE wars

#21

Post by winrid »

smw wrote: post #4

I think you might be missing the main "aha!" of clojure REPLs vs REPLs in non-homoiconic languages: you can very easily execute small parts of the program you're editing without re-typing the code. In emacs, for instance, you often use `eval-last-sexp`, by default bound to C-x C-e. This lets you move your cursor to a particular point in the file, often deep in a function, and get the results of just the form(s) you'r…

You can do this in IDEA's IDEs too, just place a breakpoint and then you can "evaluate expression" in that context to call functions, read values, etc.

Re: REPL vs CLI: IDE wars

#22

Post by toomanybeersies »

tomconnors wrote: post #2

This post could be summarized as "write as much of your project's tooling as you can in the project's main programming language and the project's main programming language should be Clojure" and I agree wholeheartedly.

The general gist of the article also applies to Ruby too.

Re: REPL vs CLI: IDE wars

#23

Post by leephillips »

dragonwriter wrote: post #12
smw wrote: post #4

I think you might be missing the main "aha!" of clojure REPLs vs REPLs in non-homoiconic languages: you can very easily execute small parts of the program you're editing without re-typing the code. In emacs, for instance, you often use `eval-last-sexp`, by default bound to C-x C-e. This lets you move your cursor to a particular point in the file, often deep in a function, and get the results of just the form(s) you'r…

Homoiconicity isn't required for that, all you need is to be able to map between source and AST enough to identify expression boundaries. Plenty of development environments for non-homoiconic languages provide the ability to evaluate a selected expression (not just the last one) in a linked REPL on demand. I love the Lisp family, but I don't know why its advocates often sound like they haven't seen a dev environment…

Indeed; I do this every day with Vim and its term command, with Julia, Python, bash, Elixir—it works with any language with a REPL of any kind.

Re: REPL vs CLI: IDE wars

#24

Post by dgb23 »

dragonwriter wrote: post #12
smw wrote: post #4

I think you might be missing the main "aha!" of clojure REPLs vs REPLs in non-homoiconic languages: you can very easily execute small parts of the program you're editing without re-typing the code. In emacs, for instance, you often use `eval-last-sexp`, by default bound to C-x C-e. This lets you move your cursor to a particular point in the file, often deep in a function, and get the results of just the form(s) you'r…

Homoiconicity isn't required for that, all you need is to be able to map between source and AST enough to identify expression boundaries. Plenty of development environments for non-homoiconic languages provide the ability to evaluate a selected expression (not just the last one) in a linked REPL on demand. I love the Lisp family, but I don't know why its advocates often sound like they haven't seen a dev environment…

There is a significant, qualitative difference between using a language that designed for REPL use and one that isn’t.

Those boundaries you talk of are the crux of the issue. A highly dynamic, completely expression based language is going to enable a much different experience. Homoiconicity also plays an important role here, because you can ispect and parse code within the language, with the same functions and algorithms as everything else.

Re: REPL vs CLI: IDE wars

#25

Post by elamje »

dragonwriter wrote: post #12
smw wrote: post #4

I think you might be missing the main "aha!" of clojure REPLs vs REPLs in non-homoiconic languages: you can very easily execute small parts of the program you're editing without re-typing the code. In emacs, for instance, you often use `eval-last-sexp`, by default bound to C-x C-e. This lets you move your cursor to a particular point in the file, often deep in a function, and get the results of just the form(s) you'r…

Homoiconicity isn't required for that, all you need is to be able to map between source and AST enough to identify expression boundaries. Plenty of development environments for non-homoiconic languages provide the ability to evaluate a selected expression (not just the last one) in a linked REPL on demand. I love the Lisp family, but I don't know why its advocates often sound like they haven't seen a dev environment…

Maybe it's not required. However, I can confidently say Clojure in emacs feels like an entirely different development experience than my daily Python work in PyCharm/VSCode and C# in VS. I recommend trying it out if you haven't already.

Re: REPL vs CLI: IDE wars

#26

Post by marcosdumay »

geokon wrote: post #14

Thanks for introducing me to `add-lib` This is going to be a huge time saver :) More info here: https://insideclojure.org/2018/05/04/add-lib/ Hopefully there will be some way to just "reload" your whole `deps.edn` though "If you get an error, the execution stops by default and you get a stack trace." I'd say the other missing piece of REPL development is that while you get a stack trace, you don't get a program state…

> Maybe I'm "holding it wrong" but this causes a lot of friction and lost time.

It is a completely non-problem for functional code. It is a big problem for imperative code.

You can't just write all of your code in a functional style, but depending on what you are doing the limit gets larger or smaller. So it's normal that this will be a showstopper for some people, and irrelevant to others.

Re: REPL vs CLI: IDE wars

#28

Post by geokon »

marcosdumay wrote: post #26
geokon wrote: post #14

Thanks for introducing me to `add-lib` This is going to be a huge time saver :) More info here: https://insideclojure.org/2018/05/04/add-lib/ Hopefully there will be some way to just "reload" your whole `deps.edn` though "If you get an error, the execution stops by default and you get a stack trace." I'd say the other missing piece of REPL development is that while you get a stack trace, you don't get a program state…

> Maybe I'm "holding it wrong" but this causes a lot of friction and lost time. It is a completely non-problem for functional code. It is a big problem for imperative code. You can't just write all of your code in a functional style, but depending on what you are doing the limit gets larger or smaller. So it's normal that this will be a showstopper for some people, and irrelevant to others.

I don't really follow.. How is it a non problem in functional code? For instance you have some recursive idempotent function that blows at some point. Wouldn't you wanna see the state at which things broke?

Just because things are functional doesn't mean you always knows the inputs at all times

Re: REPL vs CLI: IDE wars

#29

Post by dghf »

geokon wrote: post #14

Thanks for introducing me to `add-lib` This is going to be a huge time saver :) More info here: https://insideclojure.org/2018/05/04/add-lib/ Hopefully there will be some way to just "reload" your whole `deps.edn` though "If you get an error, the execution stops by default and you get a stack trace." I'd say the other missing piece of REPL development is that while you get a stack trace, you don't get a program state…

This should work just as well:

    (csv/read-csv (slurp "my-csv-file.csv"))
Or if you prefer the threading-macro style:

    (-> "my-csv-file.csv" slurp csv/read-csv)

Re: REPL vs CLI: IDE wars

#30

Post by geokon »

dghf wrote: post #29
geokon wrote: post #14

Thanks for introducing me to `add-lib` This is going to be a huge time saver :) More info here: https://insideclojure.org/2018/05/04/add-lib/ Hopefully there will be some way to just "reload" your whole `deps.edn` though "If you get an error, the execution stops by default and you get a stack trace." I'd say the other missing piece of REPL development is that while you get a stack trace, you don't get a program state…

This should work just as well: (csv/read-csv (slurp "my-csv-file.csv")) Or if you prefer the threading-macro style: (-> "my-csv-file.csv" slurp csv/read-csv)

Oh thanks. Yeah. I thought maybe I was noobing it up :)

Always nice to learn something new

Post reply on HN