Live data from Hacker News

Notes on debugging Clojure code

eli.thegreenplace.net

41–50 of 50 posts

Re: Notes on debugging Clojure code

#41

Slight tangent: Am I the only one that's a little bit annoyed that it seems like you need to start using the complex beast that is Emacs to get first class Lisp support? There are one-off apps, but everyone swears by SLIME mode or similar. Yes, I get it. The editor itself is written in Lisp. It's the most hackable thing out there. Yes, fine. It is a masterpiece of technical achievement. That's all well and good, but.…

Agree. I've been using IDEA + Cursive, and it's great and easy to use and all that, but lately I'm starting to get tired of it -- it's just so heavy weight, to the point the entire IDE will sometimes hang on me for seconds at a time while I'm trying to enter code.

I've been thinking of trying out vim + fireplace (since I already know vim well enough). Emacs + CIDER will be a last resort as the learning curve for emacs is fairly steep, which is the reason I chose vi all those years ago when I was starting out with *nix and needed to choose an editor to learn :)

Re: Notes on debugging Clojure code

#42
post #12
post #9

Earlier quoted context omitted.

This is a terrible advice, and is not even necessary. Even println debugging is better than this. Not only defs are abused contrary to their intended use, they are difficult to distinguish from legitimate defs, and thus some may (and will!) slip away into the wild.

> Even println debugging is better than this. Print debugging is great. A carefully placed print statement is something many great programmers swear by [1], despite the existence of "sophisticated" debuggers (see footnote in OP). This is a complement to this when you want to play around with the data directly. > Not only def's are abused contrary to their intended use, they are difficult to distinguish from legitimat…

Why not define debug-req and debug-auth as atoms before this function, and set them with (reset! debug-req req) etc.?

Re: Notes on debugging Clojure code

#43
post #21

When it comes to debugging, I'm firmly in the printf camp; I rarely prefer debuggers over printf-based debugging I'm struggling to understand this. Why would you ever prefer printf debugging in your local dev environment over using a debugger?

I use both. They are useful in different situations. printf is lightweight, and can let you dump a lot of information very fast. It's a good approach when you're reasonably confident about what you need to know. A debugger gives you more flexibility about the questions you can ask on any particular run.

Re: Notes on debugging Clojure code

#44

Slight tangent: Am I the only one that's a little bit annoyed that it seems like you need to start using the complex beast that is Emacs to get first class Lisp support? There are one-off apps, but everyone swears by SLIME mode or similar. Yes, I get it. The editor itself is written in Lisp. It's the most hackable thing out there. Yes, fine. It is a masterpiece of technical achievement. That's all well and good, but.…

SLIME + Emacs user here. I always wondered if there is something similar to SLIME for Clojure, because soon I'll try Clojure as well, despite knowing the tortures of having to deal with the Java platform. Slime is awesome, however...

I can feel your pain, because that's what i thought when I first tried to use Emacs. My feelings ranged from "hideous horrible monstrosity" to "looks interesting but can't use it."

Really, after one or two days of using Emacs to write Common Lisp, Emacs became second-nature to me. And you start to appreciate how easy is to have a separate concept of "buffers" versus "windows". In short, arranging your screen to work quickly, is very easy and quick.

At the end, the shortcut keys for Emacs do have some sort of logic. Thus i present a

    *EMACS/SLIME KEYS PRIMER in 5 MINUTES, FOR SANE PEOPLE*
    in the insane world of Emacs
    -----------------------------------------------

    This assumes that you're running Emacs on a windowing system like X or
    Windows. Thus you have a nice menu bar that you can use with the
    mouse.

    The first you need to know is that "Meta" is the "alt" key. So "M-a"
    means "press Alt+a".

    The first key combination you need to know is "Control-H b" (_H_elp me
    with the _B_indings). This will make Emacs open a window which will
    tell you ALL the key mappings. That is, which key combination does
    which thing. Since this window is HUGE, press Control-S (_S_earch) and
    write the string you want to search, if you are looking for a
    particular command. Press Control-S several times until you locate
    it. To search in _R_everse, Control-R.

    The next key combination you need to know is "Control-G" (_G_o to
    hell). This cancels any command that is prompting you for input on the
    status bar.

    Now, the other thing you will need is to do COPY and PASTE. Easy to do
    this is with the "Insert" (Ins) key.  Control+Insert == COPY
    Shift+Insert == PASTE

    Now, the EMACS keys do have some logic, and this can help you remember
    them.

    Control-X for commands that have to do with Emacs itself, like editing
    commands. For example "Control-X U" is _U_ndo.

    "Control-X S" is _S_ave.

    Alt-X (called "Meta-X") executes a command, for which you write the
    name of the command. This can execute any of the thousand commands
    available on Emacs. Each command is basically a LISP function that you
    will invoke.  It is very simple to invoke a command, and if you don't
    know the full name of the command, you just write the beginning of the
    command, press TAB, and Emacs will list you all the available
    commands.

    So, if you want to start SLIME, the command is "slime". Alt-X "slime"
    ENTER.

    Once you're in SLIME mode, you have SLIME commands at your
    fingertips. Most of the SLIME commands start with "Control-C".

    So, for example to load and compile the current file into Common Lisp,
    you do: Control-C-K , which "K"ompiles the file.

    Or for example you want to compile just a small part of the code, for
    example a DEFUN you have wrote. Just select (using the mouse or
    keyboard) the complete definition (or part of the code) and press
    Control-C-C to "C"ompile that section. Now it is available so you can
    use that function/macro/etc on the REPL, which is the "buffer" called
    *slime-repl*.

    When you are writing code, SLIME auto-completes as much things as it
    can, you just need to press TAB to invoke the autocomplete. Also,
    SLIME will tell you what are the arguments of each function you call,
    as you are writing the code.  If you want, SLIME can also _S_upply all
    the required function/macro parameters, just press Control-C-S.

    There is also an ALTernate _I_ntelligent auto-complete, that you can
    invoke using Control-C ALT-I. See?

    Want to know which functions are in a package and describe a simple
    _D_ocumentation for each function in the _P_ackage? So, Control-C,
    Control-D, P.  Or want to look the Common Lisp _D_ocumentation for
    _H_elp? Control-C, Control-D, H. Etcetera.

    -------------------------------
    
