4 ms·

SBCL (which Rigetti has chosen for qvm and quilc) is better than OCaml in pretty much every aspect of importance for these projects. Performance (compiler macro

• reikonomusha 8y ago
  As a heavy user of both languages (though I’m partial to Standard ML compared to OCaml), I strongly agree with this sentiment.
  • mruts 8y ago
    OCaml’s syntax feels a little (well actually a lot) clunky and illthoughtout. Reason ML fixes a lot of these problems and is a great language all around. I’m a hardcore static typing guy (though I started with Common Lisp, which is why I really appreciate static typing), so maybe I’m biased though. I’ve programmed professionally in both CL and Racket (though it was a research institution so maybe “professionally” isn’t the right word), and in both languages always felt this sense of unease when hitting the “run” button. Half the time the program would error out with something that even the most basic type checker would catch (you called car on a non-list type, oh no!). When programming in OCaml, or Haskell, or Scala, I feel like I have a guardian angel watching my back. Being able to move many runtime errors into compile time errors is such a great thing, I’m not sure why some people prefer dynamic typing. Certainly, the number of correct program with static typing is a subset of programs with dynamic typing (which can be keenly felt with Typed Racket) but even with this restriction, I still think static typing is a massive win. Admittedly though, with a big enough working memory, it shouldn’t make a big difference. Personally though, I love myself some auto-completes and underlined red squiggles!
    • armitron 8y ago
      I don't know how you programmed CL, since there is no "Run" button like in DrRacket (which simply evaluates everything and discards previous state) but if you did the equivalent of that, you were doing it wrong. The way one should program Common Lisp, is through an environment like SLIME which lets you write code interactively and iteratively. DrRacket is very far away from that. In CL/SLIME, you usually evaluate everything you type in, immediately after you do so. Since you program inside a live environment, you can see this as continuously adding to a live process and molding it to your mental model. You build your program up from zero and all state is kept as you do so. There is no reload/wipe-previous-state/run cycle. This way of engineering, when done over a short feedback loop, is supremely powerful. I can't stress this enough. Since you can evaluate expressions inside your editor, without any context switches [unlike Python, Ocaml, Haskell where there is a separate interpreter and one does not build his program up from scratch from inside the interpreter], evaluating things becomes second nature. So you do it all the time. Not to mention that the entire language is geared around this sort of development. The object system (CLOS) allows you to redefine pretty much everything at runtime. The debugger allows you to do the same. Errors (conditions) can have associated restarts that you can select interactively. You have inspectors that let you dig into the state of your process as it runs. The short of errors you are describing are easy to catch and after becoming proficient working in this way, simply do not happen. The main issue that a lot of dabblers in Lisp run into is that they are not exposed to the Lisp Machine development paradigm and thus do not know how CL is different and how to take advantage of all that it offers. If DrRacket -> Run was how I had to write Lisp code, I'd be quickly moving on to something else myself. Thankfully I can use SBCL / SLIME and recapture some (most?) of the magic of the Lisp Machines.
      • mruts 8y ago
        The “run” button is however you run your CL code. Are you seriously disputing my experience because I said “run” in quotes? Would it please you more if I had instead said I used SLIME with SWANK with emacs and I pressed C-c C-e or whatever? As I sais, I have programmed CL professional. And yes, Racket doesn’t have a real REPL. And yes, CL with emacs and SLIME and SWANK is nice or whatever, but personally, I’ve found that a REPL provides much more value with a dynamic language vs a static language. Why? Because with CL you need to be running each function because you have no faith in your code. The most trivial errors that could have been caught by a simple type checker will crash your program. I’ve almost never had the experience of writing say 300 lines of CL and having it work on the first run. Because of this, you have to use the REPL as a crutch. In contrast, with haskell or scala even though those languages provide a REPL, I rarely find myself using it. In fact, I very rarely run my code at all. With a functional and monadic style and heavy use of type parameters, chances are that if it type-checks, it is correct. One area in which CL is pretty cool is modifying a running image on the fly. I once fixed a bug mid-meeting with CL and everyone thought that was pretty cool.