Hacker News Reader

Comment by daly | Hacker News Reader

I prototype in Common Lisp (described as "clay for the mind"). This gives a clear, standards-defined, prototype.

Then I hand-translate it to C, usually without bugs since every function has a well-defined specification.

The key issue is "impedence mismatch" (eg, hooking a soda straw to a firehose).

C is "close to the machine" and "far from your problem".

Lisp is the only language I know that is close to the machine and close to the problem. So, for example, (integrate (car x)) uses a machine pointer (car) on a data structure and then calls a "problem specific routine" all the same statement.

Think in Lisp, code in C.

View on HN

> This gives a clear, standards-defined, prototype ... every function has a well-defined specification

This isn't specific to Lisp, right? Any other language would also ensure every function was unambiguous, no?

I'm also not understanding how your "(integrate (car x))" example illustrates Lisp being "close to the machine". How does this differ from "integrate(x.first)" or something in other languages?

because .first invokes some machinery. Usually some OOP/FP machinery.

The function CAR is a primitive operation in Lisp, which usually gets compiled to only a few basic machine instructions. CAR is basically just returning the first part of a cell made of two pointers (or similar sized immediate data like fixnum integers).

> because .first invokes some machinery. Usually some OOP/FP machinery.

It depends on the language and how you use it. Accessing a member of a C/C++ struct, a final member of a C++ class, Python class with __slots__, etc, is as efficient as a CAR operation. They all give you data that's at a particular place relative to the start your cell/struct/class.

Which is fine until someone changes the C++ struct definition. This 'non-local' change affects the semantics of your code. Lisp's CAR definition is unaffected by non-local changes.

You can think in any language but as noted by Wittgenstein “the limits of my language mean the limits of my world." For example, while it is technically possible in any language, the ability to write self-modifying code is unlikely to be thought of in most languages. Try writing non-object oriented code in Java.

> changes the C++ struct definition

I don't think that's right? If we were talking about a class, then yes, but with a struct I don't think there is anything you can do that would change the nature of a property lookup.

> This 'non-local' change affects the semantics of your code.

I thought we were talking about how to pick a language for performance constrained solo prototyping? In which case you don't need to worry about someone else making changes to your code.

Reply on news.ycombinator.com