Blog -- Page 3

There are two common ways of going about defining a graphical user interface.

1. Declarative UI.
   1. You adapt a markup language like HTML or XML, possibly in combination with a layout language like CSS, to define the identity and basic placement of widgets and controls.
   2. You traverse your declared UI using a real programming language like Javascript in order to add functionality and advanced UI features.
   3. This approach has been adopted by frameworks such as AngularJS, and QT+QML, and is the standard approach for Android UI development.
2. Programmatic UI.
   1. You create and lay-out the elements of the UI directly in a programming language. While you may still achieve separation of concerns by delegating UI creation and layout to a dedicated "View" object, all actions necessary to construct the UI are programmatically guided instead of declaratively specified.
   2. All older UIs used this approach, and it is commonly used today to construct UIs for a vast variety of desktop frameworks and can also be used to manipulate the web DOM.
   3. Swing, SWT, GTK, QT, is an option for Android.

Is one approach better than the other? What are the upsides and downsides of each approach?

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.