Comments on HomePage


Keene Murals

PoemMantra Template

<div id="poemMantra">
    <img class="poemMantraImg" src="">
    <div class="title"><span>Be Open</span></div>
    <div class="poem"><span>
... just attending to the now,<br>
with no purpose,<br>
no method,<br>
nothing to attain ...
    <div class="mantra"><span>No Goals!</span></span></div>                  


Be Open
... just attending to the now,
with no purpose,
no method,
nothing to attain ...
No Goals!

Halfway - between the supergalaxies and the fundamental particles - between the Hubble Time and the Planck Time - we sit, and think, and care for one another


check out and esp.

Wikipedia:Shardik - re-read and quote?

This is my LIFE.

There was a day that was so much fun.
There was a day something good happened.

There was a sad day, though it wasn’t about me.
Ah... and a sad day that was about me.

There was a day that was depressing.
And a day that was so boring.

That day,
this day,
that time,
this time.

Whatever the kind of day,
it was one day of my life.

That day, this day, that time, this time.
Whatever the kind of day,
it was a good day to be alive.

This is my LIFE.
I can’t trade it with anyone.
These are my days,
and they belong only to me.

This is my LIFE.
This is my BOOK.

Hobonichi Techo

Noam Shpancer

[1] "Decision-Making for Sound Mental Health: 3 Useful Principles" 6 Feb 2019

flexibility over rigidity, compassion over cruelty, approach over avoidance

and [2] "Are We Being Mindless About Mindfulness?" 13 Mar 2019

"A paraprosdokian (/pærəprɒsˈdoʊkiən/) is a figure of speech in which the latter part of a sentence, phrase, or larger discourse is surprising or unexpected in a way that causes the reader or listener to reframe or reinterpret the first part. It is frequently used for humorous or dramatic effect, sometimes producing an anticlimax. For this reason, it is extremely popular among comedians and satirists.[1] Some paraprosdokians not only change the meaning of an early phrase, but they also play on the double meaning of a particular word, creating a form of syllepsis."

"Paraprosdokian" comes from the Greek "παρά", meaning "against" and "προσδοκία", meaning "expectation".

-- z 2019-06-28 08:59 UTC

unlocked the wiki on Monday evening 2019-07-15 ... let's see how long until (if?) spam appears ...

-- z 2019-07-15 22:15 UTC

quote fragments from "Think in Math, Write in Code" thread [3]

Math has more aspects than just logical deduction via mechanical rules. Math also has an aesthetic aspect that guides people to find elegant, powerful solutions within the space defined by the mechanical rules. There may be many paths of deduction from point A to point B, which are all mechanically equally valid. But from the human point of view, they have different value. Some will be simple and easy to understand; others will rely on ideas from one or another realm of math, making them friendly to people who understand those ideas. Some will suggest, to the human brain, analogies to other problems. The mathematical validity of the argument is judged according to whether it correctly follows the mechanical rules, but all other aspects are judged by aesthetics and intuition and ultimately by how the solution is received and utilized by other mathematicians.
If the only aspect of mathematics that you bring into programming is logical deduction by mechanical rules, then I doubt it will help, except for rare cases where you prove or disprove the correctness of code. If, on the other hand, you bring over the aesthetic concern, the drive to make painfully difficult ideas more beautiful (ergonomic) for human brains, then it will help you make your code simpler, clearer, and easier for others to work with. ...


That's true to a certain extent, but math and programming share the property of being built up from logical building blocks that are combined in strict logical ways. Law and philosophy are built on language and culture; physics is closer but is empirical. Math and programs are built from logic, and this gives them more of a common aesthetic sense.
For example, in law or philosophy, repeating the same argument multiple times, adapted for different circumstances, can give it weight. In math and programming, the weight of repetition is dead weight that people strive to eliminate. In law and philosophy, arguments are built out of words and shared assumptions that change over time; in math, new definitions can be added, and terms can be confusingly overloaded, but old definitions remain accessible in a way that old cultural assumptions are not accessible to someone writing a legal argument.

In physics, the real world is a given, and we approximate it as best we can. In math and software, reality is chosen from the systems we are able to construct. Think of all the things in our society that would be different if they were not constrained by our ability to construct software. Traffic, for one — there would be no human drivers and almost zero traffic deaths.

Where programming differs from math is that math is limited only by human constraints. Running programs on real hardware imposes additional constraints that interact with the human ones.

