Ask HN: What concepts have you never truly understood? | Hacker News Reader

Ask HN: What concepts have you never truly understood?

85 pointsjportet179 comments

Is there a specific topic, concept, etc.. that no matter how many times you try to wrap your head around, you can't ever seem to get it? If you were in this situation, what would you do?

View on HN

No one seems to be answering the second question, so I'll take a crack at it:

When something just isn't clicking in my brain I move on from it! Then some time later (not a fixed time) I happen across it and read through it again with a fresh mind.

This has happened too many times for it to be a coincidence, that the 2nd attempt ALWAYS makes things click very naturally. It has happened with probability concepts such as Bayesian networks or HMMs, optimization algorithms like EM, Monte Carlo sampling, bootstrap, functional programming concepts like monads, C++ move semantics; the list goes on.

Whenever you're stuck, just take a break! And not a 30 minute coffee break but still at the back of your mind kind of break - completely forget about it and come back in a few days, a few weeks or even a month or 2 later

Excellent advice. In my experience it works only if you tried really hard the first time though, even if you failed.

Agreed. I've never really gotten into neural networks, most of the times I start but get distracted or bored/lost and suddenly enough a Vertiasium video pops up and about everything just slots into place, stuff you've glossed over or heard before just make sense. https://www.youtube.com/watch?v=GVsUOuSjvcg. Start at minute 4:00.

Indeed. I prefer going for a run or playing a sport as it completely shifts the focus of your mind as well as the body. I have also noticed that cooking can also be a good mind shifter.

College was immensely frustrating to me for this reason. You can’t just put it on the back burner for a few months (or even weeks): you have quizzes and exams coming up five days from now.

I’m probably a slow thinker, but there are so many concepts from my engineering textbooks that make perfect sense now that were baffling at the time. There’s something about studying those topics in a relaxed, low stakes environment that makes understanding them much easier.

Still don't have even the vaguest beginnings of a clue what the fuck a monad is, after reading 50 articles promising to make it simple, as well as their accompanying 500-comment HN threads. I suspect the real problem is that, as a C/C++/C#/ASM programmer, I lack concepts that are strict prerequisites, and people underestimate the importance and/or existence of those prerequisites.

What I did was I gave up and no longer click those articles.

This is very relatable :) A workmate and I have fun making variations of "A monad is just a monoid in the category of endofunctors!" and sarcastically suggest the other tries OCaml, Haskell, or Idris when something isn't going their way.

I've been pretty deep in to functional programming for years including implementing my own little lisp with macros and all that shit and I still couldn't confidently tell you what a monad is. I read those articles sometimes when I come across them and feel like I understand a little more of... something... and I mean I have some intuition for what they are but still I don't really get it and never have.

When you have some spare time write a function that returns a Maybe<Value, Error> and see what a pain it is to compose multiple of them.

Then, try store your programs state by passing it as a function argument to every function so it stays available for the lifetime of the program (no mutable state? This is basically what happens)

After realizing what a pain this is and wishing for boilerplate, look at the State monad. This is what did it for me :)

I don't see why I would ever want to do the first one in real life, when exceptions exist.

I'm honestly not even sure what function composition is, or why you would compose two functions instead of just explicitly making a new function that calls the two original ones.

The second one makes more sense because of the rumored bug-freeness of side effect free apps, but it seems like for that too, you'd need to understand a lot more than just monads.

Function composition is connecting the output of one function to the input of another. In math it is (f ∘ g)(x) = f(g(x))

Or in javascript:

function f(x) { return x + 1 }

function g(x) { return x + 2 }

f(g(1)) === 4

In functional languages like Haskell function composition is made easy, because functions can be partially applied. Partial application means that given a function that takes two arguments, I can call it with one argument and it will return a function that takes one argument which returns the result. Whereas in languages like javascript it is difficult because functions can have different numbers of arguments and there's no way to partially apply them or flip their arguments, so it is difficult to chain functions together. And because javascript functions aren't pure, they may not have any result which can be composed with other functions. In a functional language, functions are more like the functions in math. In most non-functional languages, functions are more like a procedure of commands. For example, the javascript function logMe(x) { console.log(x) } doesn't return anything. So it can't be composed functionally, and is not like a "real" function.

JavaScript has bind() on functions which works well enough. You can partially apply arguments, but I don't think you can project them to a different order.

JavaScript has closures. When you want to partially apply something(Which is technically never, because we would probably describe it in different words and think of it differently) we just make a new function.

When we want to "compose" two functions, there's f(x){return a(b(x))}.

It doesn't matter if the signatures are different, you don't need any nice logical idea of composition, you just explicitly build the new function that does what you want.

I would say that is a lot easier than real composition, because real composition requires you first learn to see and think in terms of patterns you would want to compose in the first place.

Also, function chaining doesn't use intermediate variables. Named variables are like free documentation. With composition you have to actually remember what you're doing. Making everything explicit makes it easier to comment what's happening.

Regular programming is to math as cooking is to chemistry. Functional brings the math back to programming. Math is useful but also hard.

In OOP, more often you're doing the equivalent of:

if crinkle(a(b(x,68), modes.FOO).bar.baz(9)): x = foo() else: x = wipe(7).bar()

And I think it's a lot nicer to just spell it out with meaningful variable names, instead of trying to compose it like an equation.

Not every step has a meaningful name. And usually you already have the name of the function. For example:

    let batter = mix(water, flour)
    let saltedBatter = add(salt, batter)
    let risenSaltedBatter = letToRise(saltedBatter)
    let bread = bake(batter)

