Of course that's your take, definitely not mine. Not easy to discuss though: the obtuseness in today's software building won't be obvious until we discover the principles that turn it into engineering.
In ancient Egypt, pyramid-building must have seemed the unbelievable pinnacle of human achievement, only surpassable by ever higher and larger pyramids. Only now we see the primitiveness of those works (notwithstanding their merit and value).
It is my take that our current level of understanding of software building is similar to the that of architecture when pyramids were built.
Fortunately, advance is now much faster thanks to the many tools that help experimentation and communication, and we should be approaching somewhere reasonable in just a few decades.
In my view, Turing's results are equivalent in computer science (an important part of software creation) to Pythagoras' theorem in geometry (an important part of architecture): incredibly insightful, fundamental, everlasting and useful. Used directly or indirectly in all early works, respectively, in software and architecture. And only a tiny part of the foundational understanding necessary for really mastering the discipline, a level I think we still haven't reached in software.
They are more of an understanding of what theoretically can be computed, rather than anything to do with how to do it or how to efficiently do it. I study lots of theoretical computer science, but it doesn't intersect with software engineering much. Software engineering tends to more relate to project management, operations research etc.
If you mean "the theoretical underpinnings", then, yes, we think we do. Turing machines and Church calculus provide solid theoretical underpinnings, that (as far as we know now) are complete. (Of course, the future could show us that they are incomplete. That's the problem with knowing whether your current understanding is proper - you don't know what gaps the future will reveal.)
However, if you mean "we know how to build programs so they work", there's massive empirical evidence that says that we don't. (That is, we can do it... sometimes. And sometimes we can do it after it takes five times as much money as we expected. And sometimes we can't make it work, ever. And we can't tell up front which will happen.) So in terms of this being engineering - as opposed to computer science - saying that we don't properly understand the fundamentals seems like an entirely reasonable statement.
I quite agree with you, but not completely. It's true that Turing & Cburch fundamentals are complete, in that anything we describe in computation can be expressed in terms of those. But I think we are using a very small subset of all Turing-Church based computing, and refinements of this understanding will provide a qualitatively better algebra for the types of software we really create. This will make it easier both for engineers to create software, and for end-users to do things that nowadays only programmers can do.
Both ends you describe (computer science and software engineering) are to me part of the same continuum. We still have articulate most of it with a coherent theory.
A mechanical engineer knows about the properties
of the metals, plastics, etc. he uses. A
civil engineer knows about strengths of
steel I-beams, etc. An electrical engineer
knows about capacities of cables, switches,
etc. So, these engineers can do real
engineering and have transmissions run,
electric power networks provide the power,
and tall buildings and long bridges stand.
A software engineer knows about the capacity
of a server? With what I/O rate, TCP/IP data rate,
memory locality of reference, independent
threads, memory that can be effectively cached,
the memory usage, errors and their consequences?
E.g., one of the problems of doing optimization
of assigning programs to servers in a server farm is
knowing what (1) the servers can do, also considering
other programs the server is running, and (2) what
resources the software needs, and it's too
tough to know either and, then, in a significantly
large and complex server farm, fully to exploit
this data for full optimization.
Software engineers are working with at best rubber
specs on both the resources they have and
the resources they will be using.
So, can't really do engineering on the
work, e.g., really can guarantee next to
nothing. Or, would you want to bet
the life of your wife or daughter on
some software doing its work without errors
and on time? Neither would I!
I agree. Sometimes we do take the reductionist approach, take the Apollo guidance software or seL4 as examples. However, when winging it gets you results that are almost as good in a fraction of the time, you can't be surprised at the prevailing method of software 'engineering'.
In ancient Egypt, pyramid-building must have seemed the unbelievable pinnacle of human achievement, only surpassable by ever higher and larger pyramids. Only now we see the primitiveness of those works (notwithstanding their merit and value).
It is my take that our current level of understanding of software building is similar to the that of architecture when pyramids were built.
Fortunately, advance is now much faster thanks to the many tools that help experimentation and communication, and we should be approaching somewhere reasonable in just a few decades.