Computer programming is an art?

Not again. Computer programming is not an art!

The output of a computer program may happen to be a piece of art. But the input to a computer which is a program SHOULD NOT be a piece of art! The input to a computer needs to be very discrete and should not be vague/subjective like an art. These programs may be very ugly to look at too! Computers are not humans and they don't mind if instructions to them look ugly to humans.

Moreover, computer Languages are not supposed to be art too! Programmers need to understand very accurately(not subjectively) what other programmers have written. It is not about art, it is all about clarity and unambiguity.

And I think these computer Languages should NOT be called "languages". They are not languages, they are simply abstracted instructions to the computer. Of course few of them realized that early direct instructions to the micro-processors are not going to fly in long run. So they started abstracting these low level instructions. But even after these revolutionary computer "languages" set in, they are not like the languages we humans use. And actually these "languages" should never be like regular human languages. Some computer scientist must have taken things easy and declared that these mechanical instructions are also language in a philosophical way.

We should never write poetry in computer "languages", they are not meant for that.

Static typing and program generation

A lot of people dislike static typing for "human" reasons. They feel constrained.

I like static typing because it is mechanical. It is constrained. It is discrete. You know where I am going?

The more people work/improve on static typing the more powerful the compilers become. The more a type checker understands contraints the easier it become to generate programs from programs.

If I failed to convey through this article then it means my thought process needs static typing. :)

The "regular" program is just a subset of overfitted hypothesis

In our "regular" programming scene the programmer knows all combinations of input/output and the program is "deterministic". If the programmer forgets about a combination, it leads to a bug. :)

If the input/output dataset is known exhaustively and is free of noise then this learner overfits/memorizes all instances. This can be seen as "deterministic" use-cases, which I mentioned above. In other words if you think like a tester and are aware of all input/output instances then you don't need to write code explicitly.

Of course, I am not talking about the efficiency of such an outcome here. ;)

Common Problem solving with fp and oop ways

The fundamental basis of common problem solving is to split a problem into smaller problems, smaller problems with one angle/factor/context at a time.

Then try to solve each one of them in seclusion, avoid mixing contexts as much as possible while solving them.

Now once they are solved individually compose them back to get the grand final solution. It will work if the contexts and the solutions both are composable.

Even with my limited knowledge of functional programming concepts I can see the above scheme fitting it nearly well. While solving it FP way I am focussing exactly on the behavior and the solution. Composition of smaller solution units as functions are deeply engrained in the paradigm. I have just one entity to worry about while composing: function/behavior. Things tend to be precise. Although the learning curve is sharp it tends to fall in place sooner or later.

Now that I have been exposed to little of FP, I have started to realise where object-oriented is not working. With that of mainstream object-oriented concepts, I start with the classes. The splitting of the problem and appearance of classes look cool and encouraging. Things look great and beautiful during the splitting phase. But when the time comes to compose the solutions back to the big picture, it tends to start getting ugly. I think the main reason behind this hurdle is that now we are trying to compose the solution at two levels: class and behavior. If I focus on class composition then the behavior tends to either underfit or overfit the desired solution. If I focus on the behavior composition then the classes start to look mixed and weird. Statefulness of the classes add another level of complexity. So now we have to deal with three types of complexities at a time.

Scala is trying to bridge the gap with its hybrid approach, but have you looked at the trio of class/trait/object? They are so hairy, full of details, so much detail! As expected the functional part is hard anyway.

The contemporary programmers like me are going through so much of flux, confusion, trial and errors and brain bending phases. But it is fun of course. Let the wheels keep rolling. :)

Programming language not based on boolean algebra

Programming languages are designed to be executed by a machine which understands Boolean Algebra. Naturally to express an idea in these programming languages one will have to totally unambiguous. Encapsulation and Abstraction concepts of prgramming languages try hard to hide or abstract the context in which the programmer tries to express something. But sooner or later it gets very complex.
Although I have very limited understanding of Fuzzy logic and similar mathematical/statistical concepts, but can we develop some programming language which is based on these foundations rather on Boolean Algebra? Or is it already there?
What I am vaguely imagining is a platform:
1. Is a composition of context bound expressions.
2. Would start with very contextual expressions and assume that they are correct and totally discrete and unambiguous.
3. Working towards the common goal of the program, when these expressions interact with others then there respective contexts should be corrected so that they make sense to each other.
4. The expressions remain the same and aren't corrected. The contexts are corrected.
5. It has to be iterative and evolving.
6. Not sure if the contexts should be aware of the bigger goal of the program. How will the contexts and their corrections align towards the main objective of the program?