on the other hand:

    let bread = bake(letToRise(add(salt, mix(water, flour)))

The first example leads to awkward names and useless variables. The second example feels cleaner to me. Interesting that you take cooking as an example: recipes usually don't name most of the intermediate steps, they describe the actions you take and the ingredients you use. Most recipes also use composition a lot. You start with your actions/functions (cut, cook, bake, dice, etc) and you do a recipe out of them. You don't create new "functions" (actions) specifically for each recipe.

Recipes are a lot closer to configuration DSLs than code though.

You have standard functions like bake and boil, and they don't tell you to use clean utensils or how to turn the stove on, because an cooking is basically just a few dozen standard functions, end condition rules, etc.

If you think of them as programs, the composition they use isn't the same as functional languages, because the individual steps are unstructured and there's no generalized abstract pattern defining what a RecipeStep is or what composing two of them means.

You wouldn't say add(flour(add(salt,empty))), you would say "add flour, salt, water, and yeast".

"add" can take either an ingredient or a list, and it's pretty encapsulated, since it dynamically selects a way to measure the ingredient based on what it is, what utensils you have, etc.

It could trigger dozens of unrelated code paths based on state, and probably includes error recovery.

Functional might be nice for implementing the internals of that add() function, but in OOP the idea seems to be that it's a pretty minor detail, since add() is only written once and rarely changed, but used millions and millions of times all over the world for a decade.

Usually when people talk about "the beauty of functional" I get the impression that they're not really doing a whole lot of "One really smart function that knows exactly what to do" level abstraction.

It seems like they'd literally be composing together their own variations of what "add" is, as needed from the raw findMeasuringStrategy and checkPantry functions instead.

I feel, in your example, that the first code block is infinitely more useful to the maintainer than the second. It literally tells the reader what each step is *supposed* to do.

That second example tells the reader that it is doing, which may or may not be what it was supposed to be doing.

As a maintainer, I prefer knowing that:

    (add(salt, mix(water, flour))

is supposed to result in a salted batter, which the first code block tells me but the second one does not.

My whole point is that sometimes intermediate steps don't have good names. I often have to apply multiple transformations to a collection, but only the first and last step have a name because the intermediate steps are just that. "salted batter" is not a thing, it's just a placeholder name because you needed a name. You will never use "salted batter", you'll only use ingredients and bread.

> You will never use "salted batter", you'll only use ingredients and bread.

For write-only code, sure, that's great.

It's irrelevant when I am tracking down a bug - the label 'saltedBatter' tells me what that intermediate result is supposed to be.

If, when debugging, I find that `add(salt, batter)` results in something else[1], using your convention it is literally impossible to tell that the value is supposed to be `saltedBatter`.

There is literally no way to tell if the intermediate values are correct. Maybe each caller in the composition chain can throw an Exception?

The point is, the variable names are helpful.

> but only the first and last step have a name because the intermediate steps are just that.

That describes the entire program :-)

In all seriousness though, it's because you intend to describe steps in the process that throwing away all labels for the intermediate steps makes sense.

You're describing verbs. We don't need to know the in-between verbs for a verb. When you call `driveTo()`, it is not necessary to know all the verbs involved in that action, it is enough to know that it will attempt a certain action.

Verbs answers the "what we are doing" questions.

Variable names answer the "Why we are doing it" questions - `saltedBatter = foo (bar(), baz);` tells the reader why foo is being called.

We don't even need to know the steps involved or even what the other variables (used as parameters) should be. Assigning the result of a function to a variable ensures that the maintainer knows if that variable ever holds the wrong value.

I think where a lot of this value (variable-names) is lost is in enterprise development - the names are never helpful, they're just a differently-cased version of the type. Like these gems I see daily:

    SomeClass someClass = foo();
    List<OtherClass> otherClassList = bar();
    ....
    return baz(someClass, otherClassList);

So, yeah, I see your point if all you ever see is enterprise-grade naming conventions. OTOH, if those above two lines were written as:

    SomeClass needle = foo();
    List<OtherClass> haystack = bar();
    ...
    return baz(needle, haystack);

you, as the maintainer, know exactly what that last line is supposed to do, and if it isn't doing that, then you know it's a bug.

Compare with this:

    return (foo(), bar());

Or, if you wanted descriptive function names:

    return (calculateResult(), userSubmittedList());

Brevity is not a virtue in programming languages and/or programs. It's probably why Haskell is still not even a rounding error as far as popularity goes.

[1] Maybe `doubleSaltedBatter`, in case an upstack caller used `saltedWater` in place of `water`, or perhaps `pepperedBatter` in case a caller switched out the salt for pepper.

> Brevity is not a virtue in programming languages and/or programs.

Real world Haskell code isn't the codegolf you are implying.

In fact, I think real world Haskell devs overcorrect and make code too verbose.

Also, "brevity is not a virtue in programming languages" is something I disagree with.

Walls of verbose code are just so damn mentally taxing. Especially hen you finish reading and saybto yourself "all that code just to do X?".

> Functional brings the math back to programming. Math is useful but also hard.

So is working with an edifice of unprincipled ad-hoc abstractions, but many seem to prefer pushing that debt on tomorrow them or others.

A function that can return a value or throw an exception is pretty similar to Maybe<value,error>

I'm not clear why the next function in the pipeline would need to know about the error rather than the caller, but that happens with promise chains too

Maybe this article will explain my point about errors a little, it also covers function composition, and I think is approachable. I guess the only advice I have for you (or anyone) with monads is to look at concrete examples first and not care about the theoretical bits. Intuition comes from use. Is it useful to know in non-functional languages? Probably not; you'll use them without realising and probably make them yourself without realising!

https://medium.com/swlh/monads-in-python-e3c9592285d6

> I don't see why I would ever want to do the first one in real life, when exceptions exist.

Exceptions usually aren't typechecked.

Lots of languages only let you throw stuff if explicitly declared.

Which ones? I'm not aware of any that has only checked exceptions, at least in the mainstream ones.

I remember one time I found an article that explained it. For a brief moment I thought i understood. But I didn't see what was in any way interesting about them, so that probably requires a whole other level of knowledge.

All I know is they contain values and you can pass them functions, and somehow by doing this you can write fully pure programs with supposedly fewer bugs, and Haskell programmers seem to not understand why this is hard.

One thing that made it difficult to me was that I didn't explicitly realize for a long time that there were two things to understand: what a monad is and why they are useful. Most explanations tell why it's useful, but it really clicked for me when I read through the book "Haskell Programming from First Principles" (Julie Moronuki, Christoph Allen) [1] and got to the monad chapter, which if you read the previous chapters explains really clearly what a monad is.

The way I understand monads: some data structure plus 2 functions, "return" and "join":

- "return": wraps something with the data structure. (no relation with the return keyword you are used to in most languages)

- "join": joins 2 layers of the _same_ data structures into one.

And that's it. It's just that simple what a monad is: in java it would be an interface with just these two methods.

Examples:

- "return" for List: takes a value and returns a List containing just that value.

- "return" for Maybe: takes a value and returns Maybe value.

- "join" for List: takes a List of Lists and returns a flattened List (2 outer layers joined).

- "join" for Maybe: takes Maybe Maybe value and returns Maybe value.

I think what makes these functional programming concepts hard to grasp most of the times is that communicating the boundaries of abstract concepts is hard in general, even if the concept itself is really simple, like a monad can be for a programmer.

As for why monads are useful, the explanations you can find online give a lot of examples. Just think of all the times you may have used flatmap for arrays: that's just map followed by the "join" for arrays, which is sometimes called flatten. The other operators you see used in haskell, like "bind" (>>=), can be derived from "join" and vice versa and are just conveniences to write code with less noise, like flatmap is.

Recap: monad is the name of the concept for things that have a "join" and a "return" functions defined. Basically "join" is the distilled concept of what a monad is.

[1] https://haskellbook.com/

(edit: formatting)

I am a C# programmer, and this series by Eric Lippert really helped me to understand what the fuck a monad is: https://ericlippert.com/2013/02/21/monads-part-one/

It explicitly tries to answer the question: "I’m a C# programmer with no “functional programming” background whatsoever. What is this “monad” thing I keep hearing about, and what use is it to me?"

> Still don't have even the vaguest beginnings of a clue what the fuck a monad is, after reading 50 articles promising to make it simple, as well as their accompanying 500-comment HN threads.

I have an article i'm about to publish that will have a lot more real world examples... hopefully it can bridge the gap.

It'll also have exercises, which are honestly the most important part of understanding.

This video explained it really well when I was learning Haskell.

https://www.youtube.com/watch?v=t1e8gqXLbsU

- How type theory can prove mathematical theorems. I can limp through the first exercises of Software Foundations, but eventually realize I'm just "making it work" instead of knowing how it works. Only made it halfway through My Little Typer and even implemented STLC and used it to prove simple propositions with implications. But I still couldn't tell you how dependent types magically make it possible to prove real theorems.

- How opamps work and how they're used to make a differentiator.

- How quantum computing works. I want understand it to understand why factoring and discrete log fall to QC but not the post-quantum algorithms. I never make it past the intro chapters.

- What exactly makes cryptographic hash functions have desirable properties like collision resistance? Bits go in, bits go out, why can't full observation of the process not yield a method to construct inputs for a target output? Similar questions for block ciphers. It is much easier to "see" the impossibility in public key schemes because you can play and experiment with the math. In symmetric algorithms it looks like just a bunch of arbitrary bit operations.

EDIT:

- Relativity. I accept things like time dialation and nothing can go faster than the speed of light. But I have no idea why you would experience less time passing than me after a high speed rocket trip when, from your perspective, you saw me on a high speed planet trip. Or what prevents a rocket in space with 3m/s^2 acceleration from reaching the speed of light after 100,000,000 seconds.

>How opamps work and how they're used to make a differentiator.

An op-amp is just a very high gain amplifier. It senses the difference in signal levels and just amplifies that difference by a large amount, usually between 1000 and 10,000,000 times.

The first op-amp circuit you usually use is a negative feedback linear amplifier. In this circuit, the positive input to the op-amp is simply grounded. The input voltage is put through a resistor R1 into the negative (AKA inverting) input. The resistor limits the current into the negative input to Vin/R. As soon as the voltage on the input becomes non-zero, the output of the op amp becomes a quite large signal, of the opposite sign. If you feed a small amount of that signal back to the same negative input, (through a feedback resistor R2) the signal will rise until the feedback current balances out the input current.

Now it's not exactly in balance, as there is a very small deviation that has to drive the amplifier to keep its output up, but for most uses the higher the gain of the amplifier, the lower that deviation has to be.

This circuit has a gain of -R2/R1

If you replace the input resistor in the above circuit with a capacitor. It will pass a current proportional to the change in voltage/time and the capacitance. If you feed in a steadily rising voltage, you'll get a current into the negative input of the amplifier that is proportional to the derivative of the input voltage, the feedback current will balance this out, and you'll thus end up with a scaled up derivative of the input.

This circuit has a gain of dv/dt * -R2/(1/c)

If you start with the first circuit and replace the feedback resistor with a capacitor, you'll find that the output has to rise at a rate proportional to the input voltage to balance the input, making an integrator. This only works up to the limit of the output voltage, and there may be a small amount of uncorrected input bias.. to counteract this, a large resistance will be placed in parallel to the capacitor, to keep the output from becoming pegged with no input.

This circuit has a gain of -Integral(Vin)* (1/C) / R1

Notice in all of these equations, the gain is the ratio of the -feedback impedance/input impedance

Does that make sense?

As an addendum, I'd add that Sedra and Smith wrote an amazing textbook on semiconductors that I highly recommend anyone interested in the topic should read. Here's an Amazon link to the book: https://www.amazon.com/Microelectronic-Circuits-Electrical-C...

I think a better way to go through the exercise is to remember the principles of an ideal op amp: The inputs have infinite input impedance and zero voltage drop across them.

You can derive the behavior of op amp building blocks from these rules and Kirchoff's laws. It also makes things obvious, like ideal vs practical integration.

That works for people who just trust formulae, but for those of use with a background in breadboards and solder, the real world behavior of op amps isn't perfect, and we need to understand it in terms of what we already know.

I'm going through the same learning curve with quantum gates. Nobody shows the physical layout of the devices involved, signals going through them, etc.

Ultimately an op amp is a hardware abstraction. Often you teach the abstraction first through its interface to understand how it allows building useful things. Then you can teach the implementation behind that interface, and all the design trade offs. And just like the formulae, you need to understand that it's a tool for simplification - distrust shouldn't come into play, just proper understanding.

At least in my EE undergrad we were taught why you would want an op amp before we were taught how to design multi stage amplifiers with discrete transistors. In fact most of the real world limitations of op amps don't require knowledge of what's going on under the hood, least of all the physical layout of the chip. Even a schematic diagram of the simplified model for a UA741 is more than you'd ever need except for a shitty SPICE emulation.

I empathize with what you're getting at, but I've seen that mentality turn into the bane of practical or working knowledge of many technical topics. It is a skill to be able to learn just what you need to learn and decide what level of detail is enough, and most of the time that skill is only provided through instruction and mentorship.

Here's a good introduction to Special Relativity, which is what you asked about:

http://www.av8n.com/physics/spacetime-welcome.htm

Inflation.

Everybody talks about how increasing the money supply means increased demand, which drives prices up. But nobody explains how does this *practically* happen. Prices don't go up on their own, it's the retailers who increase them at some point. So if the retailers' perception of the reality is not accurate (Suppose for example that money was printed "secretly", or that the increase in demand wasn't very apparent) prices won't magically go up, no?

