>Isn't all programming just syntactical tricks?

No. The decorator is really just a syntactic shortcut. There are other facilities in python to do the same thing. The decorator is just a convenient way of doing it. The concept at hand is a function that takes a function and returns a new function. Nothing crazy here.

  decorator: Callable[[Callable[[Any]. Any]], Callable[[Any], Any]] = lambda x: (lambda y: x(y)) #does nothing
  g: Callable[[Any], Any] = lambda x: x #identity func
  decorated_g: Callable[[Any], Any] = decorator(g) #decorator that does nothing to identity returns identity func   

You see? You can just call the function and assign the result to a var and that var is a decorated function. The facility exists, the @ symbol is simply a convenience so you can execute it in the declaration step.

>We have a fundamentally different view of these things. Mine is serving me well. Yours isn't challenging mine.

Exactly see. Just because my view is "better" or more "modern" you still function fine within your role which is my point. Someone could have knowledge far superior to a person with 2 years of experience, functionally speaking, it doesn't matter too much. You still do "fine" at your role. Your view serves you well in the capacity of a "senior" engineer" even though your view points are ultimately wrong and inferior they still work well enough.

Also it isn't a viewpoint. Two of the newest languages to hit the mainstream have eschewed inheritance completely from their syntax. Neither Golang or Rust have the concept. Both use interfaces exclusively to promote the concept of similar types. No inheritance anywhere. I have tons of evidence on this even papers, quotations from prominent people. It's a well known fact inheritance is outdated.

We can agree to disagree, but it's like agreeing to disagree with a child who doesn't know any better. Sure.