Blog -- Page 3

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

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.

follow guide at http://blog.lnk.si/posts/fake-latex.html

in particular, start with the template there.

http://www.gust.org.pl/projects/e-foundry/lm-math/download/index_html latin modern math

http://canopus.iacp.dvo.ru/~panov/cm-unicode/download.html computer modern unicode fonts

http://www.gust.org.pl/projects/e-foundry/latin-modern/download latin modern fonts

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

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…

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.

Originally posted 2015-09-15/Modified 2016-01-06

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

preconditions

and requirements.

Every programming problem has an infinite number of solutions

no-free-lunch theorem