There is a common knowledge component in all those equations that's missing and nobody talks about it. Maybe it's too obvious that I'm overlooking it.

> Everybody talks about how increasing the money supply means increased demand, which drives prices up. But nobody explains how does this practically happen.

Money supply isn't the only thing that does it, but when demand goes up sales go up, the additional production to keep pace with the sales has higher per-unit cost (because marginal costs increase), and everyone in the supply chain raises prices as a result. (That's simplified, a lot of price changes are anticipatory based on predictive singles, but that's the basic process that ultimately acts to align prices even if the anticipatory pricing misses movements.)

Companies compete for resources. When there is more money out there (low interest rates from the Fed) companies will be able and willing to pay more for resources. When that happens it becomes more expensive to create products which lowers margins. Companies need to keep margins at a certain level (effort is related to … is the profit worth it to run this business?) prices need to go up to keep those margins.

Commodity and base resources go up—>retail prices go up

Very simplified explanation.

>retailers' perception of the reality

More food will be sold (because why not buy the extra whatever since you can afford it) the better workers will demand more pay (otherwise they can go somewhere else that can afford them.)

It's much like gas exchange/osmosis/pressure. Sure the individual particles aren't "thinking" about the behavior of the macro system but their velocity changes every time they bump into each other and that creates the macro effects of osmosis, pressure, heat etc. In the same way inflation is a macro thing that results from the behavior of individuals.

You can see it with boats and cars today: lots of people now have spare money and buy boats/cars -> people selling see that they can charge more (because there are fewer being sold, the ones that do get sold go for more etc) -> boats/cars are more expensive.

I think of it like heat in a room.

In a normal room, the hottest air goes to the top of the room and the coldest air settles to the bottom, right?

However, if the room were to keep expanding, then there is more room at the top for the warmer particles to escape to. Since you stay the same height, the room will feel colder and colder to you even though the total amount of heat in the room stays the same.

As time goes on, unless the room's expansion is stopped or reversed, or temperature treated air is blown into the room to compensate for the difference or, failing that, platforms are provided that will raise you up from the colder areas into the warmer areas, you will eventually freeze to death as the ceiling steals all of the heat of the room, all because you cannot grow with the room.

This is a pretty good example - now just apply it to the actual problem. The amount of currency in circulation.

Inflation isn't about the cost of goods or services actually costing more. They don't. If anything, the cost of production today is far less than it was 50 to 100 years ago because of advances in technology and automation.

It's about the value of the dollar becoming less and less - because there are too many dollars in circulation, which aren't backed by anything real to begin with. "Real" could be something which has a finite supply that we attach an arbitrary value to, like precious metals, or it could be something vitally (needed for life) necessary in today's world like wheat or oil. But for decades now, newly created currency is just an entry in the Fed's ledger book, created out of thin air, backed by nothing.

In your example both the size of the room and the heat represent aspects of currency (note I did not say "money"). The size of the room is the purchasing power of dollars leveraged against the actual effectiveness of the heat. The heat itself, is the value of the currency. The size of the room represents the price of goods.

As the room gets bigger, the heat becomes less effective (it loses value). So pumping in more heat becomes required. When more heat than necessary gets pumped in (on purpose - and it is done on purpose), the room will begin to overheat and no one will want anymore (so it loses its value again). The sane solution would be to stop pumping in more heat - but instead, the same people supplying the heat decide to enlarge the room again, because they are in the business creating heat and charging a fee to deliver it ("they" would be the Federal Reserve - or any private, western central bank).

So the room (i.e. price of goods) must be enlarged over and over again (artificially and unnecessarily) in order for a new infusion of heat to have any value to the people in the room. This in turn, requires the occupants of the room to keep forking over more money in delivery fees to keep the room at a comfortable temperature. If this becomes unfeasible, they may be forced to take out loans to have more usable heat. Now they're paying money for both the heat itself, plus interest on the loan for supplying it in the first place (and they owe it to the same people).

Once you wrap your ahead around the fact that the enlarging of the room and the supply of heat are actually controlled by the same people (who make their money creating heat and charging to deliver it), you then understand that the entire financial system we currently enjoy, is nothing but a giant, legalized system of usury. That delivery fee you owe for supplying the heat is called "interest".

This type of system will always (and is designed to) collapse at pretty regular intervals. When it does, those who control the flow of heat will shut it down, and have legal authority to confiscate the room from the occupants who took out loans for more heat, but couldn't afford to pay it back.

What makes the whole thing more insidious, is that the people supplying the heat never actually owned it to begin with, nor did they create it. It would be as if the room (once upon a time) had a natural heat supply from, say, and underground geothermal source. But some strong-armed, outside entity stepped in, capped that off, and started charging the people in the room for access to what was once naturally available - free of charge.

There is inflation, but there is also price gouging wearing inflation as a mask.

If you want specific information on the exact phenomenon you’re describing, read up on the “quantity theory of money.”

While academically, it is not a precise concept of what happens in practice, as there are multiple factors at play, printing money nonetheless does have this effect.

Organizations’ ability to increase prices as a result of inflated money supply is governed by competitive forces. So, it’s not as simple as seeing money supply increase 40% and thusly increasing your prices, but there is some truth to it.

OOP.

I’m a self-taught programmer, so have probably missed lots that might help, but every time I come across anything OO, it always seems unnecessarily complicated and awkwardly structured. It always seems (to me) that everything could be done more simply procedurally. I don’t get why.

Further, while I can follow OO code that others have written, as a beginner, how to structure something simple I’m writing de novo in an OOP style has a very steep learning curve.

What made OO click for me is watching some of the talks of Sandi Metz and reading her book POODR - Practical Object Oriented Programming in Ruby

Are there any GUI frameworks that are not OOP?

I mean React is pretty popular. And then there's stuff like immediate mode UIs and FRP UIs.

Dear ImGui

Dear ImGUI keeps a bunch of state under the hood, based on the name of the object. It's not object-oriented, per se, but each object has its set of functions that operate on it, except that the object reference is not a pointer but a string. Kind of like object-oriented C (NOT Objective-C), but with strings instead of pointers.

FWIW, after I learned/memorized the semantics of C++, it did take me at least 3 years of writing lousy code to develop a sense of how to structure a program, e.g. what ‘should’ be a class, when inheritance is appropriate, etc. As for the why, I find it a useful formalism for how to organize (as in, group and associate) code and data, as well as a way to create mental-cycle-freeing guarantees (invariants).

In my opinion one of the weaknesses of OOP is just how hard it is to actually model those real world relationships in any concrete form. It's choosing to professionally have a fight with "the map is not the terrain."

Some people are really good it but it's a skill for sure and learning it is rough. It is some really abstract thinking shit, and difficult even to evaluate how well it has been done until much time has passed with it.

I think when people joke about naming in programming this is what they mean. Needing to clearly define relations that are not necessarily clear yet. OOP does demand a lot of that so is hard and exhausting in a particular way.

That said nothing against OOP I use it every day and Sandi Metz is the code book writer I learned the most useful stuff from. Just it's hard in a different way from most of the rest of coding.

Absolutely. I'm continually amazed as how much and how hard people have tried to push everything into their OO framework.

Android development is the classic example - it's ALL OO - and most of the time, that's pushing the proverbial uphill. Instead of just initialise something, everything is pushed into constructors. The model works sometimes, but for many things it just adds work. AND ADDS ENORMOUS AMOUNTS OF BOILERPLATE. Aarrgghhh.

Take a weekend to learn Smalltalk, then it will all make sense. Objects composed of other objects, all passing messages to each other. Whether you can then take that knowledge and have it make sense in a Java, a Python, a C++, etc is hard to say...

It sounds like you do understand it.

Someone will probably chime in with Smalltalk and the original intent or something.

But in modern OOP, understanding and simplicity are not what it's all about.

It's all about pushing the complexity into the language runtime stuff where it is no longer your problem.

OOP is popular because we can do stuff like port=DBConnection(); port.connect("foo.baz") and document= port.request("x").

Then, later on, when port and document are inaccessible, garbage collection will get them.

An OOP programmer doesn't think "Oh, the port.connect must make a socket and do a handshake and then..." they just think "It does all the port connect stuff".

As a student when the goal is to understand, OOP makes no sense, because encapsulation literally is all about making it so you don't need to think about things.

It lets you treat objects the same way we treat physical devices. Black boxes someone else built.

There's no beautiful reasoning or amazing objective logic saying OOP is better than I know of, or anything that even makes any sense at all if you think about it.

It just happens to work pretty well when people with a wide range of skill levels do large projects and nobody understands anything beyond their tiny part, and nobody really cares if things are simple under the hood.

If you want beauty and logic, learn a pure functional language or go study math.

And if you want to structure stuff in an modern OOP style, you just stop thinking in terms of simplicity and unified wholes and start thinking in terms of black boxes to be used by people who would be annoyed if they actually had to read the code.

Any entity you would talk about when describing the code is something that could be represented as an object.

Any collection of a variable number of a ton of entities like customers is something you could do as some kind of database connection object.

Any periodic task might be a "Machine" that is a class that manages a thread.

It's(In theory) a 1 to 1 mapping of ideas to classes, although some things just aren't worth a whole inventing object for and should probably be a data dict+procedural.

But, some would say this whole thing is nonsense for idiots who can't think, so maybe if you find yourself actually able to do procedural well you should try something more logical like haskell.

You are right. Here is procedural:

doX(data, args)

Here is OO:

data.doX(args)

