Comment by ChuckMcM | Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

That was a long way to go to insult C and brag about Eiffel. Ada doesn't have this problem either but nobody is jumping up and down saying how its the one true language. Back when I was looking at Phd topics (I ended up jumping into work instead) "provably correct" code was all the rage. Lots of folks at USC-ISI were looking into proving the code expressed the specification, and the resulting executable faithfully expressed the intent of the code. End to end correctness as it were.

What struck me about that work was that invariably there was some tool you ran over the specification and the code and it implemented some algorithm for doing the work. And yet if you went that far, then you should at least be willing to run something like lint(1) and had anyone at Apple run it, or made warnings fatal (always good practice), the repeated goto would never have escaped into the wild (useless code is useless, its a warn in both GCC and Clang, and always flagged by lint).

So is the challenge the language? Or the processes? I tend to favor the latter.

> So is the challenge the language? Or the processes?

Did you finish the article? This is exactly the false dichotomy the article was about.

It's the language AND the processes.

I finished the article.

It went on and on with its point but I didn't notice anything more illuminating than the rhetoric he was peppering into his arguments half-way through.

I think Chuck's argument still just trumps this guy: Language will always have problems. You always need good process no matter what language and you can find a tool to help you get over whatever "holes" some older language might have. No amount of cursing lazy-people-unwilling-to-enter-the-21st-century or referencing WWI will make the "you need ze one language zhat does zit all" argument that much better.

Process and tools will always have problems. You will always need a good language no matter what process or tools you use. No amount of touting of process will make the "you need ze one process zhat does zit all" argument that much better.

Believe me, I know there will never be a perfect language. But this idea that we only need process is tantamount to a claim that there will be a perfect process which will solve all the problems that a better language could solve. That won't happen.

Why would you choose a crappy language and a good process when you can have a good language AND a good process? Is there something about having a good language that prevents you from having a good process?

I think the challenge is to apply a rigorous expectation to the entire system of the software development lifecycle.

- Language chosen to reflect guarantees needed to minimize error (in all axes of analysis).

- Process chosen to meet quality and auditing standards

- Hiring and team selection done based on the kind of work needed

- Deployment system chosen to reflect the user's needs

etc. You've been around. :-)

Roughly, at each juncture, choose the thing that gives the best result for the least amount of work, given the tradeoffs involved. Engineer the thing. Language & tech stack are a big component of that - but not the whole thing.

I think you have to notice that software is an iterative rather than a one-time-only affair.

Basically, some given piece of software is going to be created once and inherently have many warts.

Just an inherently, the main effort will be spent tweaking the process over time.

The thing about programming language is that it can only be made once whereas Process, training and personnel can be constantly adjusted.

> The thing about programming language is that it can only be made once whereas Process, training and personnel can be constantly adjusted.

This is why I think that language is absolutely a much more important decision than almost any decision about your process. Choosing a poor process is fixable. Choosing a poor language is forever.

Language enforces process by design. Many processes are potentially good but philosophically undesirable.

Do you favor the latter because changing the language is not an option?

More it is a mindset that I favor. Which is that tools are not an excuse for not thinking.

I was doing a machining class where the instructor related stories that the machines with the most safeguards had the most accidents, he related it to people being less careful around them. There is a lot of research around accidents at NIH and elsewhere but I've not seen a really definitive study that took up the question of risk versus user awareness.

Having a process where you always run unit tests or lint Etc has been more reliable for me in terms of avoiding programming bugs escaping into production.

The instructor's observation seems to be an example of risk compensation:

https://en.wikipedia.org/wiki/Risk_compensation

Excellent! Thanks for putting a name to it.

There was an interesting article arguing that motorcycle helmets make motor cycling more dangerous. Sure, if you have an accident, a helmet is a win. But risk compensation indicates you might be less likely to have an accident when not wearing a helmet.

> That was a long way to go to insult C and brag about Eiffel.

Ruby does what Eiffel does also. And it got the idea from it.

Reply on news.ycombinator.com