With the trend in functional programming up, I noticed a new programming language called "coconut" that implements functional programing "style". This is written on top of "python", the coconut language scripts are compiled and translated to python.

For e.g, this factorial coconut program, will be translated to a valid python program.

def factorial(n):
    """Compute n! where n is an integer >= 0."""
    case n:
        match 0:
            return 1
        match _ is int if n > 0:
            return n * factorial(n-1)
    else:
        raise TypeError("the argument to factorial must be an integer >= 0")

You can notice the pattern matching style in the above program, which is not a syntax in Python. This program will then be converted into a valid python program.

Great many details can be found in the coconut-lang website.

Found this introductory post on core functional programming concepts dealing with the subject succinctly. It is easy to approach functional programming, if we can recognize the following concepts held true by all the functional programs, and languages facilitating them.

1. Functions are Pure

   • No side-effects, like printing something from the function.

   • When called with the same input, will always return the same output. We take that for granted, isn't it?

2. Functions are first-class and are of higher order.

   • Treat function names as variables.

   • Toss function (names) as an argument to a function, and as a return value from a function.

3. Variables are immutable.

   • Forget mutating variables in a program. If you want an updated value, create a new variable. When you are getting started with programming, you feel this is questionable. With experience under your belt, you start to prefer immutability of variables.

4. Functions have referential transparency.

   • It follows from functions are pure requirement. The referential transparency requirement is about substituting the function call with return value, wherever the function is called, should not change the state of the program.

5. Lambda Calculus

   • The mathematics behind functional programming. Take arguments and have a return valued. When evaluating multiple arguments, the function is evaluated one argument at a time, with result send to next one-arg-less function, kind of a tail-recursion. This concept is called currying.

I stumbled upon a Explain Like I am Five Story which dealt with the rationale behind punishments. The topic of punishments is a complex one and needs balanced thinking. The author elucidated many reasons for which punishments are administered in society. We see the trends of those in both online and offline societies.

Punishments are administered for one of the following reasons.

• Incapacitation

Is stopping somebody from doing an unacceptable behavior in the society again.

• Restitution

Is getting something back for the victim of somebody who misbehaves, to compensate them for that which they've been deprived by the offender. Like charging fine and using it for taxes.

• Retribution

Is like feeling of justice that deprived might get. Many of us think, this is the primary purpose for punishment. This is non measurable, but often paves way to other measurable impacts like incapacitation, restitution etc.

• Rehabilitation

The purpose is to give the offender, time to reflect on the wrong doing, possibly empathize with the one affected.

• Deterrence

Is about reducing the likelihood that misbehaviour will occur in the first place. The punishment is more for a warning to prevent a socially unacceptable behavior.

Many a social regulatory policies can be mapped to above concepts of negative reinforcements to prevent any undesirable outcomes.

This post is a short discussion on the Leslie Lamport 's paper "Teaching Concurrency".

Lamport's basic premise is that understanding the system the most important part, and engineers often muddy their understanding with implementation details as soon as they start talking about programming languages suitable for concurrency.

He even challenges engineers to come up with the solution for concurrency problems without using "semaphores", "monitors", or any other construct that were invented and provided as a tool. Using those, he says, is like using the 'sort' to routine the language to implement a sorting algorithm.

The modern field of concurrency started with Dijkstra’s 1965 paper on the mutual exclusion problem. For most of the 1970s, one “solved” the mutual exclusion problem by using semaphores or monitors or conditional critical regions or some other language construct. This is like solving the sorting problem by using a programming language with a sort command. Most of your colleagues can explain how to implement mutual exclusion using a semaphore. How many of them can answer the following question: Can one implement mutual exclusion without using lower-level constructs that, like semaphores, assume mutually exclusive access to a resource?

Lamport's approach to problem solving suggests, we need to think of computing problem as series of states instead of series of steps. I think, series of steps tend to give some linearity the approach, while series of states tend to indicate that sub-parts of the system can have multiple states and the next state each sub-part can take only depends upon the current state and action that leads the state transition to the next state.