The only difference is that you can stop doX(data, args) from modifying parts of data. However you can do the exact same thing in non-OO languages like C or Haskell by using void* (in C) or (in Haskell) modules with hidden constructors.

The only true OO language out there is Erlang. C++/Java/C# etc. are not OO languages.

The idea that OO is modelling the world is BS. You don't ask your shoe to tie itself or ask a tree to chop itself.

And you don't ask an integer to display itself in a dialog in an "OO" language unless you are a bad software designer.

IMO OOP is simply procedural programming with structs. Except, that whole "struct thing" is much more elaborate and fleshed out and has a much more emphasized philosophy behind it.

Atomic theory after about 1960. I had no trouble at all getting down to photons, neutrons, electrons, protons, etc and how both fission and fusion works. But when it came to quarks, mesons and spin, I could never work it out to my satisfaction.

I think the old adage about math applies to theoretical physics as well - you never understand it; you only get used to it

I think to get some sort of understanding (instead of just operative understanding of quantum mechanics) you have to dive relatively deep into theoretical physics.

Spin can then arise from enhancing the Schrödinger equation with a relativistic description of mass and impulse [0].

[0] https://en.wikipedia.org/wiki/Dirac_equation

I can't reliably figure out the Big O notation of an algorithm for the life of me. I can compare two implementations and tell which is better/worse, but actually calculating it? Not gonna happen.

I struggle with this sometimes, too. There are some examples that are very easy, but others that are very difficult.

For example, finding a word in a dictionary. One algorithm is to start at the beginning and read all the way through until you find it. Worst case scenario, you read all N records, thus it's O(N). A binary search would start 1/2 way through, then repeat with either half, depending on which branch you take, and you wind up with a worst case scenario of O(log N). Nested for loops often wind up as O(n^2).

Beyond that... I have a hard time being any more detailed than the ones I just mentioned.

Well it can get hard sometimes. Ill assume you dont get the basics and try to explain them to you.

For the sake of simplicity, it's just all about getting a ballpark of the resources an algorithm take (often time, can be memory too) without taking into account the specificity of the machine the program runs into.

Let say the algorithm is x+1, x being a number. Now, you can certainly tell that whatever is the computer, it should be fast right. It's O(1). 1 here means, we know it takes one number (x) to compute the result. Wait you gonna say, it takes 2 actually, x and 1. Well yeah, it's 2 then. But it's always gonna be 2. Its not gonna be 3, its not gonna be 4, its gonna be 2, always.

Lets take another example of O(1): x+y+1. How many operations here? 3. Always 3.

So its always a constant number of operation and we call that O(1).

Now let say we have the following algorithm: result = 0, for each x in L: result += x

How many operations? Well now, it depends on the size of L and if L is big, its gonna take a while to compute. Its not a constant anymore. We call that O(N). N here means: the ballpark is: the size of a list. Its not a constant number of operation, its a number of operation the size of a list.

Now, say you have: result = 0, for each i in L: for each j in M: result += i-j

Whats the ballpark here? The size of a list multiplied by the size of another list. So O(N*N) or O(N2).

Now youll find some algorithm runs at O(log N) on average for example. It means its in the ballpark of the size of a list but...no; weve been able to prove that its quite better than that. Say you search in a binary tree, on average, chances are you wont visit all nodes. On average the ballpark is better than the size of a list. Its log N. Why log? Because its a binary tree and binary trees divide by 2 the size of the remaining list after each step or operation.

result = 0

for each x in L: result += x

for each x in M: result -= x

(Loops arent nested here but done sequentially)

Whats the ballpark? O(2N) you might say. Nah, its like saying that x+1 is O(2), you re not giving me the ballpark here. What matters is how fast it grows when we put in more inputs. We dont care how many operations there is exactly.

It's O(N). Think of it like, whatever are the details, we have traversed one list, the concatenation of L and M. Weve just traversed lists sequentially, its in the ballpark of traversing one (think of it as a big one if you need too) list. O(N).

I dont get why people say (with reason, Im not contesting) time passes slowly for a fast-moving object. Since there is no fast moving object since its all relative. My (wrong) understanding is that when you observe a fast moving object (relative to you then) then you should perceive this object as moving slowly in time. And my understanding is that we all go to the speed of light, since its all relative (which would explain why e=mc2).

There is a bit I dont get in there. Namely, its relative but its not. I also have to admit I never tried hard to learn more about it.

> Since there is no fast moving object since its all relative.

I don't know if it will help you, but the explanation that worked for me was: "If two events occur at the same place in an inertial reference frame, the time between the events will be shorter than in any other inertial reference frame."

In other words, each observer sees time slow down on/in objects that are moving fast relative to them (i.e. greater time between events).

For example, if a spaceship zips past Earth at nearly the speed of light, someone on Earth will see the clocks nearly stopped on the spaceship, but someone on the spaceship will also see clocks nearly stopped on Earth. As you said, it's all relative - including time.

Edit: As you brought up the twin paradox in a now deleted question, I should point out that this is indeed "wrong" (or just not applicable) to that scenario. This analysis is only for inertial reference frames and ignores perceptual differences due to moving toward or away. The twin paradox introduces a really mind blowing idea called the relativity of simultaneity. Basically, all the asymmetry in the twin paradox is introduced while turning around.

Basically, all the asymmetry in the twin paradox is introduced while turning around.

Cause light goes at speed of light. Nice.

Im intrigued by matter now. What is it exactly it does to a photon if I attach some to it. Edit: or more like, time must be why a photon doesnt teleport (or even exists), so matter does something to time. Matter and gravity must be the same thing or something.

I wish I had time to study, love it.

Is there other things/particles going at the speed of light in a vaccum? If no, why? Whats so special about those photons? Could there be (in the maths at least) things/particles going at no speed whatever is the referential frame (in other words they are always in your frame like if they were infinitly distant from everything)?

Anything massless moves at the speed of causality

I have another question that's burning me. Has velocity always the same magnitude in space-time? Or rather (cause certainly not), can an object "trully" have varied velocity in space time (other than in terms of direction)?

I have a very poor understanding of mathematical operators and how they relate in formulae. How I have phrased that might even suggest how poor it is. I have learned 'what to expect' from operators, like exponents/log will graph curve-ily etc, but I have never felt a solid sense of understanding that meant I could see any formula containing beyond +-*/ and feel confident that my solution would be close to right.

I recently tried to implement a basic compound interest calculation to graph something and understanding the formula did not come easily. By that, I mean that exactly what the terms represent and what each operation is achieving was something I really had to focus on. Being a dev, most of my counterparts have always seemed very comfortable with this stuff and I'm usually 30s behind.

I'm really astounded when I see complex formulae - I just can't imagine ever understanding them, let alone coming up with them in the first place. It's easiest for me to just imagine that I didn't develop a brain that's good at this stuff. It seems ironic to me because one of the enjoyable parts of writing code for me is modelling scenarios, assigning responsibility, laying out entities, etc which seem (to me) like activities that exist in the same 'abstract thinking' kind of space that math is in. Maybe that's another thing I don't understand :)

Most anything mathematical. Monads, kalman filters, algebra, calculus.

Also, how people are able to practice and improve at something, like practicing guitar and eventually being able to hit every note, or being able to never leave their wallet behind, or stopping at every stop sign and never forgetting which pedal is the gas.

The fact that people are capable of developing true "skills", where they can do every detail of something, every time, rather than just the vague familiarity a modern programmer needs to get by, just amazes me.

I don't think I've ever truly acquired a new skill in the sense people usually talk about. I can't draw, paint, carve, drive, juggle, dance, etc. I can't cook without a timer, unless I stay in the room and don't do anything else.

If something has a way to fake it with more tech, I'm pretty good at that. As long as I can hide behind the screen with my undo button, where my ability with my own hands is irrelevant, I'm fine.

But there's nothing I can just do without thinking.

I never know where I am. I run into tables all the time. It must be super cool to be able to just do stuff without planning every moment, and still succeed most of the time.

Practicing and actually getting better just by doing something, rather than through research and accumulating a library of patterns, is a totally foreign idea.

> Also, how people are able to practice and improve at something, like practicing guitar and eventually being able to hit every note, or being able to never leave their wallet behind, or stopping at every stop sign and never forgetting which pedal is the gas.

That is something I can relate to. I do most things without really thinking and usually do pretty well, but this makes building skills in the long run very hard since I don't really think much. I don't really know why but I feel like thinking while doing things in the moment is hard for me.

Are you able to tell right from left without thinking?

