If he wrote a book about programming, I'd buy it in a heartbeat. Too bad that even he probably is still figuring everything out.
Just read his code. It is impressive.
John Carmack discusses the art and science of software engineering
51–60 of 74 posts
Re: John Carmack discusses the art and science of software engineering
#52The quest for perfection may be futile.
DNA is also code, and it's full of bugs. That code lives for hundred of thousands of years, if not millions.
Biological processes offer the suggestion that your system can be functional in the face of constant failures and random variations in behavior.
Biology can even offer a very high reliability rate. While we get sick all the time, and people are born with all sorts of genetically disadvantageous traits, many key processes are mind-bogglingly reliable. (No sight v No sense of touch: Compare the rates of blindness to the rates of congenital analgesia type 2)
While the math behind CS offers tantalizing guarantees of reliability the reality of software development and developers deliver a reliability far lower.
I think it is a fascinating thought experiment to imagine a development process where instead of writing any code, all you're writing is tests (or feature descriptions) and let the code adapt to the environment you've defined.
Re: John Carmack discusses the art and science of software engineering
#53Richard Feynman wrote[1]: "We could, of course, use any notation we want; do not laugh at notations; invent them, they are powerful. In fact, mathematics is, to a large extent, invention of better notations. The whole idea of a four-vector, in fact, is an improvement in notation so that the transformations can be remembered easily." What he said about mathematics, I think it applies even more to programming. [1] The…
At PARC we had a slogan: "Point of view is worth 80 IQ points." It was based on a
few things from the past like how smart you had to be in Roman times to multiply two
numbers together; only geniuses did it. We haven't gotten any smarter, we've just
changed our representation system. We think better generally by inventing better
representations; that's something that we as computer scientists recognize as one of
the main things that we try to do.
Re: John Carmack discusses the art and science of software engineering
#54Running your code through static analysis can be eye-opening. And just like when you opened your eyes for the first time... you'll probably cry.
Static code analysis has a long-term benefit as well as the more obvious short-term benefit. That is, it teaches us to be better developers as we strive to have the static analysis catch less issues in our code the next time [1]. I used static analysis to improve my style for C, Python, and most recently Ruby [2]. I think it had a lasting effect on my personal coding habits. But every once in a while, I will use the…
what tool did you use for ruby?
Re: John Carmack discusses the art and science of software engineering
#55Earlier quoted context omitted.
The more you know, the more you realize you don't know. That would be a great book though.
Yep. Also, the smarter you are the more you tend to doubt yourself. Whereas less intelligent people tend to have more confidence in what they're doing. Bites me in the ass all the time.
Not saying that business people are less intelligent (far from it, good business people are as rare as good hackers). But pointing out that in the business world, confidence is a signaling mechanism for success when they speak to others outside the business field. This easily gives rise to an impedance mismatch between the business world and the technical worlds. Appropriately enough, the very best business people I know when talking about an issue their own field are just as doubtful about themselves as good technical people.
Fractal difficulty of a field is the impetus for a lot of this doubt, and it seems pretty opaque to outsiders in every field I've seen. This seems to be prevalent here when many hackers do not acknowledge the difficulty of marketing, sales, accounting, etc.
Re: John Carmack discusses the art and science of software engineering
#56Richard Feynman wrote[1]: "We could, of course, use any notation we want; do not laugh at notations; invent them, they are powerful. In fact, mathematics is, to a large extent, invention of better notations. The whole idea of a four-vector, in fact, is an improvement in notation so that the transformations can be remembered easily." What he said about mathematics, I think it applies even more to programming. [1] The…
At PARC we had a slogan: "Point of view is worth 80 IQ points." It was based on a few things from the past like how smart you had to be in Roman times to multiply two numbers together; only geniuses did it. We haven't gotten any smarter, we've just changed our representation system. We think better generally by inventing better representations; that's something that we as computer scientists recognize as one of the m…
According to this, multiplication wasn't so bad: http://turner.faculty.swau.edu/mathematics/materialslibrary/...
Re: John Carmack discusses the art and science of software engineering
#57The quest for perfection may be futile. DNA is also code, and it's full of bugs. That code lives for hundred of thousands of years, if not millions. Biological processes offer the suggestion that your system can be functional in the face of constant failures and random variations in behavior. Biology can even offer a very high reliability rate. While we get sick all the time, and people are born with all sorts of gen…
The quest for perfection may be futile.
Agreed, and I think it's easy to observe that fact with nothing more than your DNA example. In biology, perfection will always be outcompeted by "good enough."
Re: John Carmack discusses the art and science of software engineering
#58Earlier quoted context omitted.
Static code analysis has a long-term benefit as well as the more obvious short-term benefit. That is, it teaches us to be better developers as we strive to have the static analysis catch less issues in our code the next time [1]. I used static analysis to improve my style for C, Python, and most recently Ruby [2]. I think it had a lasting effect on my personal coding habits. But every once in a while, I will use the…
what tool did you use for ruby?
I mentioned that in my second footnote.
Re: John Carmack discusses the art and science of software engineering
#59Earlier quoted context omitted.
> if(obj == null && obj.isValid()) Why would you encounter this (often)? It seems to me that this code would never evaluate to true.
This is Java code. If you test for a null reference AND THEN dereference it, you get a NullPointerException. The check was supposed to be "!= null". This check is obviously erroneous, and found via SCA. I was saying "if I had a dollar for every time I found this [via SCA] I'd have a lot of money."
I'm curious as well, I understand the bug / typo, but I don't think I've seen it more than a handful in 20+ years of C-like languages (mostly game development). In contrast, typing a single '=' instead of '==' seems a more common error IME (although still not frequent enough to drive me towards Yoda conditions to catch it).
Why do you think you are encountering this particular mistake so often? Is it something about your projects, your organization, your colleagues, or Java itself?
Re: John Carmack discusses the art and science of software engineering
#60As much as I respect John Carmack, I have to say that I'm a little disappointed that he is rehashing this meme of software development not being a science... OK, wonderful, the state of the art in his shop doesn't rise to the level of being a consistently reproducible, measurable process, but that doesn't mean that this is a permanent condition or that its an insurmountable one.