and by

I see math as the language of thinking. Math doesn’t really have a domain beyond: how do we think, how do we know, and how do we communicate our knowledge. The progression of mathematics has been the systematic removal of domain. Numbers are widely applicable because they are very abstract and devoid of domain, and they are one of the least abstract things in mathematics.
I agree with your gist, there are lots of things where studying that thing is virtuous beyond its direct application. But also, I’d contend that thought is the subject of mathematics and not just a virtuous side-effect.

and by

Mathematics and programming are strongly related more than most people think. How did he solve it? Using probability theory and sets.

It's not just games, cryptography, finance, signal processing, compression, optimization, and AI that require mathematics, tons of programming does most people just don't realize it and brute force their way to a solution.

Lot's of real world problem can be solved with algebra, calculus, Boolean algebra, linear algebra, geometry, sets, graph theory, combinatorics, probability and stats. What typically happens is most programmers are giving a problem, and what do they do? They start thinking in code. How did we solve problems before computer?

Apply that kind of thinking, then solve the problem with mathematics. Your code will often be much smaller and dense. Sure, dealing with output and input doesn't require you to write mathematical code, but the core of your problem can often be solved with some mathematics.

and suggests to see for explanation of AlphaGo

and comments

> Is this really a common thing? How can you try to implement something without first having had thought of the solution?
Unfortunately, it's incredibly common.

The result is always almost a mess. Functions that are never called, parameters that are never used, as they discovered their mistake as they were coding but then never went and cleaned up the stuff they don't use anymore. Broken logic, poor performance. Functions with a mess of loops and if statements, nested like 10 indents deep.

You can tell by looking at code if they were making it up as they were going versus implementing a solution they had thought through before starting coding. It's painfully obvious.

When you try to solve your problem by coding, I think you are forced to take a myopic view of only subsets of your solutions and it's near impossible to step back at this point and come up with a nicer, more abstract and probably more concise solution. The solution comes out spikey.


The problems we're solving when building software happen simultaneously at different levels. Some are best solved by prototyping. Others are best solved on a whiteboard. The trick is correctly identifying the problems, and then knowing which layer they belong to. If you try to code up a prototype for a design problem, you'll most likely waste a lot of time and not reach any useful conclusions in the end (or end up shipping the broken thing). If you try to whiteboard a coding problem, you can get stuck forever drawing things, with no result to show for it.
In my experience, the problem levels go differently than one could naively expect. Data structures, abstractions, module interfaces - all problems dealing directly with code - are best solved first on a whiteboard, where evaluating and iterating through them is cheap and effective. User interfaces, user experience, usefulness of a part of a program - things dealing with business and user needs - are best solved through prototypes, because you can't reasonably think through them on paper, you have to have a working thing to play with.


Yeah. It is easy to people with no university-level math background to think math is a deterministic, conscious effort to execute what are basically algorithms, like long division with pen and paper.
Whereas actually ”mathematical thinking”, like coming up with a proof, is an incredibly intuition-guided process, a parallel heuristic search in the solution space, a fundamentally creative endeavour. And as your intuition comes up with promising paths through the search space, you write them down, formalize them, probably discover some corner cases you have to handle, and either continue down that path or realize that it is a dead end and you have to backtrack.

At least to me, this process is incredibly similar to programming effort. You come up with subsolutions, formalize them, fix issues revealed by the formalization, carry on with the next subsolution or realize that approach can’t work after all, and come up with something else.


Opportunistic programmers develop solutions in an exploratory fashion, work in a more intuitive manner and seem to deliberately risk errors. They often try solutions without double-checking in the documentation whether the solutions were correct. They work in a highly task-driven manner; often do not take time to get a general overview of the API before starting; they start with example code from the documentation which they then modify and extend.

Systematic developers write code defensively and try to get a deeper understanding of a technology before using it. These developers took time to explore the API and to prepare the development environment before starting. Interestingly, they seemed to use a similar process to solve each task. Before starting a task, they would form hypotheses about the possible approach and (if necessary) clarify terms they did not fully understand.

with comment by

I've always thought of those two groups using different labels. The Code Artists and the Engineers. The Artists have a strong need to be creating to understand something, whereas the engineer has a strong need to understand before they can create. And those that believe the programming is not an art fall into the latter group.

leads to point to "Hackers and Painters" by Paul Graham, 2003

-- z 2019-07-20 10:09 UTC