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

My Clojure Workflow, Reloaded

thinkrelevance.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: My Clojure Workflow, Reloaded

#21

Post by kleiba »

Tuna-Fish wrote: post #20
kleiba wrote: post #19

Earlier quoted context omitted.

I'd probably put it after the parameter lists: (defn foo ([x] *docstring* "bar") ([x y] *docstring* "baz")) because you want to be able to document the different implementations differently. The semantics would be: If the function body starts with a string literal, the latter serves as the documentation. If the body consists of any other code following the string literal, it will be ignored for run-time processing; i…

> because you want to be able to document the different implementations differently. I disagree with this. Since the normal functions cannot dispatch on type⁺, only arity, the different implementations are typically very related and should share same documentation. Your proposal would lead to massive duplication, and reduce the likelihood of people actually documenting the functions. ⁺ There are two separate mechanis…

Yeah, I guess you've got a point there.

However, if this only applies to different arities, please also compare to the following style:

    (defun function (a b &optional c d e)
      "Documentation string"
      "return value"))
I still think that the function signature is more readable when the doc string comes after the parameters, but perhaps it's just a matter of taste.

The above is obviously not Clojure. But as I commented originally, I just wasn't aware that this is the way Clojure does it.

Re: My Clojure Workflow, Reloaded

#22

Post by spullara »

Kaali wrote: post #4
_pmf_ wrote: post #2

It's a bit ridiculous[1] that one has to jump through hoops with Clojure to get the benefits that Java hotswapping provides out-of-the-box (i.e. changing a method and transparently recompiling and changing to the new implementation in the running JVM) with even second rate IDEs like Eclipse (which I am using). Note that this is without any third-party plugins and Oracle's standard VM. [1] And by "a bit ridiculous", I…

Clojure has excellent support for hot swapping functions and data; which in my experience is far ahead of anything that Java has. The system introduced in this article is for reloading code but with a consistent state. For example, if your application includes some state from previous actions. Then you change a function that acts on that state, but with a different protocol (e.g. data structure expectations changed i…

Try JRebel.

Re: My Clojure Workflow, Reloaded

#23

Post by mcav »

kleiba wrote: post #17

I didn't know that Clojure puts function comments between the function name and the parameters. I personally find that a bit awkward - wouldn't it make more sense to have it after the parameters, to allow to simply glance at the function definition and see its signature, especially when comments extend over multiple lines?

It's ambiguous the other way:

   (defn some-string []
      "is this a docstring or a return value?")

Re: My Clojure Workflow, Reloaded

#24

Post by pjmlp »

outworlder wrote: post #11

> It is dangerously easy, when changing and reloading code at the REPL, to get an application into a state which could not have been reached by the code it is currently running. This is the key point people some comments have been missing. Since you can evaluate code whenever you want, the running instance might become a frankenstein, containing code and data that shouldn't be around anymore. I'd like to see the poin…

I only used Smalltalk at the university back in the day, before Java was born and it was a very nice experience.

All the talks about live editing is nothing more than recovering the workflows we already had in Smalltalk and Lisp machines.

If you destroy the environment, just restart not a big deal.

If you already saved the environment into the image, just rollback to the previous image snapshot, not a big deal specially nowadays that image based source control systems are available, like Monticello and Metacello.

Re: My Clojure Workflow, Reloaded

#25

Post by aerique »

outworlder wrote: post #11

> It is dangerously easy, when changing and reloading code at the REPL, to get an application into a state which could not have been reached by the code it is currently running. This is the key point people some comments have been missing. Since you can evaluate code whenever you want, the running instance might become a frankenstein, containing code and data that shouldn't be around anymore. I'd like to see the poin…

I develop Common Lisp the same way (against an image) and it only was a problem when I just started. Soon enough it becomes second nature to know which functions have been changed and / or knowing when it is time to start over with a fresh image.

tl;dr it is not much of an issue

Re: My Clojure Workflow, Reloaded

#26

Post by DigitalJack »

mcav wrote: post #23
kleiba wrote: post #17

I didn't know that Clojure puts function comments between the function name and the parameters. I personally find that a bit awkward - wouldn't it make more sense to have it after the parameters, to allow to simply glance at the function definition and see its signature, especially when comments extend over multiple lines?

It's ambiguous the other way: (defn some-string [] "is this a docstring or a return value?")

Clojure works with it in either case, and it is not ambiguous due to the arity of defn.

Re: My Clojure Workflow, Reloaded

#27

Post by weavejester »

spullara wrote: post #22
Kaali wrote: post #4

Earlier quoted context omitted.

Clojure has excellent support for hot swapping functions and data; which in my experience is far ahead of anything that Java has. The system introduced in this article is for reloading code but with a consistent state. For example, if your application includes some state from previous actions. Then you change a function that acts on that state, but with a different protocol (e.g. data structure expectations changed i…

Try JRebel.

JRebel seems a big improvement over normal JVM hot swapping, but it still doesn't seem to be quite as comprehensive as the capabilities a dynamic language like Clojure offers.

Re: My Clojure Workflow, Reloaded

#28

Post by weavejester »

DigitalJack wrote: post #26
mcav wrote: post #23

Earlier quoted context omitted.

It's ambiguous the other way: (defn some-string [] "is this a docstring or a return value?")

Clojure works with it in either case, and it is not ambiguous due to the arity of defn.

I think you're misunderstanding, because (a) no it doesn't, and (b) no it isn't :)

Clojure docstrings need to precede the argument list. e.g. this is correct:

    (defn foo
      "Some docstring"
      []
      "Some return value"))
But this is not:

    (defn foo
      []
      "Some docstring"
      "Some return value"))
It will still compile, but the first string will be treated as an expression, and therefore ignored as it has no side effects.

The reason docstrings in Clojure come before the arguments, is that because if they came after, their effect would be ambiguous, regardless of arity. e.g.

    (defn foo [] "foo")
Is the string supposed to be the return value of the function, or its docstring?

Re: My Clojure Workflow, Reloaded

#29

Post by jmw74 »

moonboots wrote: post #6

I was experimenting with integrated tools.namespace reloading in elisp as well, and I found a slightly nicer way to send commands to nrepl: (defun nrepl-reset () (interactive) (nrepl-interactive-eval "(user/reset)")) The original elisp function: (defun nrepl-reset () (interactive) (set-buffer "*nrepl*") (goto-char (point-max)) (insert "(user/reset)") (nrepl-return))

Note the former technique will display the output in the minibuffer, the latter will display it in the repl.

Re: My Clojure Workflow, Reloaded

#30

Post by kleiba »

weavejester wrote: post #28
DigitalJack wrote: post #26

Earlier quoted context omitted.

Clojure works with it in either case, and it is not ambiguous due to the arity of defn.

I think you're misunderstanding, because (a) no it doesn't, and (b) no it isn't :) Clojure docstrings need to precede the argument list. e.g. this is correct: (defn foo "Some docstring" [] "Some return value")) But this is not: (defn foo [] "Some docstring" "Some return value")) It will still compile, but the first string will be treated as an expression, and therefore ignored as it has no side effects. The reason do…

Other Lisps do it that way without a problem:

- If the function body starts with a string literal, it is always the doc-string

- If that string is the only thing in the function body, it is also the return value.

Post reply on HN