Berry Web Blog -- page 1

The Case for LISP

Posted: 2015-09-15. Modified: 2016-01-25. Tags: LISP, Opinion, programming.
  1. There are multiple ways to think about problems. *
  2. Given a real-world or programming problem, often if you find the right abstraction to model it you can make the problem vastly simpler and/or make your software vastly higher quality.
  3. Therefore, solving a problem well should involve trying to find the best abstraction possible.
  4. Programming languages influence your thought processes to match what they offer.
    1. "if you see enough nails everything starts to look like a hammer".
    2. See: Sapir Whorf hypothesis and Paul Graham: Succinctness is Power.
  5. Lisp offers the flexibility to adapt to ANY paradigm, imposes the least constraints on your thinking, and therefore is likely often the best language to use to approach a problem. **

\* I hold the idea that there are multiple ways to think about problems to be fairly obviously true. But in case you don't agree yet, here is some justification. An example of a problem which can be profitably approached from multiple perspectives is "dynamic programming". I can either approach a dynamic programming problem using a top-down recursive viewpoint, or look at it from the bottom up as filling out values in a table. I can reason about DP as either constructing a DAG of subproblems or as filling out a table of precomputed values. There are MULTIPLE WAYS to think about the problem

\** One useful corollary to the idea that different paradigms are good for different applications is the common wisdom about optimal applications for functional and object-oriented programming. Functional languages are often said to be good for problems which resemble computation, with a defined input and output (like compilers). OOP languages are said to be good for problems where you model the natural world as objects. Lisp, of course, lets you choose between object-oriented and functional programming, and lets you implement entire new language structures within the language itself to extend the language to support most any paradigm you can think of.

How to Get SDL+Opengl Going on Windows

Posted: 2015-09-15. Modified: 2016-12-21. Tags: Windows, OpenGL, howto, practical.

I know these directions are a bit sketchy, for now I am just writing down what I remember from the process. I will test these instructions on a fresh box soon.

  1. Install SDL. Download SDL for mingw, ignore the install directions. Instead copy things into your c:/mingw directory.
  2. Install glew. download sources and compile with msys. then copy into appropriate directories (dlls go in C:\Windows\SysWOW64").
  3. Build the attached "test\opengl.c" with the following command:
    gcc -o test.exe test_opengl.c -lopengl32 -lmingw32 -lSDL2main -lSDL2 -lglew32
  4. profit.

How to get pretty latex-style documents in Microsoft Word

Posted: 2015-09-15. Modified: 2015-12-21. Tags: Windows, practical, howto.

follow guide at

in particular, start with the template there. latin modern math computer modern unicode fonts latin modern fonts

make sure you print to pdf using something like cutepdf, DON'T USE word's export feature.

Java vs Lisp

Posted: 2015-09-15. Modified: 2015-12-21. Tags: LISP, Java, Opinion, programming.

Java is the best for other people to understand your abstractions…

  • with the exception of poor data-structure initializers.
    • but you can get around this pretty easily by writing fclever initializers
  • Excessive OOP considered hazardous
  • Java's static typing provides an excellent source of computer-checked, always up-to-date documentation.

Lisp is the best for creating new abstractions quickly…

  • but lack of static typing means its sometimes difficult to figure out how to properly call code, etc…

Self Documenting Code

Posted: 2015-09-15. Modified: 2015-12-21. Tags: Opinion, programming.

Code should be, to a reasonable extend, self-documenting to a proficient programmer with reasonable command of the basic platform/ language. Dependency on libraries/frameworks can either help or hinder this goal.

If the usage of the library is clearly obvious from how the library is used in the program, then the program is still self-documenting.

On the other hand, if the library/framework requires extensive knowledge about it in order to understand its usage, then the code has become NOT self-documenting. If support for the library is ever dropped, you may regret your dependency on its arcane format.

On Abstraction

Posted: 2015-09-15. Modified: 2016-01-06. Tags: programming, philosophy, Opinion.

The difference between the right abstraction and the wrong abstraction is a huge difference in simplicity and clarity.

"I do believe that bulk, in programming or writing, can sometimes be an inverse measure of clarity of thought." – Leland Wilkinson, The Grammar of Graphics

bloatware reflects design-by-committee and sloppy thinking.

propositional logic vs predicate calculus

A programming problem can be described as a set of


and requirements.

Every programming problem has an infinite number of solutions

no-free-lunch theorem

A hope for quality software

Posted: 2015-09-15. Modified: 2016-01-06. Tags: Opinion, programming, philosophy.

I believe that if something is ever good, in a complete sense, then it will always be good. Human nature does not change, and our core needs change very little. If a meal was good 2000 years ago in Jesus' time, I think we would still find it good today.

One thing that bother s me about software development is that the field is often incredibly fad-driven. People write code, and two or three years later people think they need to rewrite everything to interface with whatever the new hotness is. Look at the state of javascript libraries/frameworks for a prime example of this code churn.

Is it possible to write good code? I think that if you target the right abstractions, then it most definitely is. And one example of this is the long-term success of the Netlib libraries, developed continuously for over 40 years as high quality linear algebra tools.

"Math has a long shelf life".

Software Programmers are like Doctors…

Posted: 2015-09-15. Modified: 2015-12-21. Tags: Opinion, programming.

They must diagnose and treat complex problems every day. But the difference is:

for doctors, the platform stays the same.


Is python pseudocode?

Posted: 2015-09-15. Modified: 2015-12-21. Tags: LISP, Opinion, programming.

People often state that python is the most similar programming language to pseudocode (what you write if you are trying to convey a piece of software to other humans rather than a computer). I've translated numerous pseudocode algorithms from books into various languages, and I agree that python often makes this process natural.

However I think an argument can also be made for LISP as the most "pseudo-code" like language. Perhaps while Python has the greatest surface similarity to pseudocode, LISP has the greatest actual similarity to pseudocode.

Why do I claim that LISP is similar to pseudocode? It's appearance is often rather different, after all.

I make this claim because of the intrinsic linguistic flexibility of a language supporting structural macros. The power of pseudocode is not just that it doesn't conform to a particular bracketing convention or function naming convention – the power of pseudocode is that you can introduce arbitrary code constructs, and explain them to your readers later on.

For example, consider the "with-redeclarations" construct, which rebinds all the functions executing within it. Lisp is MUCH closer to the ideal of the programmer being able to create arbitrary constructs than python is, and there are many instances of where you could imagine a way of thinking about a problem in pseudocode and translate the idea approximately into lisp, but have to rework it completely for python.

Therefore I conclude that while python does often look very similar to pseudocode written in a book, lisp is in a way also very similar to pseudocode because you can dream up very flexible code constructs just as you would if you were explaining a problem to someone with no fixed programming language.

Turing Machines are Overrated

Posted: 2015-09-15. Modified: 2016-01-06. Tags: programming, philosophy.

Constraints of runtime environments mean that not all turing-complete languages are equally powerful. Much of computing is pushing electrons over wires, not performing symbolic manipulation in the Turing sense. Therefore Turing equivalence of two languages does not necessarily imply that you can perform the same tasks in both of them – one may have drivers written to communicate directly with your gpu, while the other doesn't, for example.

Besides running "algorithms", computers can also interact with their environment. The Turing machine model models everything that can be done with the former capability, but nothing that can be done with the latter. This is a massive omission, and of course puts a lie to the "idea" that all programming languages / runtime environments / computers are equivalent. If computer A has freely available networkable features, while computer B is a strictly self-contained "algorithm" device, then there is an entire world of things you can activate or interact with with computer A which you can't with computer B.

Atom Feeds: