Fair enough. These are used as scientific materials for scientific purposes, and are indeed not suitable for an engineer's work. However languages and frameworks are abstractions (= models) of how a computer works and engineers do use them to control it and get the ordered results.
Think of a computer as a black box. You want to get some output from it (calculation results, commands, whatever). You need to know what input you must give them in order to produce the expected output. This is were programming languages and frameworks come in. They offer an abstraction of the working of the computer that you can use. Programs are indeed not constructed to explain how a computer works because they are the input, not the system itself. They are the input a developer needs to provide to the computer in order to have the requested result.
How does a developer know what input to give (i.e. what code to write)? He has to understand how the system works, or rather, how the abstraction layer/framework he's using works. If his knowledge is not perfect, he might observe some unexpected results. He then needs to investigate what part of the framework he did not understand, and adapt his program consequently.
This is what all engineers do. They manipulate a system using an abstract representation of it, they gain experience by figuring out how or why the output they receive is not what they expected and by iteratively adjusting their understanding of the system.
Since all engineers do this, why would developers do things differently? Engineers learn to manipulate abstract models (in a lot of different domains), and IMHO many developers fail because they lack such training.
Because, as arethuza said, programmers don't have the tools that other engineering disciplines have. Most notably, the equations that allow for predictive analysis and proofs of correctness.
A civil engineer that builds a bridge can be fairly certain it won't fall down even when it's still on paper, because he can reason about the forces and stresses and even environmental degradation via well known equations and models. This collection of predictive and proof techniques is what makes it an engineering discipline.
Programming doesn't have that, at least not yet. As you point out, the program is the input to the machine, not the predictive model. But at least if the machine acts deterministically, we can focus on proving things about its input, the program. There has been quite a bit of effort in the research community to come up with ways to prove correctness, but the state of the art is still a long ways from being something actually useful. Functional languages are (partially) a reaction to the prediction requirement. By not having side effects or depending on state, it's easier to make predictions about behavior. (Of course, lazy evaluation buys you a lot in expressive power and data structure efficiency, but offers a new hurdle in predicting performance).
And if you really look at it, Software Engineering is, well, not. Everything I have seen in the emerging Software Engineering field is really about managing people. It's about how to get 1000 developers on the same page (which is like herding cats) so they can crank out an operating system. Sure, there is a lot about testing and validation and change control, but it's still mostly from the angle of controlling the risk of a developer doing something stupid. The tools that would allow a software architect to write an exact specification of a project (bridge blueprints), prove it'll meet all requirements (not fall down), then turn it over to junior programmers (construction crew), just don't exist yet. Check out Rosetta for an ongoing attempt.
So maybe someday programming truly will be an engineering discipline, but right now it's more like having a million Wright brothers all building their own airplane, using whatever materials they are used to working with, rather than an established discipline like Aeronautical Engineering.
Most real-world software projects aren't the kind of straightforward batch processing jobs you might have done in the mandatory entry-level college programming class that they make engineers take.
They aren't about trying to figure out the input (code) to get the 'expected output' you want.
They are about dealing with user interaction, and users - messy and unpredictable. It's not merely a matter of looking at the possible 'inputs' a user can take and trying to explore all the possible stateful interactions; if the software doesn't do what the user actually needs, or if he can't figure out HOW to make it do what he wants, it's a failure. Figuring that out is called design, and there's no way to 'engineer' that.
The people who 'design' the look and user interface of the car? Automotive Designers. Not automotive engineers.
The people who 'design' buildings are architects. They work with engineers to make sure the buildings 'work'.
Software is most akin to architecture, except the role of 'designer' and 'engineer' is rolled into one. There's only a portion of the the development process that you can actually apply engineering principles to.