
John Carmack discusses the art and science of software engineering (2012) - hypr_geek
http://blogs.uw.edu/ajko/2012/08/22/john-carmack-discusses-the-art-and-science-of-software-engineering/
======
mathattack
"I would like to be able to enable even more restric­tive sub­sets of
lan­guages and restrict pro­gram­mers even more because we make mis­takes
con­stantly."

I like this very much. For all the talk of power in languages, we make lots of
mistakes. One underlooked decision factor in choosing languages should be,
"How hard is to make accidental mistakes?" and "How easy is it to find and fix
mistakes?"

~~~
jk4930
"In terms of software, the languages Ada and C have very different attitudes
to freedom. Ada introduces restrictions and checks, with the goal of providing
freedom from errors. On the other hand C gives the programmer more freedom,
making it easier to make errors.

One of the historical guidelines in C was "trust the programmer". This would
be fine were it not for the fact that programmers, like all humans, are frail
and fallible beings. Experience shows that whatever techniques are used it is
hard to write "correct" software. It is good advice therefore to use tools
that can help by finding bugs and preventing bugs. Ada was specifically
designed to help in this respect."

[https://www.adacore.com/adaanswers/gems/gem-30/](https://www.adacore.com/adaanswers/gems/gem-30/)

(And if even Ada is not restrictive enough, one uses Ada's subset Spark, e.g.,
[http://www.spark-2014.org/](http://www.spark-2014.org/) )

Not to say that one should use Ada (though it would often help I guess), but
this different approach to software design and maintenance ("Ada culture"[1])
is worth knowing.

[1] [http://archive.adaic.com/intro/ada-vs-c/ada-
vs-c.html](http://archive.adaic.com/intro/ada-vs-c/ada-vs-c.html)

My personal rule of thumb:

C and Scheme for explorative hacking, Ada and Haskell for reliable
implementation, Perl for teh recreational lulz.

~~~
catnaroek
> "Ada introduces restrictions and checks, with the goal of providing freedom
> from errors (...) Ada was specifically designed to help in this respect.
> [write correct software]"

And it is a huge failure. No amount of runtime checks can make your already
compiled and deployed program less wrong.

> (Taken from the Ada vs C++ comparison article) "Stroustrup (...) presents a
> use-defined vector class (...) Unfortunately, the proper implementation of
> the class requires exceptions (...)"

A proper implementation of the class requires dependent types. Runtime index
checks are effectively testing, which can show the presence of bugs, but never
their absence.

~~~
foobarbazqux
Testing does show the absence of bugs that you test for though.

------
Arjuna
Previous discussion:

[https://news.ycombinator.com/item?id=4423031](https://news.ycombinator.com/item?id=4423031)

Here is the link to the transcribed portion of the talk (starting at
00h:30m:02s):

[https://www.youtube.com/watch?v=wt-
iVFxgFWk&t=1802](https://www.youtube.com/watch?v=wt-iVFxgFWk&t=1802)

------
ghc
Carmack's aside about his 7 year old son learning to program brings up an
interesting idea: What would happen if you taught a 7 year old to program with
Haskell. I don't have any children, but I started programming at 7 so at the
very least I can conduct a thought experiment about what it would mean if
Haskell was the tool I had at my disposal instead of opaque C manuals and a
hex editor I used to hack the Mech Warrior 2 binary when I couldn't beat a
scenario.

My thoughts:

I probably would have intuitively grasped algebraic datatypes. It often
frustrated me that I could not define new things like True and False to suit
the game worlds I wanted to create.

I would have had little to know interest in math or recursion for its own
sake. I'm pretty sure I would not have done well with those.

I would have probably written almost all of my code in the IO monad, with game
rules defined outside.

Graphics programming in Haskell would have been no better than with any of the
other languages.

Overall, I don't think Haskell would have stuck. I think I would have been
easily frustrated, despite being able to structure programs better than I was
able to in Basic. For proof of this, I look to my early abandonment of C/C++
for game development (even if the manuals were pretty much terrible). On the
other hand, if I was presented a game written in Haskell (with source), maybe
the outcome would have been different. I certainly managed to use a hex editor
at that age, so if I had some goal I wanted to accomplish (like modifying the
AI of a game), I think maybe anything would have been possible.

~~~
johndl
There exists at least one UK university which uses Haskell as a teaching
language in its CS department. Not quite 7 year olds, but certainly a good
percentage of fresh programmers.

Does it result in better programmers? Perhaps. It certainly forces you to
understand recursion.

~~~
kenshiro_o
I remember learning Haskell at Imperial College London - a very nice language.
I had never tried a functional language before and just loved how "natural" if
felt after getting familiar with it. I would love to re-learn it but I am
thinking that from a career point of view I am better off learning
Scala/Clojure than Haskell.

~~~
eru
Haskell might actually be pretty useful in the long run. (Disclaimer: My whole
career so far has been spent doing OCaml and Haskell.)

------
ra88it
Carmack is this living legend of programming, hacking, making magic happen
with the computer. And yet his writing and the concepts that interest him are
often simple and approachable.

How does he manage to look at this pile of hacks with beginner's eyes? Somehow
he does, and he sees it for what it is without judging it too harshly or
prematurely. I love reading his blog.

~~~
damian2000
He's someone who knows his stuff so completely that he's able to explain it
clearly to non-programmers. I think theres a famous quote by Einstein: “If you
can't explain it to a six year old, you don't understand it yourself.”

------
taspeotis
> With the NASA style devel­op­ment process, they can deliver very very low
> bug rates, but it’s at a very very low pro­duc­tiv­ity rate

There's some more, somewhat old and non-technical, information about NASA's
software development efforts here [1].

[1] [http://www.fastcompany.com/28121/they-write-right-
stuff](http://www.fastcompany.com/28121/they-write-right-stuff)

~~~
iyulaev
Great article! As an aside, my, Fast Company has really gone down the tubes...

------
brador
Go to youtube, search 'quakecon 2013 keynote part 1'. It's a great
talk/keynote by John. One of his best.

------
gatestone
I wonder when Carmack and Rob Pike sit down and save the sw engineering
world...

------
rickjames28
I'm becoming increasingly convinced that the way forward in software
engineering isn't "better" languages like Haskell or Clojure, but with better
tooling.

I think Carmack's talk shed light on the fact that as humans we have very
limited cognitive capacities when it comes to programming and "smarter"
languages help us a bit, but we need automated, "smart" tools - like static
analysis tools.

I think of Visual Studio and Resharper and how much ReSharper finds that I can
learn from and how it frees me to concentrate on business logic.

Years ago I remember reading an article or an interview with a Sun research
scientist where she described programming of the future where languages and
tools will be much more lenient of your mistakes and programming will be much
more of a two-way conversation with your tooling.

That and tools like language work benches are the only ways I see to go
forward. Everybody using Haskell is just a modest (if that) step forward.

~~~
chongli
_programming will be much more of a two-way conversation with your tooling._

Do you have any experience programming in Haskell? I ask because this
statement exactly describes my experience with it. The language goes extremely
far down the path of "static analysis" with its type system. Couple this with
simple tools such as ghci, flymake and haskell-mode for emacs and you have a
very interactive system with an enormous amount of feedback.

