Comment by arethuza | Hacker News Reader

Comment by arethuza | Hacker News Reader

Parent Full thread

"they are not trained to mentally play with the theoretical tools they use"

That's because the actual theoretical tools that are in place from computer science are generally not practically applicable to 99.9% of the work that most developers do.

A knowledge of lambda calculus, CSP, Turing Machines etc. etc. is of no relevance whatsoever to someone building a CRUD business application or (for that matter) another client for Twitter. Formal abstractions from other fields aren't of much use because the mathematical techniques used for modeling the "real world" don't apply too well to programs.

"Programming languages, frameworks and patterns are scientific models, designed to represent the working of a computer"

That an interesting idea - but as far as I can see, completely wrong. Scientific models are created (usually using maths, but not always) to provide logical structures that have predictive and explanatory powers - and have to be consistent with observed behavior and have be falsifiable.

Programs aren't constructed to explain observed behavior of computers or to predict what computers will do - they are created to control (through layers of abstraction and translation) what the devices will actually do. So I don't think "scientific model" is the right phrase to use.

"A knowledge of lambda calculus, CSP, Turing Machines etc. etc. is of no relevance whatsoever to someone building a CRUD business application or (for that matter) another client for Twitter."

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.

> Since all engineers do this, why would developers do things differently?

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.

"And if you really look at it, Software Engineering is, well, not."

Well said!

Your understanding of software development is limited.

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.

And physical engineers don't have users with even more complicated interface problems? Most computer systems are not real time. Airplanes, cars, factory processes, cranes, power plants, even chairs have an interface with users that is more complicated to design.

The people who make chairs aren't engineers. They're designers. Industrial Designers.

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.

I disagree with what you are saying. For each item you mentioned that is irrelevant, the same is true in electrical engineering or mechanical engineering. It should be obvious why a Turing machine isn't relevant to modern programming. It should also be obvious why Einstein's models of the universe aren't relevant to automotive engineering.

There are many computer science principles that are relevant to even a CRUD business application, encryption, hashing, caching, parameterization, abstraction, design patterns, and more are all applicable to problems for those kinds of applications -- they're just rarely used.

Sorry, I wasn't meaning that there aren't useful things in CS (I'm a CS graduate myself). What I meant was that the techniques for formally modeling software so that you can reason about it aren't as well developed as they are for normal engineering subjects.

Which normal engineering concepts are you saying are more formal than in CS? I had to take a "Formal Methods" course in college. Gears are loops. Switches are switches. If statements are transistors.

Also recognize that CS is a much newer science than physics. Some of what you are saying may be due to the immaturity of the science, but it doesn't mean that it isn't engineering.

I took a lot of other engineering courses including statics and dynamics, thermodynamics, electronics and courses for premed requirements and I don't see a lot of difference between computer science/engineering and biomedical engineering or civil engineering except our perception of of the physical engineering as more important -- due only to their visibility.

CS/CSE is hidden from view. People don't understand where while loops are operating, but they can see gears spinning and cables holding up bridges.

Compare typical software projects to medical software products as a niche. Much more design, time, and money is spent there than on Web 2.0 sites because lives depend on it.

I phrased that incorrectly - the techniques are all there in CS, but if anything they are too formal. It's the practical benefits of applying formal methods that are missing from general development (usually for good reasons).

Reply on news.ycombinator.com