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

The Land of Lisp

landoflisp.com

Post reply on HN
Print view View original

111–120 of 146 posts

Re: The Land of Lisp

#111

Post by endgame »

drcode wrote: post #32
flavio81 wrote: post #22

This book is destined to be a classic programming book, just as "The C programming language", "The Little Schemer" or "Operating systems: Design and implementation". I would really like to meet Conrad Barski and give him a great hug. And invite him a good beer. Be sure to read the comic that is on the bottom of the page!! Now, to be honest, a quicker or more practical introduction to Lisp would be the "Practical Comm…

Thanks for the kind words! Glad you enjoyed my book!

As an avid haskeller with a lot of respect for lisp, I've gotta say I really love the depiction of the Republic of Haskell as a police state, where side effects receive no mercy.

Re: The Land of Lisp

#114

Post by TeMPOraL »

flavio81 wrote: post #75
stevelosh wrote: post #59

This book comes up in #lisp on freenode every so often, and the channel is generally split on whether or not to recommend it. I generally do. It's fun and lighthearted. Using games as a medium to teach the language is something some people enjoy, and is a lot less dry than most programming books. It avoids taking sides on the editor war, by just ignoring it altogether and teaching Lisp . This is refreshing compared t…

> The main issue people have with the book is that it uses CLISP-specific code in a few places. This makes sense for a tutorial book, since CLISP is easy to install, very small to download (compared to SBCL), and is a fully featured (ANSI compliant) implementation. So i don't think it was a mistake to choose CLISP. The recommendation in #lisp for SBCL over CLISP might be because SBCL is nicer to the programmer, offer…

I'd add one more very popular implementation:

  CCL - Clozure CL
     Produces fast native code; compiles faster
     than SBCL. Also has some MacOS-specific goodies.
People sometimes use both CCL and SBCL at the same time, to have faster compiling during development via CCL and then better runtime performance of the released version via SBCL.

I used to use CCL for hobby gamedev back when SBCL had some troubles on Windows (they're gone now); now I only use it on Raspberry Pi (AFAIK SBCL couldn't utilize multiple cores on ARMs last time I checked (which was a years ago)).

Re: The Land of Lisp

#115

Post by TeMPOraL »

Koshkin wrote: post #29
mike_ivanov wrote: post #16

Earlier quoted context omitted.

"rather than looking like templated design patterns" - that is, the code goes straight to the point instead of being littered with incidental noise and ceremony? How that could possibly be a bad thing? Well, in certain software development subcultures ceremony might be a norm, but not in general.

From what I have seen, code that "goes straight to the point" is usually poorly thought out, is unmaintanable, has bugs, is difficult to extend to new use-cases, and the developer who wrote it is long gone.

No, it's the opposite - it doesn't have to drag around pointless layers of unused abstractions, and all the bugs that are there are bugs of subject matter, not of surrounding boilerplate. Such code minimizes the surface area and degrees of freedom, hence not leaving space for bugs.

The more I program, the more I'm convinced that - unless you've coded identical software many times before - code needs to grow organically and stay as focused and close to the problem as possible. Abstractions should follow naturally and be done "just in time". If they're needed, they have to be written either way, and you're not saving time by writing them up front (focused code is easy to refactor).

Of course with experience, you learn that some patterns of change are likely to occur, or that some touches of abstractions here and there are very beneficial. But beyond that, I feel the best way is to write simplest code possible, wait for it to be needed elsewhere, and then DRY up semantics.

I liked the posts of Casey Muratori, which explain roughly this mindset, calling it "semantic compression" and "compression-oriented programming": https://mollyrocket.com/casey/stream_0019.html.

Re: The Land of Lisp

#116

Post by TeMPOraL »

Koshkin wrote: post #51
hellofunk wrote: post #36

Earlier quoted context omitted.

That might be (perhaps) true in other languages, but that is not the point in Lisp.

Best practices, patterns, idioms are all important no matter what language. Lisp is not special in this regard (although, I admit, Lisp developers may stick around a bit longer).

Best practices, patterns and idioms are all tools, not religious symbols. If you treat them as the latter, you end up with things like JavaScript one-line projects that have 1kb worth of grunt/gulp/webpack config files, or with HelloWorldFactoryLightweightBridgeBuilderAbstractFacade in Java.

Re: The Land of Lisp

#117

Post by TeMPOraL »

Vekz wrote: post #50
stevelosh wrote: post #44

Earlier quoted context omitted.

> I was greatly disappointed with this book because none of the 'Game' examples had a graphical interface to them. They are all text based. Chapter 19 is titled "Creating a Graphical, Web-Based Version of Dice of Doom".

Unfortunately, this web-based version is just printing text to the browser instead of a repl in the other examples.

Using a local web browser as your user interface is a valid method for making user interfaces; in fact, it's a very cool and cheap one - all it takes is to embed a HTTP server in your application and have it output HTML/CSS/JS (+ SVG for extra pretty graphics).

Re: The Land of Lisp

#118

Post by TeMPOraL »

Vekz wrote: post #40

I was greatly disappointed with this book because none of the 'Game' examples had a graphical interface to them. They are all text based. Reading further in this thread people are suggesting Realm of Racket as an alternative and it looks like that book has much more visual game examples: https://realmofracket.com/games.html

TBH, as someone who learned programming through making games (with graphics!), it disappointed me too. That said, I found it to be only a small issue (and arguably a justified decision) in otherwise great book. A lot of the game code is really separate from the issues of display. In later chapters, the book uses the web browser to provide for a graphical display. And also, come on, the type-in implementation of Robots game made half-a-page long through abusing loop and format is just plain awesome xD.

Re: The Land of Lisp

#119

Post by TeMPOraL »

hellofunk wrote: post #82
lispm wrote: post #78

Earlier quoted context omitted.

Common Lisp: (defmethod collide ((object1 space-ship) (object2 rocket)) "Inline documentation for this method..." (the debris (create-debris-from space-ship)) SPACE-SHIP and ROCKET are types and classes. DEBRIS would also be a type and a class. Use DEFTYPE, DEFCLASS, DEFSTRUCT, ... to define new types. Use CHECK-TYPE and ASSERT to have runtime checks, integrated with the condition system.

Well I can do runtime checks just as easily in Clojure, but I'm really talking about compile time checks.

That (static type checking) is unfortunately not the part of the standard, but some implementations take extra care to help you. In particular, SBCL will do its best to use every and all type declarations you provide to both statically check and optimize your code.
Post reply on HN