Blog -- Page 4

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

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".

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

for doctors, the platform stays the same.

in software, THE PLATFORM KEEPS ON CHANGING!

Originally posted: 2015-09-15. Modified: 2015-12-21.

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.