SLIME is really an mind-opening experience for me, after having used MS Visual Studio, Visual Studio Code, Netbeans, Eclipse, and PyCharm. SLIME enables to work interactively, very quickly.

As for Emacs, final words are some wisdom words of HN user "Karunamon" which wrote:

"The editor itself is written in Lisp. It's the most hackable thing out there. Yes, fine. It is a masterpiece of technical achievement. "

Re: Notes on debugging Clojure code

#45
post #34

Slight tangent: Am I the only one that's a little bit annoyed that it seems like you need to start using the complex beast that is Emacs to get first class Lisp support? There are one-off apps, but everyone swears by SLIME mode or similar. Yes, I get it. The editor itself is written in Lisp. It's the most hackable thing out there. Yes, fine. It is a masterpiece of technical achievement. That's all well and good, but.…

It makes sense to use Lisp-specific tools with Lisp, otherwise the whole experience is underwhelming. The best Lisp tools are usually written in itself or some variant of it. On the Mac you can download Clozure Common Lisp from Apple's Macintosh application store: https://itunes.apple.com/us/app/clozure-cl/id489900618?mt=12 It comes with a small IDE written in itself. A lot of people who use CL as a serious hobby or…

I would love a proper "hobbyist" priced license for a full 64-bit LispWorks at around $200.

Stephen Wolfram did it for Mathematica (Home license)...

Re: Notes on debugging Clojure code

#46
post #34

Earlier quoted context omitted.

It makes sense to use Lisp-specific tools with Lisp, otherwise the whole experience is underwhelming. The best Lisp tools are usually written in itself or some variant of it. On the Mac you can download Clozure Common Lisp from Apple's Macintosh application store: https://itunes.apple.com/us/app/clozure-cl/id489900618?mt=12 It comes with a small IDE written in itself. A lot of people who use CL as a serious hobby or…

I would love a proper "hobbyist" priced license for a full 64-bit LispWorks at around $200. Stephen Wolfram did it for Mathematica (Home license)...

The LispWorks 64bit hobbyist license costs 600 Euro. It is not tied to a single machine and can run more then one process.

Re: Notes on debugging Clojure code

#47
post #39
post #32

Earlier quoted context omitted.

Nim and Scala are not homoiconic, yet they both have true macros

Dylan?

After reviewing Dylan's, it doesn't seem as powerful. And it's unclear how it handles runtime variables passed within code snippets to macros (Elixir has "unquote" for this)

Re: Notes on debugging Clojure code

#48
post #32

Earlier quoted context omitted.

> While I miss code-is-data very much FWIW, Elixir has this (and is possibly the only non-homoiconic language to implement "true" macros) Opt-in typing, though. Regarding Elm, I love that runtime errors are considered compiler bugs.

Nim and Scala are not homoiconic, yet they both have true macros

Nim's macros look harder to use, with a fairly custom DSL in the AST (instead of, say, a simple datastructure like a nested map). I don't think you can pattern-match on AST fragments, either, like you can in Elixir.

Scala macros cannot change its syntax, Elixir macros can I believe (to some extent).

Re: Notes on debugging Clojure code

#49
post #32

Earlier quoted context omitted.

Nim and Scala are not homoiconic, yet they both have true macros

Nim's macros look harder to use, with a fairly custom DSL in the AST (instead of, say, a simple datastructure like a nested map). I don't think you can pattern-match on AST fragments, either, like you can in Elixir. Scala macros cannot change its syntax, Elixir macros can I believe (to some extent).

The AST of Nim is a simple tree, the only thing is that the nodes of this tree are tagged with a kind that represents the kind of syntactic element, since the language is not homoiconic

Re: Notes on debugging Clojure code

#50
post #8
post #7

I fear Lisp had already a better debugging experience in the mid to late 60s...

Clojure also has better debugging experience. This is a bare-bones workflow of a guy who doesn't use the best tools available in Clojure.

Better debugging experience than Common Lisp? Are you sure? Do you know what happens when you hit a runtime error in Common Lisp? You get a full backtrace of all the calls that lead to the error, the error code, the error explanation, and THEN a lot of options that you can do to make your code keep working "on the fly", for example the runtime environment will give you the following options:

   0: [KEEP-OLD] Keep symbols already accessible FOO (shadowing others).
   1: [TAKE-NEW] Make newly exposed symbols accessible in FOO, uninterning old ones.
   2: [RESOLVE-CONFLICT] Resolve conflict.
   3: [RETRY] Retry SLIME REPL evaluation request.
   4: [*ABORT] Return to SLIME's top level.
   5: [ABORT] Abort thread (#)
Post reply on HN