[eiffel-users] Someone should tell Lex Fridman (and John Carmack) about Eiffel and DBC, the next level "assert"
491 views
Skip to first unread message
Finnian Reilly
Oct 27, 2023, 9:35:17 AM10/27/23
to Eiffel Users
This afternoon I was listening to this interesting clip of a discussion between two famous coders talking about
- developer productivity
- debuggers (and how big companies are hostile to them because
of a Linux bias)
- language choice
- IDEs
- and the limited form of DBC you can achieve with asserts.
(The full conversation is 5 hours long)
Lex Fridman: is a Russian-American computer
scientist and podcaster. He hosts the Lex Fridman
Podcast. He is arguably a contender for the title of "most
famous nerd-podcaster in the English speaking world". He is
a friend of Joe Rogan.
John Carmack: is a legendary programmer, co-founder of id Software, and lead programmer of many revolutionary video games including Wolfenstein 3D, Doom, Quake, and the Commander Keen series. He is also the founder of Armadillo Aerospace, and for many years the CTO of Oculus VR.
Here is a lightly edited transcript of the part where Lex
declares his love for asserts.
8:55 LEX
In my private code i have asserts
everywhere. [It's] just there's something
pleasant to me, pleasurable to me about
[this] sort of dictatorial rule of like
this should be true at this point.
In too many times
i've made mistakes
that shouldn't have been made
and i would assume
i wouldn't be the kind of person that
would make that mistake but i keep
making that mistake therefore and the
assert really catches me
uh really helps all the time so my..
I would say like 10 to 20 percent of my
private code just for personal use is
probably a certain
09:32 JOHN
and they're active
comments that's one of those things that
in theory they don't they don't make any
difference to the program and if it was
all operating the way you expected it
would be then i they will never fire but
even if you have it right and you wrote
the code right initially then
circumstances change the world outside
your program changes and in fact that's
that's one of the things where i'm kind
of fond in a lot of cases of static
array size declarations where i went
through this period where it's like okay
now we have general collection classes
we should just make everything variable
because i had this history of in the
early days you get Doom which had some
fixed limits on it then everybody
started making crazier and crazier
things and they kept bumping up the
different limits, this many lines this
many sectors
uh and it seemed like a good idea well
we should just make this completely
generic it can go kind of go up to
whatever and, there's cases where that's the right
thing to do
but it also the other aspect of the
world changing around you is it's good
to be informed when the world has
changed more than you thought it would
and if you've got a continuously growing
collection you're never going to find
out. You might have this quadratic
slowdown on something where you thought
oh i'm only ever going to have a handful
of these but something changes and
there's a new design style and all of a
sudden you've got 10 000 of them
so i kind of like in many cases
picking a number, some you know nice
round power of two number and setting it
up in there and having an assert saying:
it's like hey you hit the you hit this
limit you should probably think are the
choices that you've made around all of
this still relevant if somebody's using
10 times more than you thought they would
11:12 LEX
yeah this code was originally
written with this kind of world view
with this kind of set of constraints you
were you were thinking of the world in
this way
if something breaks that means you got
to rethink the initial stuff and that's
it's nice for it to afford for it to do
Finnian Reilly
Oct 27, 2023, 9:49:31 AM10/27/23
to Eiffel Users
My youtube comment on the Lex Clips video:
Finnian Reilly
Oct 27, 2023, 9:56:44 AM10/27/23
to Eiffel Users
For some reason youtube has banned my respectful comment, even when I sorted "by newest first" I couldn't find. I tried reposting it and failed. :-(
Anders Persson
Oct 27, 2023, 11:46:49 AM10/27/23
to eiffel...@googlegroups.com
I added the same comment but removed the link. See if you can find it.
On Fri, 27 Oct 2023 at 15:56, Finnian Reilly <frei...@gmail.com> wrote:
For some reason youtube has banned my respectful comment, even when I sorted "by newest first" I couldn't find. I tried reposting it and failed. :-(
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/2440f0f8-a0f6-4218-bad7-f60c68c6bb1cn%40googlegroups.com.
Finnian Reilly
Oct 27, 2023, 12:11:23 PM10/27/23
to eiffel...@googlegroups.com
Thanks for that Anders,
I found your posted comment. Maybe
they don't like links in comments. I got an automated message
informing me that my comment was in violation of "community
standards", to which I appealed.
The ultimate nannybot !
regards
Finnian
Ian Joyner
Oct 28, 2023, 7:48:03 AM10/28/23
to eiffel...@googlegroups.com
Indeed it seems that arbitrary links to sites they don’t know about are prohibited, but links to Quora are alright. It is probably Google not wanting anyone to use their platform for advertising without paying.
I recently came across John Carmack when someone posted a link to his article on how to do functional programming in C++ and no reason to use fringe languages like Haskell or OCaml. Seems pathetic really.
http://sevangelatos.com/john-carmack-on/
Here is what I posted on the video:
What terrible advice to start with a debugger. A debugger should be the last point of call for professional well-trained programmers. It is also a symptom of programs written (coded) in C/C++, where so many obscure behaviours (unpleasant surprises) can happen.
To start with, modern programming languages that are more carefully designed to avoid pitfalls, traps, and non-orthogonalities should be used. The goal of these languages is that programmers can read the program and understand what it going on. With C++ there is too much hidden below the surface. This comes from the C dogma and trite platitude of ‘trust the programmer’. What this means is that a compiler must assume a programmer knows what they are doing and try to generate some code. That can lead to nasty surprises, and nasty surprises are the kinds of things debuggers are for. Not only can we not trust programmers because they make mistakes, but we certainly can’t trust programmers who are hackers. Checks like bounds checks must be included, not only in languages, but in platforms below any machine code or language level, so that no programmer can undermine such checks.
It is true that someone’s head might be a faulty interpreter, however C and C++ magnify that problem. As programming skills improve, both in the profession as a whole, and in individual programmers, we should get better at reading program source and understanding exactly what it does. But this depends on simple and clear languages, which C++ certainly is not.
Students learning programming can certainly be helped by visuals showing them how things work by stepping through a program. However, they should be weaned off this approach.
It certainly seems like more exciting programming — just run the damn program, have a laugh when it crashes, hack, recompile, rerun, hack again in this cycle, but it should be the cycle we get away from to do more rational development.
Those going from interpreted languages which painfully step though and crash on each problem to compiled statically-checked languages which report a whole lot of errors at once, find the extra discipline of static checking hard to understand at first. Programmers must also learn how to build logic into their programs that can be checked. However, the point is that should save time by fixing a whole lot of problems at once as well as statically testing the logic of a program. More professional reasoned development seems boring compared to the write-run-crash-hack cycle. The latter hacking programmers also look a lot more busy, although they are less productive.
Not only should the syntax of a language be clear (and C++’s is particularly arcane), but the semantics should be precise, meaning that it is stated that “this construct does exactly this”, and non-orthogonalities like having different meanings in different contexts or combinations are avoided. Pragmatic design of languages means that the language designer has gone even further and analysed the language for pitfalls and traps that a programmer might fall into. C and C++ always lacked that kind of design effort where traps and pitfalls and unexpected behaviours abound. C was not so much a design (although any formal design basis came from BCPL), but an expedience to not have to write Unix in assembler.
If the syntax, semantics, and pragmatics of a language is clear, we can still get problems that maybe require a debugger if the implementation of compiler or runtime has bugs in it. These should be reported back to the compiler/runtime vendor. In such cases the implementations do not conform to the specification of the language. However, these really are a last-thing-that-should-happen kind of bug, and usually programmers will not have to get involved at this level. Again, a debugger is a last resort, not the first port of call, but it seems to be in C++. That alone is proof that C++ is a defective and deficient language. There are also community forums where a programmer getting such an obscure problem can post, have any problem in understanding corrected, or have it confirmed that it is a vendor bug. This will help the developer get on with more important issues quickly.
Thus debuggers should be the last line of defence in modern programming, not something depended on as a crutch. And that last phrase about crutch is against those C people who claim that static checking in languages are either a crutch or aid for beginners. It is rather the opposite way around — static checking is the tool of the professional, using debuggers to make up for primitive and deficient languages is the crutch!
That is enough for now, but only the first part of my reaction to this video. I have another point of contention about the second half where it is recommended to use ‘asserts’ liberally in ‘code’.
https://www.quora.com/How-do-I-find-bugs-in-code/answer/Ian-Joyner-1
————
My second point about this video is on using assert in the second half of the video. Doing conditional checks to ensure valid states while a program is running is indeed a good thing.
However, the assert mechanism in C is a primitive checking and exception mechanism. I’m not saying it is wrong, rather that it is so important and fundamental in the development of trustworthy software that it should be integrated in a language at the core.
Like so many things in C, assert is primitive. That is there is little true semantic integration with the language and the mechanism is mostly syntactic. Primitive mechanisms are just an emulation of higher-level ideas (in fact that is how C++ started as C with Classes, just being a set of primitive #define macros https://www.quora.com/What-is-define-in-C/answer/Ian-Joyner-1).
We can do much better than just primitive asserts, with true semantic integration into a language. This is called Design by Contract (DbC):
https://www.quora.com/What-is-a-constructor-in-C-Ive-been-trying-figure-out-whats-the-difference-between-a-constructor-and-a-normal-method/answer/Ian-Joyner-1
Design by Contract not only covers run-time tests but static type checking as well, particularly the types of actual arguments passed to a routine must conform to the declared formal arguments. Good programmers will use the type-checking facilities intelligently to do as much compile-time checking as possible. Again the facilities in C and C++ are lacking, resulting in far more dependence on primitive testing and debugging. DbC is founded on formal program proof and verification techniques, but is not just a paper-based exercise, but integrated into languages for the working programmer to understand and use.
Note there are efforts to add Design-by-Contract to C and C++, but as I noted in a letter published in Communications of the ACM (December 2021), these efforts are lipstick on a pig, and very ugly, and as most things in C++ really just something hacked into Frankenstein’s monster as an afterthought and not removing anything that should have been replaced (as in structs should have disappeared with classes, pointers with references). While DbC might be new to C++, DbC is a technique that has been included in a language that has all the attributes I talked about in this and the other comment here for over 30 years. It is no fad, and has not even achieved the success of a fad — it is time it did, but we more experienced developers don’t like hype or hyping things, particularly like C and C++ have been hyped over the years, successfully installing them as fads that have ensured lock in, due to the use of programming primitives.
Design by Contract also supersedes Test-Driven Design. DbC puts the tests where they belong — in the program itself, not as a separate module. It is right that contract statements form not only documentation, but live tests, integrated with better exception handling mechanisms. TDD uses the tests while developing, but these can then be discarded or lost, or maybe used for later regression testing. Like TDD makes programmers think about what software modules must do before writing the modules, DbC also does this but in a better more integrated way. Thus DbC is TDD done right with a lot more.
https://www.quora.com/How-do-you-write-tests-before-code/answer/Ian-Joyner-1
Alan Perlis (first recipient of the ACM Turing Award for computing): “A software system can best be designed if the testing is interlaced with the designing instead of being used after the design.”
Modern programming needs to get away from the primitive mechanisms of C, or just the dressing up of C with some more advanced concepts such as classes and inheritance, and then pretending we have something modern.
While testing is important, we should cease reliance on testing. Be sure to read my other comment on this video for the related subject of why debuggers should be the last resort, not the first thing we turn to for testing programs.
Some last thoughts from John McCarthy in 1963:
“Proof checking by computer may be as important as proof generation. It is part of the definition of formal system that proofs be machine checkable. In my forthcoming paper, I explore the possibilities and applications of machine checked proofs. Because a machine can be asked to do much more work in checking a proof than can a human, proofs can be made much easier to write in such systems. In particular, proofs can contain a request for the machine to explore a tree of possibilities for a conventional proof. The potential applications for computer-checked proofs are very large. For example, instead of trying out computer programs on test cases until they are debugged, one should prove they have the desired properties.”
“This experience has led me to the conclusion that mathematical linguists have made the serious mistake in their almost exclusive concentration on the syntax and, even more specifically the grammar of natural languages.”
To start with, modern programming languages that are more carefully designed to avoid pitfalls, traps, and non-orthogonalities should be used. The goal of these languages is that programmers can read the program and understand what it going on. With C++ there is too much hidden below the surface. This comes from the C dogma and trite platitude of ‘trust the programmer’. What this means is that a compiler must assume a programmer knows what they are doing and try to generate some code. That can lead to nasty surprises, and nasty surprises are the kinds of things debuggers are for. Not only can we not trust programmers because they make mistakes, but we certainly can’t trust programmers who are hackers. Checks like bounds checks must be included, not only in languages, but in platforms below any machine code or language level, so that no programmer can undermine such checks.
It is true that someone’s head might be a faulty interpreter, however C and C++ magnify that problem. As programming skills improve, both in the profession as a whole, and in individual programmers, we should get better at reading program source and understanding exactly what it does. But this depends on simple and clear languages, which C++ certainly is not.
Students learning programming can certainly be helped by visuals showing them how things work by stepping through a program. However, they should be weaned off this approach.
It certainly seems like more exciting programming — just run the damn program, have a laugh when it crashes, hack, recompile, rerun, hack again in this cycle, but it should be the cycle we get away from to do more rational development.
Those going from interpreted languages which painfully step though and crash on each problem to compiled statically-checked languages which report a whole lot of errors at once, find the extra discipline of static checking hard to understand at first. Programmers must also learn how to build logic into their programs that can be checked. However, the point is that should save time by fixing a whole lot of problems at once as well as statically testing the logic of a program. More professional reasoned development seems boring compared to the write-run-crash-hack cycle. The latter hacking programmers also look a lot more busy, although they are less productive.
Not only should the syntax of a language be clear (and C++’s is particularly arcane), but the semantics should be precise, meaning that it is stated that “this construct does exactly this”, and non-orthogonalities like having different meanings in different contexts or combinations are avoided. Pragmatic design of languages means that the language designer has gone even further and analysed the language for pitfalls and traps that a programmer might fall into. C and C++ always lacked that kind of design effort where traps and pitfalls and unexpected behaviours abound. C was not so much a design (although any formal design basis came from BCPL), but an expedience to not have to write Unix in assembler.
If the syntax, semantics, and pragmatics of a language is clear, we can still get problems that maybe require a debugger if the implementation of compiler or runtime has bugs in it. These should be reported back to the compiler/runtime vendor. In such cases the implementations do not conform to the specification of the language. However, these really are a last-thing-that-should-happen kind of bug, and usually programmers will not have to get involved at this level. Again, a debugger is a last resort, not the first port of call, but it seems to be in C++. That alone is proof that C++ is a defective and deficient language. There are also community forums where a programmer getting such an obscure problem can post, have any problem in understanding corrected, or have it confirmed that it is a vendor bug. This will help the developer get on with more important issues quickly.
Thus debuggers should be the last line of defence in modern programming, not something depended on as a crutch. And that last phrase about crutch is against those C people who claim that static checking in languages are either a crutch or aid for beginners. It is rather the opposite way around — static checking is the tool of the professional, using debuggers to make up for primitive and deficient languages is the crutch!
That is enough for now, but only the first part of my reaction to this video. I have another point of contention about the second half where it is recommended to use ‘asserts’ liberally in ‘code’.
https://www.quora.com/How-do-I-find-bugs-in-code/answer/Ian-Joyner-1
————
My second point about this video is on using assert in the second half of the video. Doing conditional checks to ensure valid states while a program is running is indeed a good thing.
However, the assert mechanism in C is a primitive checking and exception mechanism. I’m not saying it is wrong, rather that it is so important and fundamental in the development of trustworthy software that it should be integrated in a language at the core.
Like so many things in C, assert is primitive. That is there is little true semantic integration with the language and the mechanism is mostly syntactic. Primitive mechanisms are just an emulation of higher-level ideas (in fact that is how C++ started as C with Classes, just being a set of primitive #define macros https://www.quora.com/What-is-define-in-C/answer/Ian-Joyner-1).
We can do much better than just primitive asserts, with true semantic integration into a language. This is called Design by Contract (DbC):
https://www.quora.com/What-is-a-constructor-in-C-Ive-been-trying-figure-out-whats-the-difference-between-a-constructor-and-a-normal-method/answer/Ian-Joyner-1
Design by Contract not only covers run-time tests but static type checking as well, particularly the types of actual arguments passed to a routine must conform to the declared formal arguments. Good programmers will use the type-checking facilities intelligently to do as much compile-time checking as possible. Again the facilities in C and C++ are lacking, resulting in far more dependence on primitive testing and debugging. DbC is founded on formal program proof and verification techniques, but is not just a paper-based exercise, but integrated into languages for the working programmer to understand and use.
Note there are efforts to add Design-by-Contract to C and C++, but as I noted in a letter published in Communications of the ACM (December 2021), these efforts are lipstick on a pig, and very ugly, and as most things in C++ really just something hacked into Frankenstein’s monster as an afterthought and not removing anything that should have been replaced (as in structs should have disappeared with classes, pointers with references). While DbC might be new to C++, DbC is a technique that has been included in a language that has all the attributes I talked about in this and the other comment here for over 30 years. It is no fad, and has not even achieved the success of a fad — it is time it did, but we more experienced developers don’t like hype or hyping things, particularly like C and C++ have been hyped over the years, successfully installing them as fads that have ensured lock in, due to the use of programming primitives.
Design by Contract also supersedes Test-Driven Design. DbC puts the tests where they belong — in the program itself, not as a separate module. It is right that contract statements form not only documentation, but live tests, integrated with better exception handling mechanisms. TDD uses the tests while developing, but these can then be discarded or lost, or maybe used for later regression testing. Like TDD makes programmers think about what software modules must do before writing the modules, DbC also does this but in a better more integrated way. Thus DbC is TDD done right with a lot more.
https://www.quora.com/How-do-you-write-tests-before-code/answer/Ian-Joyner-1
Alan Perlis (first recipient of the ACM Turing Award for computing): “A software system can best be designed if the testing is interlaced with the designing instead of being used after the design.”
Modern programming needs to get away from the primitive mechanisms of C, or just the dressing up of C with some more advanced concepts such as classes and inheritance, and then pretending we have something modern.
While testing is important, we should cease reliance on testing. Be sure to read my other comment on this video for the related subject of why debuggers should be the last resort, not the first thing we turn to for testing programs.
Some last thoughts from John McCarthy in 1963:
“Proof checking by computer may be as important as proof generation. It is part of the definition of formal system that proofs be machine checkable. In my forthcoming paper, I explore the possibilities and applications of machine checked proofs. Because a machine can be asked to do much more work in checking a proof than can a human, proofs can be made much easier to write in such systems. In particular, proofs can contain a request for the machine to explore a tree of possibilities for a conventional proof. The potential applications for computer-checked proofs are very large. For example, instead of trying out computer programs on test cases until they are debugged, one should prove they have the desired properties.”
“This experience has led me to the conclusion that mathematical linguists have made the serious mistake in their almost exclusive concentration on the syntax and, even more specifically the grammar of natural languages.”
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/1fa5ac27-298b-934a-3389-d98e6dc2384b%40eiffel-loop.com.
Bertrand Meyer (from phone)
Oct 28, 2023, 8:13:08 AM10/28/23
to eiffel...@googlegroups.com
So apposite. Are we in 1980 or what? Do these people ever pay attention to serious existing work?
With best regards,
-- Bertrand Meyer
(Sent from phone, apologies for curt style & possible typos.)
On Oct 28, 2023, at 13:48, Ian Joyner <joyne...@gmail.com> wrote:
Indeed it seems that arbitrary links to sites they don’t know about are prohibited, but links to Quora are alright. It is probably Google not wanting anyone to use their platform for advertising without paying.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/BF7A8949-8D47-4D9F-A7C8-4E3924B4D3EE%40gmail.com.
Ian Joyner
Oct 28, 2023, 6:42:41 PM10/28/23
to eiffel...@googlegroups.com
They deliberately ignore serious work into software development techniques because it would blow apart their power base in the cult of C and C++.
Ian
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/C4F8EFAE-D250-470B-9B47-17012D980FAF%40inf.ethz.ch.
Ulrich Windl (Google)
Oct 29, 2023, 2:41:52 PM10/29/23
to eiffel...@googlegroups.com
Well,
considering these levels:
* Programming-time checking (maybe that's what test-driven design is about)
* Compiling-time checking (incompatible type)
* Runtime-checking (array Index out of bounds)
* CPU or hardware checking (“bus error “)
I think the goal is to move the checking "up". That way the code to generate would be more compact and more efficient (because most checking had been done already).
Unfortunately the code generated by current Eiffel is not very efficient.
Maybe that's the reason why people actually go back to C or C++.
Regards,
Ulrich
considering these levels:
* Programming-time checking (maybe that's what test-driven design is about)
* Compiling-time checking (incompatible type)
* Runtime-checking (array Index out of bounds)
* CPU or hardware checking (“bus error “)
I think the goal is to move the checking "up". That way the code to generate would be more compact and more efficient (because most checking had been done already).
Unfortunately the code generated by current Eiffel is not very efficient.
Maybe that's the reason why people actually go back to C or C++.
Regards,
Ulrich
Finnian Reilly
Oct 29, 2023, 5:25:36 PM10/29/23
to eiffel...@googlegroups.com, Bertrand Meyer (from phone)
Hi Prof.
I think it might be worth reaching out
to Lex and see if he would be interested in having you as a guest
to discuss alternative perspectives on writing good software.
With 3.3 million subscribers it would certainly be welcome
publicity for Eiffel. Lex strikes me as someone who is always
interested to explore new perspectives.
Here is the application form to pitch a
new guest or suggestion for the Lex show.
If you like I would be happy to make a
pitch for you
regards
Finnian
Reply all
Reply to author
Forward
0 new messages