Nope, I have essentially zero spatial abilities. I get left and right confused constantly, and frequently write letters backwards(In addition to writing totally unrelated letters if I don't stop and think about each one)

I also can't really rotate something. When I spent a few hours with a driving simulator game to see if it was at all possible one big issue I had was not being able to figure out which side was the right side of the road, relative to the new perspective after a turn. So I turned straight into traffic more than once.

That is rather fascinating. I wonder if there is some sort of treatment or inner ear procedure you could take to ground your spatial awareness.

Pretty sure I just have dyspraxia, which is one of those dyslexia/add/etc type conditions that doesn't have any drug or surgical treatment aside from occupational therapy and always having 100 different backup plans.

But there's GPS apps now so aside from driving and math it's not that limiting. If they ever fix the public transit here I'd probably be fine...

Certificates, certificate chains, certificate installation. In theory the concepts sound easy and there are numerous guides and instructions online. Once you try to become your own CA the challenge becomes real. Trying to write an automated solution cross-OS feels like running a marathon on your hands.

I’ve always been confused about this too. It seems to me like asymmetric encryption is all there is to it… shouldn’t it just be a bit of data encrypted with a private key? I don’t understand why it’s so complex.

The basic idea is simple: A certificate is just a signed document. The document has been encrypted with a private key so that anyone can decrypt it with the public key and know which private key was used to encrypt it.

The complexity comes from the many layers of detail that get added.

First, we don't encrypt the document directly, because public key operations on arbitrarily sized data can be slow, require padding, etc. So we hash the document, and encrypt the hash: Hashes are fast, they produce fixed sized output (mostly), etc.

Second, the document itself isn't an arbitrary document, it contains very specific, structured pieces of information. The two most important things are a) the public key being certified and b) the identity of the owner of that key.

We need "b", the identity, so that when we decrypt a signature using "a", the certified public key, we can have some assurance as to who the holder/owner of the private key was.

Identity gets complicated: A person? A machine? An email address? Etc. The original X.509 spec had directory names (think LDAP names) only; later revisions added email addresses, machine identifiers, etc.

Third, why should we trust a certificate? And what for?

Above, I wrote that the important things were "a", the certified public key, and "b", the owner's/holder's identity. Well, we also need "c", the certifier's identity.

The original X.509, e.g., basically had a, b, and c, and some date information (during what period is/was the certified key, a, considered valid); we date-limit keys for security assurance, because we cannot guarantee that key pairs generated today won't be cracked tomorrow or next year or next decade. The bigger we make the keys, the more resistant they are, but the slower is the crypto, so we strike a balance and go for more frequently generated and certified smaller keys, unless we really need long-term, in which case we use bigger keys. But hash algorithms get cracked too, so, again, a tradeoff.

So I've got a certifier's identity. Great. How do I verify the certificate they issued? For that, I need THEIR public key. Now we start getting into chains.

Somehow, I have to have a trustworthy copy of the public key of the certifier, the so-called certification authority (CA). The CA's certificate looks like mine and yours, a document containing a (key), b (identity), and c (CA), and some date info, etc.

I use that trustworthy copy of the CA's public key to verify a certificate, and that lets me know that I can rely on a, the key in that certificate, for some purpose.

But what purpose? In the original X.509, it was "fill your boots", whatever purpose you like.

Does that mean I can verify with that key? Encrypt with it? Use it for email, ssh, TLS, or even acting as a CA myself?

Later versions of X.509 addressed these questions by adding various markers that a CA includes to say to relying parties "I say this certificate is good only for these purposes". You are free to use it for other purposes, but if you get burned, you cannot go back to the CA, because those markers basically told you the certificate wasn't to be relied on for that.

Three of the most common restrictions are 1) is/isNot a CA (that is, does the CA recognize the certificate subject, the b, as a CA themselves? mostly the answer is no, this is an end-user or end-device; while there is nothing we can do to stop them from issuing certificates on their own, we DO NOT recognize them - the chain ends here); 2) encrypt/verify, used in two-pair cryptosystems, e.g.: the CA is saying that THIS key is good for verification, but don't encrypt with it, while THAT one is good for encryption, don't verify with it (there can be policy and security and operational reasons for all of those); and 3) purpose, e.g., this certificate is good for email only, that certificate is good for TLS only, this certificate represents a person, that certificate represents a machine, etc.

Fourth, what about that trusted copy of the CA's public key? Where does that come from? That requires a specific action OUTSIDE the overall infrastructure, outside the chain of trust. In many cases, it is a certificate import: We specifically say to our system "trust this specific certificate". How it gets used, the purposes for which it gets used, depend upon where it was imported (into a root certificate store, an intermediate store, a machine store, a user store) and upon the certificate properties previously discussed.

Fifth, and probably last, what if something goes wrong along the way? What if, despite my best precautions, a private key is compromised during the valid lifetime of the certificate?

How do I let people know? That's where revocation lists and online status checkers come in. I cannot remember who said it, but they described revocation lists as wandering anti-matter for certificates.

The basic idea of an RL is that it is a signed list of zero or more certificate identifiers - turns out certificates also include serial numbers which are intended to be unique within the set of all certificates issued by a specific CA. If the certificate is compromised, the CA writes the certificate's serial number on an RL.

Part of verifying a certificate is verifying that it isn't on an RL. Like certificates, RLs have validity periods, so one has to verify that the RL is also valid.

And that's pretty much what the original X.509 said about RLs. The expectation was that they would be in the directory (the whole point of X.500), in the CA's entry (the CA's certificate contains their directory name as their "b"; cf "a" and "b" way above). Original X.509 did make one distinction, between an RL for end-users, a CRL, and one for authorities, an ARL, but that distinction wasn't well described.

What if I am not using a directory? What if I want to have multiple RLs, maybe for different purposes? What if they get very large? How do I segment them? How do I tell people where to look for the RL that would apply to a given certificate?

And how do I know I have the right RL? If I am using a directory, what if an attacker replaces the RL I am expecting with another valid one? E.g., puts the ARL where I expect to find the CRL? Absent other information, the ARL will validate and of course the enduser certificate I am validating won't appear on it (it's on the CRL, the one the attacker hid), so it will appear valid.

Finally, what if the reason for revocation doesn't affect my purpose? The simplest example would be revoking certificates because of a change in business purpose. Maybe the business went out of business in July, so anything signed by them after July is invalid, but anything signed before then might still be.

Later versions of X.509 addressed all of these questions by including reason markers, revocation time markers, and a few other things.

Most importantly, these later versions of X.509 included the distribution point concept, the most important applications of which are 1) segmenting RLs so that instead of having a single monolithic CRL, a CA can maintain many smaller, perhaps more frequently issued RLs, and 2) tying a certificate to a specific RL BEFORE it is compromised.

In other words, the certificate contains a marker that says "if ever I am compromised, the CA will list me on an RL in this place", wherever that is. It goes one step further (since we trust signatures, not places): RLs themselves contain issuing distribution points that identify where they are from or are/were expected to be: The IDP on an IRL should/must watch the RL distribution point identified in the certificate itself.

That way you can know for sure that this is the right RL: If this certificate is NOT listed on this specific RL, then the CA has NOT revoked it.

This gets around attacks on the storage place, e.g., the directory, etc.

And that's just the management side of PKI, Public Key Infrastructure, and doesn't touch the crypto side, which is as complex.

So, yeah, it's a complex ball of wax.

(I worked for a PKI company for many years in the 1990s, did some PKI work before then, some X.500 work before that, and an awful lot of PKI, security, compliance, audit, and directory consulting in the first two decades of this millennium, but right now I mostly write code, either for high assurance network security devices or for an integrated risk and compliance management software product; this quarter is mostly the hardware product....)

"Modern" devops (and kubernetes). It seems to me that people want to avoid human error and dependence by replacing human operators with complex networks of dozen of services, each of which can fail in isolation or in conjunction with others. How do we measure the costs and benefits of putting in all that extra complexity in our stacks, how do we ensure that the friction they cause will not be a greater detriment than the previous situation they aim to improve? Are we in a situation where the solutions to existing problems have so many problems themselves that they need solutions of their own, thus creating an infinite tower of ever more complex software?

This is it for me as well. The best way I can describe it is "bloat."

The best success measurement is described in Google’s SRE book: you’re doing it right when you can scale the number of services/features/products/customers you support faster than the size of your ops/devops/sre team.

The crux of the issue is scaling. Devops is, for the most part, automation. You could never run 500 nodes across 10 geos and 2 clouds by hand. What works for 100 http reqs/s cannot work for 100k.

Kubernetes is a different beast. Most people think of it as a cluster manager: instead of managing your own nodes, then running scripts or automation on them, you write a bunch of yaml and K8s deploys and runs it. While that is fine and true, that's not why Kubernetes was built.

Instead, k8s is a platform for building platforms. You don't run your microservices on it, you run your clouds on it, which in turn run your stuff. At this level, you can see why you need the comical amount of complexity.

Functional programming (and how it is even useful)

A lot of things can be conceptualized as an operation that takes some stuff, and gives back some new stuff, and does absolutely nothing else.

It's like a lot of other strong constraints on complex endeavors. If you run with it you can get surprisingly far, but only by twisting your understanding of how to do things. Whether that's good or not seems highly personal though.

Haha thanks love this explanation!

This is a great explanation. As someone who's a relatively recent convert to FP and am currently writing both imperative and functional code I will test my own depth of knowledge by trying to explain it

1. In traditional (imperative) languages you can have functions that deliberately or accidentally either modify the data they were given or do some other stuff that changes data somewhere else in your program or the computer. Let's take an example of each. Say you have a function that adds two numbers a and b. In imperative languages you could return a+b into b. In other words the sum(a,b) operation would change b. That's not cool in FP: you are (almost never) allowed to change the input you received. This way whenever the function is called with a and b it always returns the sum (otherwise if you call sum(a,b) again you will pass in a modified b).

This makes every function guaranteed to always return the same value for the same arguments. If you accidentally try to change a parameter in your code it will fail.

But you still need to make changes to the world - you do so by chaining these functions and using the output from one as input to the next and so on.

Last but not least, functions that have side effects (e.g. print to the screen) are marked differently and usually their effect is isolated.

A way I heard it explained that made it make sense to me is this:

FP is basically making all of your inputs and outputs explicit. In OOP if you have some bool on a class that affects what a method does, that private bool is technically an extra parameter for that method, even if it doesn't get passed in. Similarly if a method changes some integer on its parent class, in a sense that integer is technically part of what gets returned by the method.

Functional programming forces you to actively think about all of the extra inputs and outputs of your code. In turn, this helps you avoid unintended side effects from the internal workings of a method etc. and the bugs that they can cause.