It is more useful to think about states than sequences of steps because what a computing device does next depends on its current state, not on what steps it took in the past.

To describe a computation we need to describe a sequence of states. More often, we need to describe the set of computations that can be produced by some particular computing device, such as an algorithm. There is one method that works in practice: describing a set of computations by

1. the set of all initial initial states and

2. A next-state relation that describes, for every state, the possible next states that is, the set of states reachable from that state by a single step.

On computational thinking.

How should we describe computations?

Most computer scientists would probably interpret this question to mean, what language should we use? Imagine an art historian answering “how would you describe impressionist painting?” by saying “in French”.

Programming and hardware-design languages don’t help an engineer understand what problem a system should solve. Thinking of computations as sequences of states, rather than as something described by a language, is the first step towards such understanding.

Lamport also describes in great details about importance of problem specification. Sometimes, when the problem is specified clearly and understood problem, the solution becomes easy. Most of our struggles seems to be with coming to grasp the problem specification.

The great contribution of Dijkstra’s paper on mutual exclusion was not his solution; it was stating the problem. (It is remarkable that, in this first paper on the subject, Dijkstra stated all the requirements that distinguish mutual exclusion from fundamentally simpler and less interesting problems.)

On concurrency, itself

He gives an example of concurrency problem that according to him is "trivial". It took me some reading to understand the problem. StackOverflow.com certainly helped.

Once an engineer understands what a computation is and how it is described, she can understand the most important concept in concurrency: invariance. A computing device does the correct thing only because it maintains a correct state. Correctness of the state is expressed by an invariant—a predicate that is true in every state of every computation.

Invariance is the key to understanding concurrent systems, but few engineers or computer scientists have learned to think in terms of invariants. Here is a simple example.

Now, the problem

Consider N processes numbered from 0 through N − 1 in which each process i executes

and stops, where each \(x[i]\) initially equals 0. (The reads and writes of each \(x[i]\) are assumed to be atomic.)

This algorithm satisfies the following property: after every process has stopped, \(y[i]\) equals 1 for at least one process \(i\) .

It is easy to see that the algorithm satisfies this property; the last process \(i\) to write \(y[i]\) must set it to 1. But that process doesnt set \(y[i]\) to 1 because it was the last process to write y.

What a process does depends only on the current state, not on what processes wrote before it. The algorithm satisfies this property because it maintains an inductive invariant.

Explanation

The explanation on how \(y[i]\) equals for 1 at least one process \(i\) goes like this.

1. The \(x_s\) model the following behavior: \(x[i]\) is 1 if and only if the process \(i\) has already run.

2. After all processes have completed, all \(x_s\) are thus set to 1.

3. The \(y_s\) are a bit trickier: \(y[i]\) is set if \(x[i-1]\) was set, that is, \(y[i]\) is 1 if and only if the predecessor of \(i\) had already run when \(i\) was doing its write to \(y\).

I essentially to had resort to StackOverflow.com post author's explanation to completely understand this.

The program invariant is:

If a process has set \(y[i]\), it must already have set \(x[i]\) to 1. This is true regardless whether \(y[i]\) is set to 0 or 1.

Proving this invariant is quite easy: In the beginning, none of the \(y_s\) is set, so it holds trivially. During program execution, each write to \(y[i]\) is sequenced after a write to \(x[i]\). Therefore the invariant also holds for every step of the program afterwards.

The further reasoning goes like this.

The last process to finish sets \(y[i]\) to 1 because, by definition of being the last process, its predecessor must have already finished execution at that point (ie. its y value is already set).

