For a good programmer, the language is just a tool to make what you've just thought out. To me, programming isn't about how to code, but about what to code. What makes somebody a good programmer is the thought process before a single character of code is written.

Someone who assembles an Ikea cabinet isn't necessarily a master furniture maker (altough they could be!). If all you need is a cheap, cookie cutter coffee table it'll not only do, but it'll be the fastest and cheapest option. However, if you're looking for a bespoke cabinet with dovetails, you're going to need a furniture maker.

>For a good programmer, the language is just a tool to make what you've just thought out.To me, programming isn't about how to code, but about what to code. What makes somebody a good programmer is the thought process before a single character of code is written.

I tend to agree with it but there is a bit of idealization here. How to code does matter. It helps to not care about RAM barriers, CPU registers, memory pointers, etc. The span of human attention is only so much broad. Constantly dealing with low-level details obstructs seeing a bigger picture. Assembly coders don't think much in terms of type classes or lazy evaluation.

Most apps, especially data entry apps, are like ikea furniture. You don't need a master furniture maker.

Programming in assembly isn't harder (in fact quite the opposite), it just takes more grunt work. The actual difficulty of solving a problem (the 'irreducible complexity') is the same regardless of language.

There's a difference between useful, tried and true abstractions like SQL or compiled languages. As you accrue decades of experience, you start to learn that some abstractions are just hopeless, like those tools that sell themselves as "programming for non-programmers" which promess you that you won't need to write code. A new version of this comes up every few years.

>Picking the right tool for the right job will always be a problem to solve

My experience has been that this is a very challenging problem. Business leaders consistently apply pressure for faster results (rightly so!) which means that technology leaders will also be under pressure to deliver faster results.

Tools at the highest level of abstraction (like the various "declarative programming" app builders) trade away power and flexibility in return for simplicity. The sales teams that sell these tools then inevitably highlight the speed and gloss over the trade off that's being made. The message that buyers (business and tech execs) hear is that a tool can solve problems faster.

That is often true when the tool is being applied to a problem for which it's suited and can be disastrously incorrect when it's applied to a problem it's not suited to.

My experience is that the promise of "faster" often drowns out the voices warning that a tool is being applied to the wrong kind of problem.

Right, that's why the best abstractions are built on solid tools, and if needed, give you access to that lower level foundation.

If I can do 95% of my work using the super simple UI, and then for that last 5%, I can go in and hack my way with some code, I'm much happier than having to write 100% of the code with code.

Of course, if that last 5% is impossible to achieve at all, then yes, you're definitely not going to be happy and that 95% will have been a total waste.

You're pointing out that programming languages are relative to the level of abstraction needed but not the quality of the programmer. So true! Programming is programming.

bigato, on the other hand, is pointing out that the brains are relative, i.e. regardless of the programming language, you still need a programmer's brain using it to be successful.