This is a variant of the no-code mindset where people expect coding to be easy.
What they don't understand is that tools which aim to make coding easy or automatic don't add any value if the person using the tool doesn't understand all the nuances in the underlying logic which is being produced. Fully understanding the distinction between client and server is one such nuance.
When it comes to coding, the bottleneck is essentially never the tool, it's almost always the person.
I don't think I've ever met anyone who was naturally good at thinking logically. Working close to the hardware and then working your way up the stack is one of the best ways to develop the required level of nuanced logical thinking.
The problem with no-code, low-code or tools which try to move away from the underlying reality is that they don't train your logical thinking skills.
In my view, tools should help people develop into better programmers, not give an illusion of ease and mastery when it is not deserved.
> I don't think I've ever met anyone who was naturally good at thinking logically
I've heard, though, that declarative programming (prolog, haskell etc) was a LOT easier for people who aren't trained in imperative programming. Whereas those who are actually have a hard time picking it up... As was my experience.
@op have a look for declarative programming. You might like prolog :)
I'm someone who learned declarative after imperative. In my experience, there are two things to understand about any declarative language: what it expresses, and what it actually does on the machine. The latter is often considered an implementation detail, but - at least for the people with imperative programming experience - it's actually crucial to gaining full understanding.
I remember my final breakthrough in grokking Prolog was realizing that the engine hides a glorified DFS that walks a graph of concepts for you. Suddenly, all the reasoning and non-deterministic features wasn't mysterious anymore, and performance-related implications became clear. Similarly, for people who struggle with async, it's beneficial to understand that async means somebody hid an event loop from you.
Both Prolog and Haskell make memory management really hard, and without good memory management you can’t reason about the run time of software.
Of course the solution is to learn a lot on the low level details of the compilers for these languages, at which point it’s not easier than imperative coding.
Doubt it. To do anything beyond basic stuff in Prolog you need to understand its resolution algorithm. And it is not enough to understand 'what' it does but also the 'how' which is basically a backtracking algorithm.
My main problem with declarative/functional programming languages is that they force developers to separate the logic from the state (they are not co-located based on concerns) and this often causes developers to neglect the separation of concerns principle altogether; which is by far the most important principle in my experience.
Most developers never learned proper blackboxing/state encapsulation.
It's impossible to create truly modular code without colocating related logic and state.
Yes! Being able to hide state is a blessing but sometimes also a curse.
However Monads kind of allow you to hide/abstract over state too. I find it way more difficult though.
What they don't understand is that tools which aim to make coding easy or automatic don't add any value if the person using the tool doesn't understand all the nuances in the underlying logic which is being produced. Fully understanding the distinction between client and server is one such nuance.
When it comes to coding, the bottleneck is essentially never the tool, it's almost always the person.
I don't think I've ever met anyone who was naturally good at thinking logically. Working close to the hardware and then working your way up the stack is one of the best ways to develop the required level of nuanced logical thinking.
The problem with no-code, low-code or tools which try to move away from the underlying reality is that they don't train your logical thinking skills.
In my view, tools should help people develop into better programmers, not give an illusion of ease and mastery when it is not deserved.