Hacker News Reader

Comment by 7thaccount | Hacker News Reader

I thought there was some interesting history in the book and certain common lisp implementations like SBCL are incredibly fast and powerful (some real secret alien technology there), but I thought that I could generally make shorter and clearer programs in just about any common scripting language (Python, Perl, PowerShell...etc). Granted, I know those languages better, but the book honestly didn't want to make me write Lisp. Homoiconicity is insanely powerful, but I find that specific syntax for certain things is easier for me to read and write up to a certain point.

View on HN

The best part of Land of Lisp is learning to use SLIME. Except that learning it (and REPL-driven development) makes all other language/editor integrations seem inadequate! (one exception I know is CIDER for Clojure, also excellent)

Not as that book. In fact it is after nearly 1 decade after I finished that book and finally do this REPL and live code editing in lisp via

https://susam.net/blog/lisp-in-vim.html

It would be better if it was ihtroduced then.

Not my experience at all. I have spent enough time doing REPL-driven development to know that I most definitely do not prefer it. It might be superior for you. But that doesn’t automatically mean that it will also be superior for anybody else. We are all different, with different preferences and work styles.

Would you mind shedding some light on how you do development and the pros and cons you experienced comparing to REPL-driven development?

Sure. I think REPL-driven development is great for what I call exploratory programming. When you are playing around with ideas and want to quickly try out different approaches and quickly test if a new function is working. However the code that I normally deal with are very large code bases where a lot of the code is not written by myself. And I find it a lot easier to navigate and build a mental model of where things are and how it works using an IDE. It simply works better for my brain but of course YMMV.

Why not both? Are the two concepts somehow incompatible?

A REPL is a (very) powerful tool for testing, probing, inspecting (etc) code; but it is only one tool. It should be a part of your IDE (if you go for such things), not replace it.

Wouldn't it make more sense to automate the tests instead of doing it manually? I have 9000+ auto tests for the large complex C++ code base I am currently maintaining. And the result is zero customer production bugs in the last 5+ years. And I routinely refactor and rewrite large parts of the code without worrying about it.

Yes, automated test suites are great! I don’t know that they need all the things some people stuff into them, but the idea is a useful one.

If you take my comment in the context of REPL-driven development, it’s going to seem tangential at best. But you mentioned that you prefer IDEs over REPLs; I’m merely suggesting that the two need not be exclusive.

Unless you’re advocating for TDD, in a strict sense?

Not OP, but I would venture that REPL-driven development encourages a style that is essentially trial and error programming.

This may be good for small scale, short lived scripts and projects but it does not scale.

My experience from a somewhat large (400+ people) Clojure project is that people would be better off building a test suite as a checked-into-source-control REPL substitute to drive their experiments and make sure the expected application behaviour stays the same over time.

REPLs may be useful, but don’t use them as your only tool.

Yep a good match for how I am thinking. One of the large projects I work on is written in C++ and it has more than 90000 use case tests to make sure it is safe to deploy into production. I haven’t had a customer production bug in the last 5+ years.

For me, the biggest problem with REPL-driven development is the handling of global state. That's why there's no fewer than 5 (!) actually-being-used Clojure libraries for handling it.

What "handling of global state" are you referring to? The state of "vars" or the state of actual application data (a la "atom"s)? The former being solved with the various ns-* functions, the latter depends on the application and how state is being used. If you could, could you share the libraries you're referring to too?

> If you could, could you share the libraries you're referring to too?

Component, Mount, Integrant, System, Clip.

My reaction as well. The exaggerated claims of Lisp programs being bug free and non-Lisp programmers being slaves/prisoners/drones etc. doesn’t give me confidence in anything the author claims. I know it is supposed to be funny, and I do enjoy the humour, but I would prefer some real life stories about how complicated problems were fixed in Lisp better than what I could have been done in other languages. Lisp has cool features, but that doesn’t necessarily result in better software being developed in Lisp. Certainly looking around there doesn’t seem to be a lot of successful software written in Lisp. The world runs on other languages.

Lilypond (http://lilypond.org/index.html) is music typesetting software that is not for everyone, but can be a joy to use if you have a software background.

It makes extensive use of Scheme under the hood, because C++ proved "too inflexible". I've never looked at the details of what the authors meant by that.

They have some notes on it here if you're curious:

http://lilypond.org/doc/v2.22/Documentation/essay/building-s...

Thanks for the link! That was a great read. And a good example I think of using Lisp embedded in a C++ program to give the user more power and flexibility. I think it is the right way to do it when your UI is basically code. A lot of games do something similar (using embedded Python, Lua or Lisp) to make it possible for gamers to extend the game. I think Factorio use Lua for this. But Lisp would have been another good choice I think.

You're welcome! Glad to hear you enjoyed it.

I'm familiar with game engines embedding scripting languages, but using Lisp for that honestly hadn't occurred to me (despite being an Emacser that has written several small elisp packages).

Are you aware that Crash Bandicoot for the Playstation and a bunch of follower games were originally written in a Scheme dialect, with the development environment written in Common Lisp (on SGIs)?

Yep and I think it is super cool. More stories like that would do more to improve Lisp adaption than yet another “Lisp is great” article. Don’t make empty claims. Do something cool and then talk about it.

Not at all. That's fascinating.

Do you have a link or reference I could learn more about it from?

See 'GOOL' and later 'GOAL':

https://all-things-andy-gavin.com/2011/03/12/making-crash-ba...

https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Very neat. Thank you!

Reply on news.ycombinator.com