Comment by anon9001 | Hacker News Reader

Comment by anon9001 | Hacker News Reader

Parent Full thread

That's a pretty bad example because any good programmer will have at least a rough idea how to profile code in their environment.

Can you name any software that's "engineered"? I can't. All software is built by craftsman of varying degrees. Nobody sits down and engineers anything up front.

The original point "agile" was that code is an iterative craft, so everybody should get together and work toward incremental improvements and respond to change, rather than try to engineer the whole project upfront. In other words, the way software is "supposed" to be built in most places these days is explicitly the opposite of engineering.

* Individuals and interactions over processes and tools

* Working software over comprehensive documentation

* Customer collaboration over contract negotiation

* Responding to change over following a plan

Doesn't sound like "engineering" to me, and that's the process with the most adoption (even though it's bastardized now, that's still the idea that's being sold).

> Can you name any software that's "engineered"?

Most compilers. GPS and mapping systems. Basically, software whose core operation founded on well understood data structures and algorithms.

No doubt there is heuristic fiddling around the user interface and that's not engineering, but the core of plenty of software ought to be well engineered.

I'm interested. Could you elaborate on "most compilers", with a specific compiler, and how it is "engineered"?

Although much care and thought goes into compilers, and they are related to discrete mathematical models (though, more descriptive than prescriptive for hand-written recursive descent parsers; unlike the central PDEs in some engineering), there is much tweaking for efficiency and especially for helpful error messages. I would describe that as "crafted" (though "engineering" has some crafting too).

Even something like diff, based on longest common subsequence, is full of ad-hoc tweaks to give excellent performance on typical real-world input, much better than theoretical complexity. (I mean the specialization that is in addition to the general optimization in the implemementation of the algorithm.)

I suppose your concept of "core operation founded on well understood data structures and algorithms" is the best we can hope for.

CompCert is the most extreme example of course given it's fully verified and the strictness required entails a high level of attention to details. Almost every compiler will be based on graph or tree transforms; Haskell and Rust are both engineered around reduction to intermediate, lower-level languages.

I don't think the tweaks you mention necessarily negate the core engineering, unless the system is completely unusable without them or they define more of the behaviour than the core itself.

Edit: for an analogy, consider whether the ergonomics of where buttons are placed on the dashboard of a car suddenly negate the fact that the car is engineered. That seems silly right? Any number of performance or other tweaks can be made to a car and not negate its engineeried quality, until you start compromising the actual operation of the car itself, like swapping out wheels for a tank track, or something like that.

Thanks, I was thinking of more used languages, such as c, python, java, javascript (they'd have greater need of good engineering, wouldn't they?).

I don't know Haskell or Rust well enough to appreciate their compiler engineering (and haven't heard of CompCert). But I might have a look at their source - I have a long-term project about tree transforms ATM and hadn't thought of looking at what compilers do (even though I was aware of Knuth's attribute grammars).

Yeah, nah, I think your "core operation" is a reasonable definition, both as primary function, and as the basic design (despite crafted tweaks atop).

Reply on news.ycombinator.com