A longstanding GnuTLS certificate validation botch
A longstanding GnuTLS certificate validation botch
Posted Mar 11, 2014 21:13 UTC (Tue) by nybble41 (subscriber, #55106)In reply to: A longstanding GnuTLS certificate validation botch by ms-tg
Parent article: A longstanding GnuTLS certificate validation botch
> drift towards language wars, rather than towards modern ideas about
> unit testing, software composability, test-driven development, and
> code coverage tracking.
These "language wars", as you put it, are pretty much all about modern ideas regarding unit testing, composability, test-driven development, and code coverage tracking. Specifically, they're about encouraging the development and use of languages which make such things easier and more reliable, and thus more likely to be implemented.
Posted Mar 11, 2014 23:47 UTC (Tue)
by pizza (subscriber, #46)
[Link] (5 responses)
I believe the point nybble41 was attempting to make is that test-driven development (and other such "modern" ideas) is independent of the underlying language used. (Look at GPSd for a case of TDD applied to a primarily-C project)
No amount of "encouragement" will make higher-level languages suitable for system/low-level tasks -- the features (reflection/introspection, dynamic compilation, "package repository") that make those languages more easily testable at the module level make them unsuitable for low-level tasks.
Posted Mar 12, 2014 3:28 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
I think you meant "ms-tg" rather than "nybble41".
While I agree that these concepts are equally applicable to any language, even C, my point was that the proper choice of language can significantly reduce the testing burden by making stricter guarantees regarding the behavior of the program at compile-time. Speaking as someone who works with system-level C code on FAA-certified embedded systems, C just give you way too much rope to hang yourself with, and it shows in the amount of testing required to obtain full coverage.
As for not being able to do "system/low-level tasks" in high-level languages, I think the authors of House[1] and Kinetic[2] would disagree. While these two OS projects are not written entirely in Haskell, neither is the Linux kernel written entirely in C. Certain core operations require lower-level access to the system, via C and/or assembly, but drivers, network stacks, window systems, and command shells seem "low-level" and "system" enough to me.
[1] http://ogi.altocumulus.org/~hallgren/ICFP2005/house.pdf
Posted Mar 12, 2014 17:50 UTC (Wed)
by ms-tg (subscriber, #89231)
[Link]
Considering the *vast* quantity of C language code that makes up the modern software stack which was developed outside the culture of unit testing, can't I please persuade you (and others reading, perhaps) that by putting your language suggestions on a separate track, the community might optimize its efforts to introduce test coverage the vast bulk of our linux software?
For example, I suspect that the reason "C culture" seems impervious to adopting the lessons of test-driven development has a lot to do with the masses of developers who are interested in it, by following your advice, are moving to other languages and practicing it there.
In other words, by complecting the issue of unit testing and test coverage with the choice of language, are we not actively *contributing* to the continuing absence of these ideas from C culture, and thus from the bulk of our existing systems?
Food for thought, at least, I hope!
Posted Mar 12, 2014 18:00 UTC (Wed)
by ms-tg (subscriber, #89231)
[Link]
Yes, thank you, exactly!
> No amount of "encouragement" will make higher-level
This may be true, but I think it's worse than that.
Based on the comments here and elsewhere on the web, it
This suggests a self-reinforcing phenomenon where the
Couldn't one argue that the choice to advocate
(apologies for the length of this rant ;)
Posted Mar 12, 2014 18:10 UTC (Wed)
by ms-tg (subscriber, #89231)
[Link] (1 responses)
I think this is the HEAD version of the build file for GPSD:
Not for nothing, but:
Perhaps I am confused, but it doesn't appear to me that even GPSD is doing these things. Please help me out if I've missed it!
Posted Mar 14, 2014 22:03 UTC (Fri)
by jkt_ (guest, #90352)
[Link]
A longstanding GnuTLS certificate validation botch
A longstanding GnuTLS certificate validation botch
[2] http://intoverflow.wordpress.com/kinetic/
A longstanding GnuTLS certificate validation botch
> to any language, even C, my point was that the proper
> choice of language can significantly reduce the testing
> burden
A longstanding GnuTLS certificate validation botch
> > and use of languages which make such things easier and
> > more reliable, and thus more likely to be implemented.
>
> I believe the point nybble41^H^H^H^H ms-tg was attempting
> to make is that test-driven development (and other such
> "modern" ideas) is independent of the underlying language
> used. (Look at GPSd for a case of TDD applied to a
> primarily-C project)
> languages suitable for system/low-level tasks -- the
> features (reflection/introspection, dynamic compilation,
> "package repository") that make those languages more
> easily testable at the module level make them unsuitable
> for low-level tasks.
seems like there's a widespread message that one must
leave the C language in order to adopt modern ideas about
testing and test coverage!
majority of the folks interested in learning test-driven
development leave the C language to do it! And therefore,
the bulk of our existing C code remains inadequately
covered by automated tests, and continues to be written
in ways that make coverage difficult to add.
for a modern type system (Haskell, ML, Rust, etc), when
the immediate issue is that C code has no test coverage,
is a textbook example of "The Perfect is the Enemy of the
Good"?
A longstanding GnuTLS certificate validation botch
http://git.savannah.gnu.org/cgit/gpsd.git/tree/SConstruct
1. Where is the build target that that runs all the tests?
2. Where is the target that generates coverage stats?
3. Is there a link to where Travis CI, or another automated
system, is running the tests on each commit?
A longstanding GnuTLS certificate validation botch