Which means, because of the invariant, its \(x\) value (which determines the last process' \(y\) value) has to be 1.

The alternate way to look at this problem can give some intuitive understanding too.

You cannot find an execution order in which all \(y_s\) are set to 0. Doing so would require all processes to execute before their predecessor. However, since our processes are arranged in a ring (that is, if I follow the predecessor chain I will eventually end up at my starting point again), this leads to the contradiction that at least one process must have finished executing before it wrote to \(y\).

To understand this concurrency problem, it requires some notion of syntax, a prior understanding of proving hypothesis, and possibly discussing the problem and solution.

Trying to understand itself, I guess, is a progress.

Looks like Edison used TODO list too.

This article on openculture has a snapshot of his todo list from year 1888.

These were his 108 things he wanted todo.

1 - Cotton Picker

2 - New Standard Phonograph

3 - Hand turning phonograph

4 - New Slow speed cheap Dynamo

5 - New Expansion Pyromagnetic Dynamo

6 - Deaf Apparatus

7 - Electrical Piano

8 - Long distance standard Telephone Transmitter which employs devices of recording phonogh

9 - Telephone Coil of Fe [iron] by tt in Parafine or other insulator

10 - Platina Point Trans using new phono Recorder devices

11 - Gred Battery for Telephones

12 - * Long Distance

13 - * Phonoplex

14 - * Jump Telegraph

15 - * Voltmeter

16 - Improved Magnetic Bridge for practical work

17 - Motograph Mirror

18 - * Relay

19 - * Telephone practical

20 - Artificial Cable

21 - Phone motor to work on 100 volt ckts

22 - Duplicating Phono Cylinders

23 - Deposit in vacuo on lace, gold silver also on cotton molten chemical compound of lustrous surfaces to imitate silk also reg plating system

24 - Vacuous Ore milling Large Machine

25 - Magnetic Separator Large

26 - Locking material for Iron sand

27 - Artificial Silk

28 - Artificial filiments [sic]

29 - New [illeg.]

30 - Uninflammable Insulating Material

31 - Good wax for phonograph

32 - Phonographic Clock

33 - Large Phonograph for Novels, etc.

34 - Pig Iron Expmts with Electricity + Magnetism

35 - Malleablizing Cast now in Vacuo

36 - Drawing fine wire

37 - Joy phonograph for Dolls

38 - Cable Motograph

39 - Very Loud Motograph telephone with 1/3 siz phonogh motor.

40 - Magneto telephone with actual contact end magnet compression of an adjustable rubber press as in new phones

41 - Snow Compressor

42 - Glass plate water ore repeator

43 - Tinned faced [illeg.] for Stove Castings

44 - Refining Copper Electrically

45 - Quad neutral relay

46 - Cheap low induct Cop Insulating material for Lead Cable people

47 - Constant moved for nonfoundry

48 - 200 volt 20 cp lamp

49 - Cheap [illeg.] Indicator

50 - Recording Valt Indicator

51 - Box balancing System

52 - Alternating Machine + Transformer

53 - Sifua Surface Switches

54 - Vulcanizing [illeg.] African Rubber adullement

55 - Platinum wire [illeg.] cutting Machine

56 - Silver wire wood cutting system

57 - Silvering or Coppering bathing cloth in Vac for durability

58 - S Mater attend own with new devices for c speed

59 - Expansion mirror platwire in vacuo

60 - Photoghy

61 - Photoghy by camping heat after central points

62 - Boron fil.

63 - Hg [mercury] out of Lamp

64 - Phonaplex Repeater

65 - Squirting glass sheet tube etc. Nickel [illeg.]

66 - Artificial Mother Pearl

67 - Red Lead pencils equal to graphite

68 - India Ink

69 - Tracing Cloth

70 - Ink for blind

71 - Fluffy Incandescent Burner for gas

72 - Regenerative Kerosene Burner

73 - Centralized arc in arc Lamp

74 - Cai-[illeg] Tesla arc lamp test

75 - Strengthening alternating cli by sternt Dynamo

76 - ERR Cont [illeg.] reducers

77 - Electroplating Machines for Schenectady

78 - Condenser Transformer

79 - Sqr ft difraction gratings in silver by 5000 [illeg.] tool special [illeg.] lathe for ornamental purposes

80 - Photo Scant [illeg.]

81 - Cheap plan produce Mimeograph surfaces

82 - Miners battery + lamp

83 - Sorting Coal from Slate Machine

84 - Butter direct from Milk

85 - Burning asphalt Candles by high chimney

86 - Magnets RR signals

87 - Soften [illeg.] of books transfer to Cop plate + plate to [illeg.] matrix

88 - Telephone Repeater

89 - Substitute for Hard rubber

90 - Artificial Ivory

91 - Soften Vegetable Ivory to press in sheets

92 - Various batteries on [illeg.] Type

93 - Revolving Thermo

94 - Caller Indicator for Jump Telegh

95 - Marine Telegraphy

96 - Long distance speaking tube filled H20 2 dia pressure

97 - Lend plate battery for modifying attending Current

98 - Two revolving bands in battery Lead faced press in liquid close together + out into separate chambers to [illeg.]reduce by gas the other

99 - Siren phonogh

100 - Perm mag like an electromag of [illeg.] hand steel high polish separately magnetized + forced together powerfully[illeg.]

101 - Telephone working more [illeg.]

102 - Eartubes formed crescent [illeg.] wire

103 - Long strip 50 cp carbon under stress [illeg.] for

104 - Cheap Voltmeter

105 - Chalk Battery

106 - Dynamo or motor long tube in long magnetic field top bottom contacts forcing water through generator current by passage.

107 - Thermo battery slick Copper oxidized then plated over surface oxide nailed to make good contact [illeg.]

108 - Disk Phonogh

Setting up a TeamCity Server on Mac as a personal agent was very easy.

1. Run TeamCity server

#!/bin/bash

PATH_TO_DATA_DIR=/Users/senthil/teamcity/data
PATH_TO_LOGS_DIR=/Users/senthil/teamcity/logs
PORT_HOST=8111

docker run -it --name teamcity-server-instance  \
    -v $PATH_TO_DATA_DIR:/data/teamcity_server/datadir \
    -v $PATH_TO_LOGS_DIR:/opt/teamcity/logs  \
    -p $PORT_HOST:8111 \
    jetbrains/teamcity-server

The teamcity server is accessible now at http://127.0.0.1:8111

2. Setup a reverse proxy to access that locally.

$ cat /etc/apache2/vhosts/teamcity.local.conf
<VirtualHost *:80>
    ProxyPreserveHost On
    ServerName teamcity.local
    ProxyPass / http://127.0.0.1:8111/
    ProxyPassReverse / http://127.0.0.1:8111/
    LogLevel debug
</VirtualHost>

3. Setup your /etc/host to point http://teamcity.local to 127.0.0.1:8111

$ cat /etc/hosts |grep teamcity
127.0.0.1   teamcity.local

"Myth of a Strong Leader" by Archie Brown is from Bill Gates book recommendation. Pause a moment and think about the title. Every now and then you will hear something saying "Strong Leader", you never hear people saying "we need a weak leader".

The book's title is that, the concept of "Strong Leader" is a myth. According to the book, an effective person works by collaboration, flexibility and never becomes a center point of decision making.

• Review link

In this short TED talk video, Salman Khan pitches for mastery based learning. It means that if there is a bar (say 100%) for mastery, then the variable in the learning should be how many hours one spends to attain that bar. Until the bar of 100% mastery is attained, the student should not be considered the master of the subject, and should not just move on the next class/course.

We adopted the current system because it was impractical for mastery based learning previously, but given our computational resources, mastery based learning is very much practical today.

Parkinson's is not curable (yet). Folks with Parkinsons will have a progressively degenerating muscular order. But I have seen folks with Parkinsons live for very long time with only slight impairment.

It's well knowm it is a brain disorder and caused due to stress. There is a recent news (http://www.bbc.com/news/health-38173287) that it might due to bacteria in the gut. If it were due to bacteria in the gut, then the cure is near.

I wrote a short technical howto on installing Adminer on Mac. If you use Databases on Mac, give this a try:

https://github.com/orsenthil/adminer-on-mac