4 ms·

For (most) languages lacking a REPL, it's very similar. Instead of a REPL you write compiled unit tests and/or test programs to poke around at the API. For la

For (most) languages lacking a REPL, it's very similar. Instead of a REPL you write compiled unit tests and/or test programs to poke around at the API. For languages with a reasonably sophisticated IDE, use the IDE itself to jump straight to the class/function declarations to understand the surface area of the API, and jump to the decompiled code for the implementation of those functions if you're the type to want to understand the machinery. Other languages (like Haskell) may not have the IDE support but attempt to solve the problem with auto-generated docs so you can at least see the surface area of the API and can start prodding it.

derefr 9y ago
> What's your experience level with other languages? ~15 years experience across C, ARM assembler, Javascript, Lua, Ruby, Python, Erlang, Go, and Rust. Mostly doing Elixir these days. Admittedly, I've never used an IDE; I write all my C in vim. > ...you write compiled unit tests and/or test programs to poke around at the API. That assumes you can get your tests to compile; or that the compilation errors are at-all helpful when they don't. If you've got a library that 1. ships as a binary blob + header files, and 2. most of its functions take handles to structs that are declared opaquely in the SDK headers; and yet 3. nothing you do with the badly-documented "create handle" parts of the API is giving you a struct that the "consume handle" parts of API will do anything with but crash... ...then you'll really wish that you had a REPL; or rather, a language runtime that enforced some level of introspect-ability on everything, so that a REPL could show you what's in the struct and whether your calls so far have failed to touch some obviously-necessary-to-fill-in part of it. Without such support, you will have to rely on reading the decompilation results of both ends of the API to figure out what's really going on.
- photojosh 9y ago
  > then you'll really wish that you had a REPL Yes. I write roughly equal amounts of C (microcontroller firmware) and Python (overall system control, running on embedded Linux). I absolutely wish I had a REPL for C. When implementing with a new library in Python, I'll usually use iPython to explore it, and if I need to run a decent amount of data through, I'll use a Jupyter notebook. I'd put the difficulty of grokking a C library somewhere between 10x and 100x harder.
  - yorwba 9y ago
    I use gdb as a C REPL. You attach it to a binary that has the functions you need, then you can use them with the `p` (or `print`) command. Loops and new function definitions are not possible, but sometimes it's still good enough.
    - pjmlp 9y ago
      That is how I once developed a B+ Tree library for low level disk blocks back in 1996, it was quite helpful tracking down how the nodes were being used.
    - RhysU 9y ago
      Gdb as REPL is a nice trick. Beaker Notebook might give the notebook parent wants for C work.
      - photojosh 9y ago
        Thanks. It won't since all my C work is embedded and mainly systems programming rather than algorithms. But I'll keep it in mind for the next time I have to translate my Python explorations over to C for production.
    - photojosh 9y ago
      Good point. I've only been working with AVRs for a few years since I've been at this job, but looks like it might be doable. Thanks for the tip.
  - pjmlp 9y ago
    C has had REPLs since the 90's, one just needs to search for them, and eventually buy them. They were quite common advertising in The C User's Journal and Dr. Dobbs.
- zzalpha 9y ago
  or rather, a language runtime that enforced some level of introspect-ability on everything And now we get to the real meat of it. It's not a REPL you want. It's reflection. It just so happens that the latter is frequently paired with the former. And I agree, that feature, which separates C#, Java, Ruby, Perl, Python, etc, from legacy languages like C make them significantly easier to use as a developer as the compiler, debugger, and IDE can do a much better job. But as a feature it's orthogonal to a REPL.
  - derefr 9y ago
    Reflection isn't orthogonal to a REPL; it's synergistic with a REPL. When you have a static language, yes, REPLs don't add much; reflection by itself is all you need and an IDE will suit you fine. But when you are working in a language with runtime code generation—one where objects can build themselves new runtime-native function handles in response to messages—then a REPL will be able to do things for you that an IDE cannot†. A REPL in a dynamic language (that takes advantage of its dynamicity) can be used to "explore" down CORBA/DBUS object trees; or fluently walk REST or SOAP endpoints without needing pre-baked WSDL descriptors to guide you to them. Heck, an Erlang REPL can hot-upgrade remote nodes. :) † Or, at least, not a traditional IDE. You would need an IDE connected to a "live session" of your project—essentially a hybrid IDE-REPL. (Examples: Light Table; Emacs' CIDER extension for Clojure.)
    - deleted 9y ago
      [deleted]
    - pjmlp 9y ago
      Lisp, Smalltalk and Mesa XDE at Xerox PARC are the genesis of what an IDE is supposed to be. Two dynamic and one static languages.

