Great presentation !! The balance between build abstractions vs illusion is an awesome analogy and I think that is part of our lives as a software engineers. I like this way of thinking and I really agree that we always need to find the balance in everything that we do: - Build abstraction - Don't abstract too much - Use patterns - Don't segregate the system to only use patterns in everything - Hide details and information - Don't hide too much Sometimes we cannot achieve the best design from the first time, but to have the mindset to always do an incremental design and improve the places we pass is a great thing as well.

Phenomenal well presentation!

This talk has been featured in the #6 issue of Tech Talks Weekly newsletter. Congrats Gregor!

GM had been doing so since the 30s.

Was surprised by "RPC - the worst illusion" claim, as it doesn't make much sense. It is a useful abstraction as well as justified simplification and is very appropriate in vast majority of scenarios. RPC does not pretend absence of partial failures, as local calls don't pretend it either: anyone who wrote multithreaded code is aware of that. Similar story with congestion, retries and whatever else was mentioned.

@architectelevator

2 ай бұрын

What I tried to highlight is that a local method call (commonly) behaves quite differently from a remote call. You won't expect the invocation to fail due to the method being unavailable or worry about latency. Most local method calls won't have retry logic, e.g. if someone calls myString.toUpperCase() they won't have logic to retry that. There are always exceptions, so I am basing the example on common usage like one method calling another.

How about solve problems, not build abstractions...

@ConductiveFoam

2 ай бұрын

Because good abstractions help solve problems Also, if an abstraction becomes ubiquitous we cease to even realize it's there

@mardukbp

2 ай бұрын

As explained in the talk abstractions (should) provide a language for describing the solution to a problem. This is a key point. The names of classes and methods (or modules and functions) should provide a vocabulary that allows people to communicate ideas about a certain domain (technical or business). As stated in the preface of SICP, software should be written for humans to understand and only incidentally for computers to execute. Unfortunately this is not how most people are taught to write software and therefore it's not uncommon to find bloated codebases which consist of layers upon layers of mindless abstractions, which make it very hard to understand what problem they are actually trying to solve.

@orange-vlcybpd2

2 ай бұрын

Problems which can be solved without abstractions are trivial. Also your very math from the elementary school, is all abstraction. What you see on your monitor is abstraction of the signals inside the computer. Its an abstraction which helps us interpret the signals. Abstraction is the cornerstone in the foundation of our human cognition.

@aybgim3850

2 ай бұрын

Mediocre coders solve instances of problems. Good software engineers build solutions for classes of problems. This is where abstractions come into play.

@mardukbp

2 ай бұрын

@@aybgim3850 This is not true. It's like saying that all the Physicists that came before Newton or Maxwell were mediocre because they didn't come up with a general framework for solving problems in a given domain. A framework so general that it allows solving classes of problems arises only after solving lots of individual problems. As Newton said, he achieved what he did because he was standing on the shoulders of giants. Great scientists and engineers acknowledge this. They don't call people names.

Aye('so much').hate().hooks();