While the ideas behind FP are useful and can help you think about your coding in a cleaner way, I also think they can be overdone and taken to almost religious extremes. And it can come with a cost of worse performance, more difficult to write/maintain code, etc. , though done right it can have the opposite effect. Done right, it can also make certain aspects of asynchronous and parallel programming easier to work with.

FP, OOP, and all of the other programming paradigms have useful concepts, but purism for any paradigm can lead to all kinds of problems. The obsession with "state" that you see from some FP evangelists is especially annoying, because it ignores that in almost any useful program there will be an irreducible amount of state that has to be tracked and dealt with.

It's useful because it's simple.

You are essentially working with functions that receive input and return output, and are not allowed to change anything outside them.

The simplicity is in that you create multiple levels of abstractions by only combining functions: low-level functions do some "dirty" work that the program needs to perform (slice cucumber, open oil, pour oil, add salt, etc); you then combine a couple of such low-level functions in another set of functions - making it a bit more abstract (make salad, prepare table); then you combine these abstract functions into even more abstract ones(prepare dinner), etc. There will be also some "helper" abstract functions that can be reused in different contexts (slice something, open something, put some food on the table, etc).

Because each function - no matter the level of abstraction - only takes input and produces output - it's very simple to write, read, reason about, and test.

Obvious question you might have right now: how can you write a useful program if you can't change anything outside the function or interact with the outside world? Well, that's the "dirty" part of writing a FP program. You just write your program trying to keep it as "pure" as possible, pushing the "dirty" parts away as much as possible. Think Layered Architecture but for programs. You keep the "outer layers" of your program "dirty" - reading/writing to the DB, making network calls, etc - and preserve the "purity" of as many "inner layers" as possible. For example, when you want to write to a DB in one of "inner layers" which should stay "pure" - you can return your "desire to write to a DB" as a string(or however you encode it) to your outer layers, which will then perform the actual operation by actually talking to the DB. The inner function stays pure because it doesn't actually talk to the DB, it only returns instructions for outer layers to talk to the DB.

Depending on the language you are using it might be either beautiful and easy, or extremely awkward and overly complicated. Most of the time it's something in between.

Hope this helps.

The three forms of heat are radiation, convection, and conduction. I see how radiation is different. But how are convection and conduction different? Conduction is heat transferred when things are touching. Convection is heat transferred via a gas or liquid---but isn't that just a special case of conduction, applied transitively (from a solid A to a gas/liquid B to a solid C)? It doesn't seem like it's genuinely something different.

Convection is with fluids. The molecules themselves move (not just transfer of energy). So different issues arise.

Because you are right - convection is just a special case of conduction

https://physics.stackexchange.com/questions/497923/is-convec...

I've never been able to fully grok parsers. I can write them, but can't make a functioning programming language out of them. I've read books, some of my favorite programming books ever (hat tip to Robert Nystrom). I've read papers, some of my favorite papers ever. But I never can quite seem to get it all to stick.

> I can write them, but can't make a functioning programming language out of them.

What do you mean? A parser is just a program that parses input following a grammar into some kind of internal representation. Did you mean you can't write a compiler? A parser is just a small part of that.

Bell's theorem.

I did an whole B.S. in physics and I could just never get it.

git. Even if I understand the codebase well, I always manage to get my working branch into a merge conflict.

i always pull up the docs on rebasing and do that every time

I can not remember the order of —onto for my life but use it all the time.

I'm not sure of your exact problem, so this might not be helpful, but learning about the reflog in Git accelerated my learning Git because I was no longer fearful of getting my repo into such a state, as I knew the reflog would get me out of trouble, i.e. I could try most any old Git op knowing that if I stuffed things up, I wasn't doomed to re-clone.

With Git everyone has their own personal repository on their machine. Like you could “break away” and be “the central repo and people could start syncing from you. So like remember it’s all “self contained repos” you’re just syncing changes from “somewhere upstream”

Make sure you’re merging changes from your upstream regularly.

When two people change the same area of code, you get a merge conflict.

So sync often and merge often. Don’t wait until you’re ready to push to merge upstream or you’re gonna have a bad time.

The Git Parable [0] was the thing that gave me my "aha!" moment with git. It may work for you too

[0]: https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...

jportet says:

>"Is there a specific topic, concept, etc.. that no matter how many times you try to wrap your head around, you can't ever seem to get it? "<

Yes, <edit>Russian political thought patterns</edit> Make that 'Political thought patterns' or hell, maybe just "Thought."

>"If you were in this situation, what would you do?"<

Go to war? Kill the enemy?

But seriously, I'm completely flummoxed by human group behavior vs individual behavior [i.e., the crowd vs the individual]. We have no meaningful way of extrapolating from one to the other. The closest complete model is thermodynamics, which is so primitive as to be useless in this context.

I've never been able to understand how matrices like 3D transformations relate back to the idea that a matrix represents a set of linear equations. What set of 4 equations are 3D matrices representing?

I'll take a stab at this. Remember that linear transformations satisfy: 1. T(ax) = aT(x) 2. T(u + v) = T(u) + T(v)

Consider a linear transformation from Rn to Rm. i.e. T[x1,...,xm] = [y1,...,yn].

Let's simplify the left-hand side with what we know about linear transformations: T[x1,...,xn] = T[x1,0,...0] + ... + T[0,...0,xn] (by 1). And T[x1,...,xn] = x1T[1,0,...,0] + ... + xnT[0,...,0,1] (by 2)

We don't know what T[1,0,...,0],...,T[0,...,0,1] will be (cause we're generalizing for any linear transformation) so let's just assume the values will be [c11,c12,...,c1n],...,[cm1,cm2,...,cmn].

So now we have: [y1,...,yn] = x1[c11,c12,...,c1n] + ... + xn[cm1,cm2,...,cmn]

And using the properties of linear transformations we can revert it back to the original form: [y1, ..., yn] = [x1c11 + x2c12 + ... + xnc1n, ..., x1cm1 + x2cm2 + ... + xncmn]

So no matter the linear transformation, all entries yi of the vector you output will be equal to a linear combination of x1,...,xn. So if all linear transformations satisfy this condition, what makes a linear transformation different from the others? It will be the set of coefficients [c11,c12,...,c1n],...,[cm1,cm2,...,cmn] that multiply with the x values.

This set of coefficients is unique to every linear transformation from m to n (it's what defines it), this means that we can set up a one-to-one correspondence between these coefficients [c11,c12,...,c1n],...,[cm1,cm2,...,cmn] and any linear transformation (from m to n)!

So let's make it easier for ourselves to describe every single linear transformation from m to n by setting up a rectangular array of the coefficients with m rows and n columns: [[c11,c12,...,c1n],...,[cm1,cm2,...,cmn]].

And so if we find a matrix [[A,B],[C,D]] then we immediately know it corresponds to the linear transformation [y1, y2] = [Ax + By, Cx + Dy]

Note: You won't find a one-to-one correspondence between a matrix and a non-linear transformation with this method because non-linear transformations could have terms like xy, x^a, sin(x), etc... that can't be captured by a linear combination.

I understood Incompleteness Theorems for about five minutes 15 years ago.

How to start a successful SaaS business.

Solve some problem people will pay for.

SaaS is useful inside enterprises because you don't have to provision software on machines.

SaaS is useful for entrepreneurs to build businesses by chaining APIs together.

SaaS viz a vi Shopify is useful because smaller business can leverage larger Amazon like tooling.

The first part is finding something people will be spending money on in like a year.

You either have to be in an industry and see the “next major iteration”, “now that this tech exists let’s make it simpler” or you have to talk to a lot of people to find a common trend.

Once you have that you start talking and showing your MVP to people. They will give you product excuses not to buy. Use those excuses to slowly iterate your product to remove those excuses.

If at the end there are no excuses and people aren’t buying your value prop isn’t strong enough.

Start with “why are people allocating budget here when they could allocate it to something else” … it needs to affect the bottom line somehow because someone who’s buying your product needs to make a business case internally.

So find a trend, iterate on the product, make sure there’s a “reason to spend money on your product instead of another product”

- how mathematicians reason about proof space, when obtaining any metamathematical property of a statement - such as proof complexity - is formally undecidable

- the mathematical formulation and simulation of relativistic systems and the standard model

- quantum anything

- axiom independence proofs/"forcing"

- the shader pipeline

- historical mindsets that caused religious schisms

- why individual particle decay is truly random

- how to reason about complex electronic circuits

- why it makes sense for countries to artificially devalue their currency

- how the execution of passed laws is organized

- how dna recombination works

- p-values and tests of randomness

- mathematical induction

> - why it makes sense for countries to artificially devalue their currency

it's an unavoidable tax. if there are 100 bills in circulation and I print 100 more, I took 50% of the purchasing power of the bills that were originally in circulation.

If someone buys your bond for 10 mil of X currency, you have to pay them back 11mil in couple years, if you devalue the currency in the meantime you just pay them back worthless papers while they've invested real money into you back in the day. Also US dollar is like global currency (everybody country trades in that) - so like 70% of dollars are outside of US. While US prints 100 bucks, 30% of devaluation hits US, 70% hits the world - that's why the world is pissed at US FED printing money like crazy.

call/cc in Scheme. I’ve tried a few times to understand it (and I kind of do on a certain level), but still don’t get how to actually use it effectively in my code

I do not understand why the Oberth effect works:

https://en.wikipedia.org/wiki/Oberth_effect

I understand the math, but I cannot form an intuitive understanding of why it works. My brain just insists that it shouldn't matter how fast you're going, you have a certain amount of energy in your fuel, and that's all there is to it.

Your fuel is measured in delta-V—the velocity you can accelerate by in an inercial reference frame—and kinetic energy scales with the square of your velocity.

Yes, Wikipedia offers a grokable example of increasing speed by 1 m/s:

> at 1 m/s, adding 1 m/s increases the kinetic energy from 1 J to 4 J, for a gain of 3 J;

> at 10 m/s, starting with a kinetic energy of 100 J, the rocket ends with 121 J, for a net gain of 21 J

But the energy of the spacecraft is not static. As the craft falls towards a body it is trading gravitational potential energy for kinetic energy. Thus the fuel/reaction mass gains kinetic energy along with the rest of the craft. So at the lowest point to the body that reaction mass has the most kinetic energy.

From here it could go two ways:

a) The craft does nothing. The full mass continues to get higher and the kinetic energy the reaction mass gained is turned back into gravitational potential energy.