derefr 9y ago

> What's your experience level with other languages? ~15 years experience across C, ARM assembler, Javascript, Lua, Ruby, Python, Erlang, Go, and Rust. Mostly doing Elixir these days. Admittedly, I've never used an IDE; I write all my C in vim. > ...you write compiled unit tests and/or test programs to poke around at the API. That assumes you can get your tests to compile; or that the compilation errors are at-all helpful when they don't. If you've got a library that 1. ships as a binary blob + header files, and 2. most of its functions take handles to structs that are declared opaquely in the SDK headers; and yet 3. nothing you do with the badly-documented "create handle" parts of the API is giving you a struct that the "consume handle" parts of API will do anything with but crash... ...then you'll really wish that you had a REPL; or rather, a language runtime that enforced some level of introspect-ability on everything, so that a REPL could show you what's in the struct and whether your calls so far have failed to touch some obviously-necessary-to-fill-in part of it. Without such support, you will have to rely on reading the decompilation results of both ends of the API to figure out what's really going on.

photojosh 9y ago
> then you'll really wish that you had a REPL Yes. I write roughly equal amounts of C (microcontroller firmware) and Python (overall system control, running on embedded Linux). I absolutely wish I had a REPL for C. When implementing with a new library in Python, I'll usually use iPython to explore it, and if I need to run a decent amount of data through, I'll use a Jupyter notebook. I'd put the difficulty of grokking a C library somewhere between 10x and 100x harder.
- yorwba 9y ago
  I use gdb as a C REPL. You attach it to a binary that has the functions you need, then you can use them with the `p` (or `print`) command. Loops and new function definitions are not possible, but sometimes it's still good enough.
  - pjmlp 9y ago
    That is how I once developed a B+ Tree library for low level disk blocks back in 1996, it was quite helpful tracking down how the nodes were being used.
  - RhysU 9y ago
    Gdb as REPL is a nice trick. Beaker Notebook might give the notebook parent wants for C work.
    - photojosh 9y ago
      Thanks. It won't since all my C work is embedded and mainly systems programming rather than algorithms. But I'll keep it in mind for the next time I have to translate my Python explorations over to C for production.
  - photojosh 9y ago
    Good point. I've only been working with AVRs for a few years since I've been at this job, but looks like it might be doable. Thanks for the tip.
- pjmlp 9y ago
  C has had REPLs since the 90's, one just needs to search for them, and eventually buy them. They were quite common advertising in The C User's Journal and Dr. Dobbs.
zzalpha 9y ago
or rather, a language runtime that enforced some level of introspect-ability on everything And now we get to the real meat of it. It's not a REPL you want. It's reflection. It just so happens that the latter is frequently paired with the former. And I agree, that feature, which separates C#, Java, Ruby, Perl, Python, etc, from legacy languages like C make them significantly easier to use as a developer as the compiler, debugger, and IDE can do a much better job. But as a feature it's orthogonal to a REPL.
- derefr 9y ago
  Reflection isn't orthogonal to a REPL; it's synergistic with a REPL. When you have a static language, yes, REPLs don't add much; reflection by itself is all you need and an IDE will suit you fine. But when you are working in a language with runtime code generation—one where objects can build themselves new runtime-native function handles in response to messages—then a REPL will be able to do things for you that an IDE cannot†. A REPL in a dynamic language (that takes advantage of its dynamicity) can be used to "explore" down CORBA/DBUS object trees; or fluently walk REST or SOAP endpoints without needing pre-baked WSDL descriptors to guide you to them. Heck, an Erlang REPL can hot-upgrade remote nodes. :) † Or, at least, not a traditional IDE. You would need an IDE connected to a "live session" of your project—essentially a hybrid IDE-REPL. (Examples: Light Table; Emacs' CIDER extension for Clojure.)
  - deleted 9y ago
    [deleted]
  - pjmlp 9y ago
    Lisp, Smalltalk and Mesa XDE at Xerox PARC are the genesis of what an IDE is supposed to be. Two dynamic and one static languages.