zyxzevn

Because of the excessive growing corruption in the EU, their politicians have decided to restrict all opposition. This corruption is hidden behind double-speak, demonization and censorship. Even putting people in prison who talk about the crimes that they endured.

Instead of using the criticism to improve the system, the corrupt system starts to attack and forbid the criticism.

I see a lot of complaining from small companies and startups. The taxing system is slowly becoming communism (I have no better word). And they also are stopping farming, based on bad ideas.

I tried to get into fundamental research, but disliked the burocratic approach in Dutch universities.

Big Brother is always right!

Why is this a question on Hacker News? Are many people struggling with this?

The problem is when certain (mental) models are important to a community or science specialization. When these models fail, the community will often enforce the model and censor the opposing facts. I have encountered several such conflicts.

Scientists are still humans. Individual people may be curious and be open to some questioning. But thy find it difficult to discuss such things in the open. It is like a religious dogma.

One example is the model of "colliding magnetic field lines", which is a concept not possible in electron-magnetism (my own expertise). But astronomers use this concept to describe plasma lines that collide with each other on the sun. They call it "magnetic reconnection". I can discuss this problem within communities that know electromagnetism, but not with astronomers. The confusion comes from their model (magnetohydrodynamics) that plasma always follows magnetic field lines. And if plasma collides, so must also the field lines. But in reality (and according tot he inventor of the model, Alphen) the model describes a very special case.

With a language like Forth, you know that you can use a stack for data and apply functions on that data. With currying it you put functions on a stack instead. This makes it weird. But you also obscure the dataflow.

With the most successful functional programing language Excel, the dataflow is fully exposed. Which makes it easy.

Certain functional programming languages prefer the passing of just one data-item from one function to the next. One parameter in and one parameter out. And for this to work with more values, it needs to use functions as an output. It is unnecessary cognitive burden. And APL programmers would love it.

Let's make an apple pie as an example. You give the apple and butter and flour to the cook. The cursed curry version would be "use knife for cutting, add cutting board, add apple, stand near table, use hand. Bowl, add table, put, flour, mix, cut, knife butter, mixer, put, press, shape, cut_apple." etc..

Physics is needed to fully understand the demolition of 3 towers..

While skeptical, he did not have much skepticism against mainstream theories.

I think it needs another item in the list: For any theory/ hypothesis: how well does it stand against the null-hypothesis? For example: How much physical evidence is there really for the string-theory?

And I would upgrade this one: If there’s a chain of physical evidence (was argument), every link in the chain must work (including the premise) — not just most of them

And when breaking these items do not mean that something is false. It means that the arguments and evidence is incomplete. Don't jump to conclusions when you think that the arguments or evidence is invalid (that is how some people even think that the moonlanding was a hoax).

"The oil must flow"

what about a smart lamp?

I used "Open Recursion" in many large (ObjectPascal / C++) projects. With simple interfaces, a large project becomes a collection of smaller components. I noticed many programmers do not understand it. Pure OOP languages (like Smalltalk or Ruby or Scala) are the best languages to understand how it could work. They usually have closures where other languages would have "patterns".

The problem is that the components are often connected to different interfaces/graphs. Components can never be fully separated due to debug, visualization and storage requirements.

In non-OOP systems the interfaces are closed or absent, so you get huge debug, visualization and storage functions that do everything. On addition to the other functionality. And these functions need to be updated for each different type of data. The complexity moves to a different part. But most importantly, any new type requires changes to many functions. This affects a team and well tested code. If your product is used by different companies with different requirements (different data types), your functions become overly complex.