b) The craft ejects (maybe by burning) the reaction mass. The kinetic energy of the reaction mass is transferred to the craft. Ejecting the reaction mass slows it down and that speed is transferred to the craft. Now the craft continues with all the energy it had going in, but because it is much lighter less of that kinetic energy is transformed back into gravitational potential energy.

Or think of it this way. You have a big rock at the top of a hill. You roll that rock down the hill and convert 100 units of energy in to kinetic energy.

At the bottom of the hill is a see-saw. The big rock hits it and launches a small pebble. That pebble still only has 100 units of energy, but it's moving much faster than the big rock did.

It is not about getting more energy, it is about shedding mass at the right time to transfer (what starts as gravitational) energy from the fuel to the craft.

That's not an accurate explanation, since the Oberth effect also holds for a fictitious rocket that doesn't lose mass when it thrusts.

Well shit, I guess I'm in the same boat as Imnimo then.

Time; the nature of time itself.

I know that time prevents all things happening at once... but what _is_ time? How does it work? How did it start? Mind-boggling...

Time is a reference invented by men

Decorators in Python

Have you ever read the chapter on Decorators from Design Patterns? I’d recommend that for a full treatment, but basically it’s just a way of letting you add on additional work for a function call to do. If we had a decorator called @log(), and a function add_two, if we added this decorator on to add_two it will log the function call or some other aspect(as we define it.)

Wow thanks im gonna read that today! That explanation makes quite a bit of sense. Ive been reading over some code to try understand what it does and now its starting to make more sense.

It’s just a super fancy way to put a function around an existing function.

Difference between force and energy? If I hold a kilogram weight it requires me to expend energy. But a magnet can somehow do it for free?

You can look at energy as the potential to do work, and work is a function of force.There is a good explanation of the magnet thing here [0].

[0]: https://reddit.com/r/explainlikeimfive/comments/n9v01r/_/gxp...

What if you hold the magnet that holds something? ;d

I think we should talk force/work/energy/material structure.

Force is just force, how hard you push something. Work is force times distance you moved that thing - moving something 10 meters is twice as much work as moving it 5 meters. Energy is the abstract term that is basically Work, but normalized so we can define energy of any action (not only pushing something but like heating this, or spinning that). Power is energy output per second. (not relevant here)

Person holding 1kg first uses energy to pick this up, then unfortunatelly because we're squishy uses energy to stabilise muscles (chemical energy) holding it against gravity.

Magned uses electric field energy (either static or dynamic cos there's two types of magnets) to pick up something - but once grabs it, it's no longer using energy (there's no movement) - things get 'frozen in time' and that thing magnet is holding just becomes part of the magnet. If you separate them - the thing "gives back" the energy to the magnet (you supply the energy by using force to separate them).

Now the thing that hold the magnet holds both - as long as it's not squishy human but for example the metal bar - it does not use energy to hold stuff (thanks to internal metal structure that's stiff enough to not move under magnet's weight, of course there's a border value of weight a metal bar can withstand without collapsing)

Think of a lamp post holding a lamp above a road - the post does the holding for 0 energy but someone had to use the energy to install the bulb up there. Person holding the same lamp would use energy because we're not stiff as metal.

Thank you very much! Itch finally scratched! You had me at force times distance. I was forgetting about the D part of the equation.

Still re-reading and learning more from it. Thanks a million.

How astronomers “see into the past” by looking at dim stars, and how bigger telescopes see farther back in history?

You probably know that light has a speed, right? It takes time for light to get from point A to point B. Even from our Sun, light takes around 8 minutes to reach us. From that, you are actually viewing the Sun (relative to yourself) from about 8 minutes ago, by the time the light reaches you. If the Sun just disappeared magically, you wouldn't really know it for about 8 minutes while the light traveled from where the Sun used to be, to your eyes on Earth. So, expand that concept to distances that are billions of not just minutes, but years. A "light year" is just how far light travels in an Earth year. So, we can see about as "far" as 13.5 billion light years away. Which also implies we can see as "far back" (in time) as 13.5 billion years ago.

Yeah, I understand that the photon hitting my eye right now was ejected from the sun 8 minutes ago. And if I could see it, a photon hitting my eye now from the big-bang was ejected 13bn years ago.

But if I have some super telescope here on earth, and I'm looking through it now, the photon that hits the eyepiece of the telescope also was ejected 13bn years ago.

I don't see how magnification allows me to see even older photons.

Maybe there's fewer of those old photons reaching us from any particular angular slice of the sky, so you need a more sensitive detector to see them?

Eigenvalues. I can do the math for them but don't quite understand what their intuitive meaning is - if any.

This would have been my answer too, before I found this [0] video. If only I had found it during my EE degree, not after…

[0] https://youtu.be/ue3yoeZvt8E

Thank you both, that was super helpful

Geometrically, it’s the vector that remains on the same line after applying the linear transformation of a matrix.

The halting problem hegemony. I can tell if a program would exit eventually or not. At some point there must be a subset of all possible programs we can tell, can stop, and can tell would stop under x,y,z conditions. So the whole problem thing always felt like a strawman.

I run into this problem a lot on my day job. A lot of things are easy for people to do. A person can look at one example and categorize it A or B. No problem. But trying to get a computer to do it, en masse, at scale, algorithmically, in a reasonable amount of time, can be impossible. Some things just require a fuzzy neural network, I guess. One thing about the halting problem too... the computer can't run the program to determine if it halts or not, it has to be able to tell through essentially static analysis, without running it. I'd say for a human looking at a program, if they did the classic "run the program in my head" which many of us learn to do, then you aren't really abiding by the halting problem's strictures. It may not be as easy to "tell" as you think!

> the computer can't run the program to determine if it halts or not, it has to be able to tell through essentially static analysis, without running it.

Not really, as a turing machine is fully able to simulate any other turing machine.

The problem is not that the "termination checker" may not run the program it's checking (it is allowed to do that). The problem is that if that program runs forever then the "termination checker" program will also run forever and thus never return "yes" or "no".

(You could say, well just output "no" if the program runs for longer than x days / weeks / months / years, but it's quite easy to write programs that run for a very long time but do eventually terminate. At best, you'll manage to write a checker that can output "yes" or "I don't know").

Can you? Try proving the Collatz conjecture. It's a very simple program.

Of course, such subsets exist. You can either define such subsets informally yourself, or you can find a total programming language (such as Coq), in which you may only write programs that provably terminate. Even without identifying specific subsets, it's quite possible to predict whether specific programs terminate. For example, it's trivial to write a program that loops forever.

Some people misrepresent the halting problem and its corollaries as "we can under no circumstance predict any aspect of the behaviour of any program", which is in fact wrong.

What is true is that, for every property we may want to assert about a program, there exists a program (on a Turing machine or in a Turing-complete language, so excluding any of the total programming languages) for which you will fail to tell if it has that property.

Still don't understand dew point/vapour/condensation. When I read/watch about it it sounds trivial, but if you asked me to explain it right now, I'd say "I don't know". So I don't really understand it.

Its all about energy. Water condenses when it doesn't have enough energy to keep zipping around in the air. This means kinetic energy, physical movement.

Water has one oxygen and two hydrogens, this makes for a pretty polar molecule. At a purely mechanistic level, you can think of polar molecules like how magnets work. N is attracted to S and vice versa. In polar molecules, + is attracted to -.

When water loses energy (like through cooling down which is just when it runs into other molecules and loses energy) it doesn't have enough momentum to not stick to other water molecules. When this happens they start clumping together and can fall out of the (gas) solution.

Water in air is moving around pretty fast and this overcomes the attractive force of the polar interactions with water molecules, so no clumping (water droplets)

Since amount of energy (temperature) determines how much water the solution (air) can hold, dew point is the temp at which the air is fully saturated with water molecules and can't hold any more. Water will condense if the temp is lowered past the dew point if we assume a constant water content and air pressure

I appreciate the time you took to write this up. I think this is the clearest explanation I've had yet.

So, when I have a cold glass of beer and there's condensation on the outside of it, it's because molecules of water vapour bouncing around, cool down rapidly, lose their kinetic energy and end up being captured by the existing water on the outside of the glass?

yea they just "warm the glass" giving it their energy, thus slowing down and eventually condensating because they've lost so much energy (cold stuff absorbs heat from the warm stuff)

on the contrary if you boil the water like madman you're giving water molecules so much energy it flies away as steam :)

Yea, from our huge perspective it's a bit strange to think about. Heating a pan means you're giving kinetic energy to the pan itself, the pan molecules are then smashing into the water molecules

How gravity and mass and time interact.

I get the description of planets in gravity wells and can understand the basic technical explanations.

But it still just doesn't make rational sense on any level to me since I view time and gravity as static concepts from my experiences.

Same. The only path I see is to really learn GR (and the requisite differential geometry) and do lots of examples. I never got far enough to grok it.

I feel that I sort of get it - after listening to many many podcasts by scientists trying to make it understandable. It took me years. And still I may be wrong, so please consider what follows as an essay.

My first major step was to really understand that gravity is a law and not a force.

This is totally counterintuitive since we feel gravity as if it were a force, and because many people use the expression "force of gravity".

So a mass should be viewed as a "tag" that an object has - and the higher the number on the tag, the higher it deforms the space-time around it.

My second major step was to understand that all objects, for example planets, always go straight along a line. They appear to have an orbit because they move in a space-time that is deformed by other planets and mainly stars or black holes.

The moon goes along a straight line in its space-time. But the latter is deformed by the mass of Earth so it looks to us living in Earth's space-time that the moon is orbiting around Earth.

The third major step is to understand that the two space-times mentioned (the Moon's and Earth's) are not "related". Someone on the moon lives in a different space-time than someone on Earth.

So the duration of time that person lives on the Moon as measured by an atomic clock he/she brought will diverge with an atomic clock on Earth.

The difference won't be huge, in truce very very small - but measurable.

Everyone of us lives in its own space-time. Because the gravity is not equal on the point of Earth surface. Because of mountains, and because the Earth itself is not homogeneous, and because we move around and up and down all the time.

In final, this means to get rid of two related notions that appear so self-evident that it is almost impossible to really get over with: - there is a common 3D space that we all share ; - there is such a thing called time that is totally independent and flows continuously.

What really exists - for each person or object or planet - is its own space-time.

And all these space-times are unrelated to each other.

The proof of it is that there is a maximum speed limit to any existing thing. That maximum speed does not vary whatever are the speeds of two considered space-times.

The only thing we know that reach that maximum speed happens to be the light in space.

If the two space-times were related, then the speed of light would vary if one space-time is moving in a different direction and/or speed relatively to the second considered space-time.

But it doesn't. So you and me don't share the same space-time. So, between two encounters, we won't have lived exactly the same duration of time. Our personal atomic clock, if synchronized at the first meeting will have diverged when we meet again.

Of course, the difference will be so super small that it's unnoticeable to us (but measurable with today's technology).

GPS satellites orbite at around 36,000 kms from Earth. That's far enough to make GPS calculations quite wrong if Einsten's relativity is not taken into account (by around 50 meters). That is noticeable.

By the way, Einstein deeply regretted his poor choice of words. Because its theories of "relativity" precisely demonstrate that the different space-times are NOT related.

We need to understand that space and time don't exist. Only unrelated space-times co-exist, within which time as we feel it flows at a different pace than in other space-times.

But there is only one "Reality", right? Well... that really depends what we mean by that. The only common point among space-times is the respect of causality.

That sort of reinstates time as we feel it. If A causes B, then B can not precede A.

In a sense, events creates time as we know it. After all, we are all very often surprised by the time it is on our watch. So this "unstoppable Time that flows no matter what" that we think as self-evident in our representations ... just doesn't match our very variable perception of time in our lives.

Isn't it weird that we commonly consider obvious a notion that contradicts directly our daily experience of it?

Maybe it is time to reconsider the way we teach physics at school ; we learn Newton's laws and then we are supposed - much later if ever - to unlearn it in order to grasp Einstein's relativity.

Some will argue that Newton's laws are good enough for our daily lives. Well... not anymore since we use GPS all the time. And Newton's law can't explain Mercury's orbit either so why are we taught Newton to explain the orbital system when 1 planet among 9 contradicts what we are taught?

Science is by principle a work on ourselves to deconstruct reality as we perceive it spontaneously, through our senses, our biases and also the inherited paradigms from the established Science.

It is super difficult to unlearn. If you play tennis for years without taking lessons, it is super difficult to train our body to unlearn the bad habit and learn the proper way taught by a professional.

So maybe let's stop calculating where will land a cannonball without even taking into account the effect of the air! This is not even a practical teaching of everyday life since the major effect of air on the cannonball is obliterated to teach us Newton's laws that are not totally true either.

Let's learn Einstein first. That the nucleus of an atom is 100 000 times smaller that the atom ; that no graphical representation of a nucleus composed of neutrons and protons is possible ; all these illustrations with agglomerated spheres of different colors are ... just wrong. Phycists don't know how to represent a nucleus, which is not a static thing but rather something that is animated by opposite forces but kept close by a vastly superior force.

Physics is like History. We keep on learning at school things that we know to be at best approximate and very often just plain oversimplification that leads to misrepresentations that are super difficult to correct.

Hence the so many Russians, including Putin himself, considering that Ukraine and Russia are historically one nation. Totally ungrounded but war nonetheless.

Fascinating essay, thanks for putting all of that down.

You have thought about this plenty. The only thing I'll add is that all objects live in the same spacetime. The metric of that spacetime is a mathematical object that obeys known laws under coordinate transformations, and the parameters of those transformations depends on the energy momentum tensor (likewise an object that transforms...).

Trouble with GR is that the "trivial" solutions are heavy shit. So it goes.

Teaching anything when the student doesn't want to learn is a bit futile. I was taught physics at school. I am actually interested in physics now, and I am finding the historical progression, the story behind the move from an older model to a newer one to be very enlightening. I was taught this way at school but I just didn't understand it and wasn't interested enough to pay full attention. I think there is value in telling the historical story of physics, just only to interested students.

Yes! That's fascinating and thank you for writing that. It expanded my knowledge. You should put that in some sort of linkable format.

However, think about insane it sounds.

Like if we didn't have the subject physics or if you had to explain it to a medieval king in the 1300's.

They would think we are totally insane.

Because it is different than what our everyday hairless monkey lizard brain sensory organs are reporting to our brains.

That's why I struggle with it.

Cool example of satellites. That actually grounds it in an understandable example.

Also does relativity discount Newton?

Or can it be viewed as an extension?

> Physics is like History. We keep on learning at school things that we know to be at best approximate and very often just plain oversimplification that leads to misrepresentations that are super difficult to correct.

I think all of science is like that. It's continually advancing and changing our views of the universe which is beautiful.

Im going to tell my boss next time I'm late that I'm not late it's just that our space times are subjective and aren't currently synchronized.

Haskell. Not a concept exactly.

Best trick that I have ever learned is to build resilience or “stick-with-it-ness”.

Do explain please?

This is my take on it: when you start something it's at first easy and then it gets really hard. Or boring. Or you get distracted or disenchanted. But if you stick with it long enough you eventually become an expert in the space (or what you are building becomes good enough) that it's not state of the art. And then you can innovate on it or sell it or sell your skills. But you have to get through that tough valley in the middle.

Covariance and contravariance

Why we say nothing can't go faster than speed of light when on the other hand we have quantum entanglement which shows otherwise.

I knows this is a dumb question but please pardon me as my knowledge of physics is very limited.

Quantum entanglement has not been able to show any usable information can be passed faster than speed of light.

So for example, if two bits are entangled, you flip one bit, the other bit flips at a completely unpredictable way.

Hence, no rule is technically broken.

Hasn't some information been passed? You flip one bit, and if your observing the other bit you know the first one was flipped? So you know when something was done to the first bit...

But observing the other bit changes the outcome. The whole point is that you don't know the outcome until you observe one of the particles.

> Quantum entanglement has not been able to show any usable information can be passed faster than speed of light.

The key word being: "usable".

You can have two bits of quantum information entangled together so they are always opposite values. Then (while keeping the two bits entangled) separate the two bits and place each inside a box without looking at the bits. Then move the boxes apart to the other side of the world.

Quantum Entanglement says that we can open one box to look at the value of the bit inside that box and know that the opposite box has the opposite value.

Alice opens her box and sees the bit "0", so she knows that inside Bob's box is a bit with the value "1".

So depending on which quantum mechanics interpretation you're using, Alice's bit has to share some information with Bob's bit to determine what each bit's value is.

Depending on the time that the boxes are opened, we have experimentally proved that if information is getting transmitted between the two bits and if it is travelling through the space between the two bits, then it must be transmitted faster than the speed of light.

The problem with trying to use this "transmission speed" to send information is that there is no actual way to send any usable information with it.

We can open a box on our end to see which value we got, but we don't know if we got value because we opened the box first, or if the other person opened their box first. The only way to tell is to go and talk to the other person to tell them the time that we opened the box which in and of itself is slower than light.

I'm a 5 year web developer and I can't understand what web3 is, after spending about 15 minutes trying. Good luck to those senators who try to understand or pretend to understand it.

Instead of big tech giants like FB and Google controlling big centralized databases, you should use a decentralized (but defacto centralized) database that is less efficient.

Instead of recording transactions of a coin on the blockchain, you are storing web3 app data on the blockchain. Unlike a centralized DB controlled by corporations/organizations, it is distributed just like all the nodes in ethereum(for e.g). That was how it was explained to me.

I don't understand why x^n+y^n=z^n has no integer solutions for n > 2. I tried to understand it for a long time but it was too difficult so I gave up. :)

Basic explanation for hawking radiation. Maybe the concept is too complicated to be explained in simpler terms.

Redux (including Thunks, and Sagas)

React hooks

Space-time

https://m.youtube.com/watch?v=wrwgIjBUYVc

leasing a car

Entropy.

your nickname says otherwise :>

trigonometry

Reply on news.ycombinator.com