Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming Ruby Software

'Pragmatic Programmer' Author Andy Hunt Loves Arduino, Hates JavaScript (bestprogrammingbooks.com) 185

Posted by EditorDavid from the authors-vs-languages dept.
Andy Hunt is one of the 17 software developers who wrote the Agile Manifesto, and he co-authored The Pragmatic Programmer. Now Slashdot reader cerberusss writes: In an interview with Best Programming Books, Andy Hunt mentions he "hates languages that introduce accidental complexity, such as JavaScript -- what a nightmare of pitfalls for newbies and even seasoned developers... My go-to languages are still Ruby for most things, or straight C for systems programming, Pi or Arduino projects." Furthermore, he mentions that "I tend to do more experimenting and engineering than pure code writing, so there's occasionally some soldering involved ;). Code is just one tool of many."
Andy writes that he also likes Elixir, talks about Agile, reveals how he survived his most challenging project, and says the biggest advancement in programming has been the open source movement. ("Imagine trying to study chemistry, but the first half of the elements were patent-protected by a major pharma company and you couldn't use them...") And he also answered an interesting follow-up question on Twitter: "Do you feel validated in an age of Node and GitHub? Some of your best chapters (scripting and source control) are SOP now!"

Andy's reply? "We've made some great progress, for sure. But there's much to be done still. E.g., You can't ship process."
This discussion has been archived. No new comments can be posted.

'Pragmatic Programmer' Author Andy Hunt Loves Arduino, Hates JavaScript More

'Pragmatic Programmer' Author Andy Hunt Loves Arduino, Hates JavaScript

Comments Filter:

  • "Beware.. (Score:4, Insightful)

    by LesserWeevil ( 4776371 ) on Saturday April 15, 2017 @02:41PM (#54240811)
    ..programmers with screwdrivers" a mentor of mine in SW engineering once said. I've largely ignored that dictum, as a more problematic group is programmers who have no idea what a screwdriver (or soldering iron) is for. Programs exist to interface with the real world in some way, and understanding the larger (sometimes analog or wetware) view can make the difference between an elegant, but useless, piece of code and something that changes the world.
    • When I was on the Google IT help desk in 2008, I had to walk a newly hired Stanford CS graduate through the process of turning on his own workstation because no one was standing around to turn it on for him. I had to explain to him that a cubicle farm wasn't a computer lab at the university. I've been reassured by various Slashdotters that CS students are not required to learn about hardware much less how to turn them on.

  • Well that makes sense (Score:5, Insightful)

    by Kethinov ( 636034 ) on Saturday April 15, 2017 @02:49PM (#54240829) Homepage Journal

    Because of course one of the people involved in creating one of the worst management fads ever would also join the JavaScript hate train.

    "The Pragmatic Programmer." Hardly. Real pragmatism is recognizing that popular languages are often the best tool for the job, no mater how aesthetically distasteful they are.

    Ever notice how prolific JS users rarely defend the language? Of course it's badly designed. We use it because it's pragmatic to use the lingua franca of programming.

    What isn't pragmatic is using languages with declining market share because they feel aesthetically "better," or imposing horrible management fads like Agile/Scrum on your team against their will.

    So I'll pass on joining this guy's fan club.

    • Re: (Score:2, Insightful)

      by MightyMartian ( 840721 )

      Javascript is a horrible piece of shit, as a language and as a library set. It's dominance exists because of a bit of a historical accident. Everyone knows it is an utter garbage language, which is why so much effort is put into languages like Go, as a means to achieve reasonable web functionality without having to put up with that steaming pile of shit.

      • This. The only reason JS is a thing is because browsers run it natively.

        I'm dying for something like WebAssembly to take over.

        • The official WebAssembly FAQ [webassembly.org] throws shade at that attitude.

          Is WebAssembly trying to replace JavaScript?

          No!

          It goes on to say that WebAssembly is meant to encourage hybrid stacks.

          It's much more likely the end result will be an ecosystem similar to Node.js, where some stuff is in JS, and other stuff is in native node modules.

          • Don't buy it. If WA takes off and saner languages can be compiled to run on the web it will inevitably end up happening. Give it DOM access and wait a while.

            • That seems unlikely. I'm not aware of any efforts to get something other than JS writing directly to the DOM via wasm. That would be a loooooot of DOM APIs that would have to be replicated in Java or whatever.

              Besides, by the time something other than JS has full DOM access, ES7, ES8, ESwhatever will be out and JS will have slowly evolved into a usable language, eroding the appeal of switching to something less popular because the aesthetic differences won't be so vast anymore.

              • You don't need to replicate anything. If an alternative appears, in time, it will just happen - the nature of the web is being constantly rewritten or abandoned altogether.

          • Ugh. Too much "leveraging".

      • Me: "Nobody denies JavaScript is aesthetically distasteful. But you don't pick the best tool for the job based on aesthetics."

        You: "But JavaScript is aesthetically distasteful!"

        k.

    • Re: (Score:2)

      by johnw ( 3725 )

      We use it because it's pragmatic to use the lingua franca of programming.

      Hardly a lingua franca - JavaScript is used because it's the only language web browsers understand.

      I've used a lot of programming languages, and I've spent quite a bit of time trying to learn how to write clean JavaScript. It can be done, but the language really doesn't help. You have to fight it every step of the way - a better designed language would help you, not hinder you.

      If a decent alternative to JS were suddenly to be supported by all the major browsers, the rush to get away from it would be immen

      • Reading this, I'm thinking back to the early '80s when COBOL could be described exactly the way you are talking about Javascript.

        Now, we're 30+ years later and people who have experience with COBOL (and the systems/tools that work with it) are in hot demand because of applications that won't die.

        In 30 years, will we see the same need for programmers that understand how Javascript is programmed and can support the applications that were written in it?

        • Doubt it. COBOL was used for banking enterprise applications, the type that will run and be supported for years.

          The main use of JS is web sites - they're either constantly being rewritten or abandoned after a few years.

        • I'm not so sure. COBOL was, and still is used heavily in a helluva of mission critical applications, particular in major financial systems. If there's a modern day equivalent to COBOL, it's Java, not Javascript. While Javascript is certainly going to be around for a while, if it is supplanted, I think it will be more like Flash.

      • Hardly a lingua franca

        It's the world's most popular programming language, so yeah, it's a lingua franca.

        If a decent alternative to JS were suddenly to be supported by all the major browsers, the rush to get away from it would be immense.

        No doubt. But I'm not gonna wait around for that. Gonna use the lingua franca in the mean time.

        • It's the world's most popular programming language, so yeah, it's a lingua franca.

          Not likely - Java and C++ would still contend that podium. It is one of the most popular languages in the world though but, again, only because there's no other choice when developing for the web.

          • Did you miss the numerous articles like this published over the past few years? https://arc.applause.com/2016/... [applause.com]

            Seems pretty clear JS hit the popularity tipping point already. It's the world's most popular programming language. (For better or worse.)

            • Only if your one source is Stack Overflow. TIOBE [tiobe.com] and PYPL [github.io] still have other languages ranking higher.

              Again: i don't want to underplay how popular JS is nowadays. But "world's most popular programming languages" is highly debatable.

              • Dunno man, this feels kinda like the climate change "debate" to me. Sure you can cherrypick data sets that show JS isn't quite there yet, but there seems to be a growing consensus that JS has already hit that tipping point. And if miraculously everyone is wrong about that, it won't be long before even the most stubborn surveys have to admit JS hit that tipping point. The momentum is rather obvious.

              • ... highly debatable.

                For web frontends?

        • It's the world's most popular programming language

          "Most widespread" or "most used" does not mean "most popular." Plenty of people who hate it still use it.

      • I think the issue is that "clean" is in the eye of the beholder. It looks very different in OOP than it does in FP, both of which are pretty well supported paradigms in JS. Seems like the real argument is that JS doesn't make these decisions for you, so you don't get much guidance. That's certainly a speedbump, but it's also a feature, in that it is eminently flexible in the face of new paradigms.

        • Re: (Score:2)

          by johnw ( 3725 )

          I think the issue is that "clean" is in the eye of the beholder.

          Sounds good, but utterly untrue. There are plenty of objective criteria by which the clean-ness of code can be assessed. Yes, you get beginner programmers who take an attitude of "That's your way; this is my way - we're both entitled to our opinion." but unless they shed that view point they'll never become competent.

          The fact is that to achieve even something as simple as an encapsulated module of code which won't clash with anyone else's code, if you're working in JavaScript you have to jump backwards th

          • Re: (Score:2)

            by reanjr ( 588767 )

            I do not understand what is hard about encapsulating code. There are no hoops. Module encapsulation just works. What am I not understanding? // readval.js
            module.exports = () => 42; // other.js
            const readval = require("./readval");
            const otherreadval = require("someone-elses-readval");
            console.log(readval());
            console.log(otherreadval());

      • Hardly a lingua franca - JavaScript is used because it's the only language web browsers understand.

        And French was the Lingua Franca for awhile because Francs was a dominant country, and English has been Lingua Franca for awhile because Great Britain and then the US became dominant counties...

        The phrase "lingua franca" means it's in common, widespread use and it's easy to find someone who speaks it. It does not imply excellence of any sort. If you guys want to fight about something, maybe you could th

    • I've found that management fads are typically only as bad as the managers who impose them on their employees.

    • Re: Well that makes sense (Score:4, Insightful)

      by reanjr ( 588767 ) on Saturday April 15, 2017 @03:18PM (#54240939) Homepage

      I will defend Javascript to pretty much anyone. All languages suck in various ways. Javascript at least has the sense to keep the language small, backwards compatible, and well defined. New language features are almost always targeted, useful improvements, with clear use cases. And it's fast as fuck (not really because of anything related to the language, of course, but still).

      • > I will defend Javascript to pretty much anyone.

        Did you learrn nothing from BASIC in the 70's and 80's??? Only amateurs think misspelling a variable name without throwing an error is somehow "acceptable".

        When you are forced to use hacks like this "magic number" ...

        "use strict";

        ... where you can't disable strict mode, or worse, turn it off for only one function, you quickly see why it is shitty language.

        • If you can't be bothered to use professional tools which glaringly highlight misspelled variables, then perhaps you should stick with something with more hand holding. I've never really felt compelled to "use strict", because I - as a developer - have discipline, and don't need it.

      • Its single threaded, despite what node.js developers will tell you.

        • While the code you write is running single threaded, that's only the programming model; the program you create with that code is decidedly multi-threaded. The truth is it's easier to write properly multi-threaded code in Node.js for the vast majority of real world use cases, and for everything else, you can write multi-process code with good language support built right in.

      • Re: Well that makes sense (Score:5, Insightful)

        by UnknownSoldier ( 67820 ) on Saturday April 15, 2017 @05:00PM (#54241285)

        > All languages suck in various ways.

        Except JavaShit sucks worse. It was designed by a fucking moron in 10 days. [computer.org]

        JavaShit likes to masquerade it has native arrays but we can quickly dispel that notion via these tests:

        console.log( typeof 1 ); // native integer type
        console.log( typeof Math.PI ); // native constant floating-point number
        console.log( typeof "Hello World" ); // native string
        console.log( typeof [] ); // native array, right?
        console.log( typeof [] == "array" ); // sarcasm, this should work, right?
        console.log( Array.isArray( [] ) ); // Why is this needed??

        Which produces this output:

        "number" // OK -- so both integers and floating-point are treated the same way
        "number" // OK -- so both integers and floating-point are treated the same way
        "string" // OK
        "object" // Wut?? Why is Array returning object??
        false // There is no native array in JS
        true // WTF is the point of having a broken typeof if it doesn't work for arrays???

        How does JavaShit define concatenation with arrays? I mean, that isn't too hard to fuck up, right?

        console.log( [1,2] + [3,4] );
        console.log( typeof ([1,2] + [3,4]) );

        Out of the the 4 possibilities for a return type ...

        * The array [4,6] which is Vector or Matrix addition
        * The array [1,2,3,4] which is concatenation like [1,2].concat( [3,4] );
        * undefined -- Gee, one would think this would be expected, or
        * Throw an exception -- maybe even this one.

        ... guess what JavaShit does? It does a 5th retarded thing -- string concatenation!!

        "1,23,4" // <b>WTF!?!?!</b> Who is the fucktard that thought this would be reasonable??
        "string" // <b>WAT!?!</b> Idiotic type conversion to string!?

        --
        Only a complete and fucking moron defends JavaShit.

        • Idiosyncratic? Sure. But it takes literally an afternoon to learn the entire language. Unless you're a moron.

        • Here's a quick study guide, if this is too hard to mentally map type checks:

            * if it's a degenerate value, such as null or undefined, use ===
            * if it's a scalar like a number or string, use typeof
            * if it's an object (yes an array is an object), use instanceof for classically inherited types (which includes all buit-in types), and isPrototypeOf for prototypally inherited types.

        • Re: Well that makes sense (Score:4, Insightful)

          by Raenex ( 947668 ) on Sunday April 16, 2017 @03:26PM (#54245831)

          It was designed by a fucking moron in 10 days. [computer.org]

          So the "moron" designer was given 10 days to come up with a language that met marketing requirements, and he delivered, and beat Java (applets) at its own game. Not only that, he slipped [amazon.com] in some advanced programming features that still makes the language relevant today. From your link:

          "Although the schedule and constraints might have been impossible for most programmers, Eich had a long history of building new programming languages, starting from his experience as a student at the University of Illinois, where he built languages just to experiment in syntax. At Silicon Graphics, he created languages that could be used to build extensions for network monitoring tools.

          Clearly, building "yet another" language wasn't the hard part for Eich--the hard part was producing a rich and powerful language while being prohibited from using the object-oriented syntax reserved for Java. He wanted to embed advanced features in JavaScript without using language syntax so the language would initially appear simple and lightweight, yet sophisticated programmers would be able to exploit its underlying power.
          Like many other languages, Java-Script took its basic syntax from the C language, including curly braces, semicolons, and reserved words. It was to be a light, friendly version of C with simpler semantics and better dynamic memory characteristics. Because a typical webpage's lifetime lasted from a few seconds to a few minutes, JavaScript could take a very simplified approach to concurrency and memory management.

          Eich built a simplified object model that combined structs from the C language, patterns from SmallTalk, and the symmetry between data and code offered by LISP. The Hypercard event model inspired the pattern for adding events to the HTML document. Object-oriented patterns were possible but via runtime semantics with prototypes (as in Self) instead of compiler-supported class syntax (as in Java and C++."

      • Re: (Score:2, Flamebait)

        by UnknownSoldier ( 67820 )

        > All languages suck in various ways.

        Except JavaShit is brain dead.

        Any JS programmer worth their salt uses the triple equality test, ===, because JavaShit fucked up the normal equality comparison test, ==, due to unwanted type conversions -- one ends up with this retarded operator comparison [github.io] table.

        if( 0 == "0" ) console.log( "equal" );
        if( 1 == "1" ) console.log( "equal" )
        console.log( false == "0" );
        console.log( "0" == false );
        console.log( true == "1" );
        console.log( "1" == true );

        Which produces this

        • So, if you have no use for a sloppy equality test, why would you use it? I personally can't remember the last time I've used it, but having an operator I never really have a use for has never once impeded my ability to get shit done. Do you have some sort of arthritis that makes that third "=" painful to type, or is the arthritis in your head?

        • If you don't know what types you're working with, why don't you just cast them?

          String(a) + String(b) or Number(a) + Number(b) is pretty easy.

          If you're arguing that JS exposes you to your own sloppy conventions, then I agree.

        • Re: K&R, just pretend you're at a REPL. If what you're doing would confuse a REPL, then it's not going to work as expected in JS.

          That said, very little JS uses K&R for anything because it is an absolute mess when you start using inline callbacks. If you want to be a special snowflake, then you can use whatever format you like by using a var/const instead of a literal, but perhaps you should get over yourself and just do it the "normal" way.

      • Re: (Score:2)

        by e r ( 2847683 )

        And it's fast as fuck...

        Wrong [debian.org].

    • We use [Javascript] because it's pragmatic to use the lingua franca of programming.

      LOL, bless your heart.

      You just go right on thinking that and having fun playing in your browser sandbox.

      Pay no mind to all the C/C++ that implements that browser, and the server daemon on the other end, and the operating systems they both run on, and the libraries your code ends up calling to actually accomplish anything....

    • Re: (Score:2)

      by dfghjk ( 711126 )

      Nailed it.

    • JS is a lingua franca but its a very bad one. It wouldn't be so bad if the language had actually been designed and was consistently implemented.

      That being said our industry never learns. We dealt with termcaps and incompatible ChUI terminals in the 80's, odd and/or incompatible desktop graphics capabilities thru the 90's followed by browser incompatibilities and now vastly different JS engines. You would think the industry would eventually figure out that taking decades to establish baseline standards for

    • Real pragmatism is recognizing that popular languages are often the best tool for the job, no mater how aesthetically distasteful they are.

      The only reason Javascript is the "best tool for the job" is because it's the only tool available. If you only have a hammer, every problem looks like a nail, and that describes Javascript perfectly. MFC was the the best choice for windows UIs for a long time, so I used it, but it still sucked (and still does suck).

      So I'll pass on joining this guy's fan club.

      That's fine.

  • What nightmare of pitfalls? (Score:4, Insightful)

    by hey! ( 33014 ) on Saturday April 15, 2017 @02:56PM (#54240867) Homepage Journal

    Over the years I've come to realize that programming languages aren't standalone beasts. When you pick one, you get a lot of other stuff along with it: common libraries and frameworks, runtime systems, problem domains, communities of programmers who do things a certain way, and the sources where most people learn them. That last bit is not to be overlooked, one of the best features of C is The C Programming Language.

    As for pitfalls for newbies -- I think that's the browser, not Javascript. Javascript seems pretty straightforward in Node.

    • It's both because Javascript developed in 10 days (Score:5, Informative)

      by raymorris ( 2726007 ) on Saturday April 15, 2017 @03:09PM (#54240909) Journal

      As someone else said, often Javascript is the right tool for the job, because the job is manipulating DOM elements in a web browser.

      A major new future in Netscape 2.0 was that it had Scheme embedded, for scripting. Ten days before the public beta, it was decided that the Scheme effort couldn't be salvaged - it just wouldn't work. But Netscape's hype had promised embedded scripting. So in ten days Brendan Eich designed, coded, tested, and integrated Javascript. 10 days for all of that means he had about two days to design the language. It shows. Other languages have had years, or at least months, of design. Javascript had about two days. Eich did an amazingly good job, for weekend design project.

      Obviously Javascript has matured a bit since then, but its origin as the mother of all all-nighters, the crashiest of all crash projects, still shows in its design, its inconsistent naming of functions, etc.

      • often Javascript is the right tool for the job

        Eh... right tool, or only tool?

      • Re: (Score:2)

        by hey! ( 33014 )

        It's funny that you mention that, because I was going to say that Javascript is a lot better if you program in it as if it were Scheme than if you try to program in it as if it were Java.

        The inconsistent naming of functions makes the same point I was making: that's not a language problem, it's an API problem. If you take Javascript out of the browser and put it into a freshly designed runtime environment (e.g., Node) that aspect of the language experience goes away.

        Another language that "has" this problem

        • Re: (Score:2)

          by doom ( 14564 )

          In the case of R, there's a sub-universe of it's own using the Hadley Wickham (and his cohorts) packages tidyr and so on. If you buy into the hadleyverse (he prefers the name tidyverse).

          I'm particularly interested in the new packages for reading data readr and readxl, which are supposed to be much faster with saner defaults. The old read packages had a habit of treating all strings as though they're a database enumerated type, it would try to "tokenize" everything on the fly...

          I think what you're tal

  • Accidental complexity (Score:4, Informative)

    by Dutch Gun ( 899105 ) on Saturday April 15, 2017 @02:58PM (#54240873)

    A number of newer languages are embracing the idea of protecting the programmer from doing the wrong thing by accident, and I welcome this trend.

    Even though I enjoy my occasional work with Python, the other day I accidentally forgot to explicitly reference a specific variable from a returned tuple, the error code I wanted to check against. Python happily let me compare tuple_value != 0 without complaint. While it may be possible to conceive of a situation in which a programmer MIGHT want to compare a tuple against an integer, it seems like 99% of the time, it would be best to throw an error, and force the programmer to do such an operation explicitly, rather than assuming it was intentional. It would have saved me a lot of hassle had this operation not been permitted. So, just one example there.

    JavaScript has a lot of similar issues, from what I understand, such as weak scoping rules, global by default, no namespaces, and overly-generous implicit type coersion. All these things seem to work against the programmer, even if they were originally designed as conveniences.

    It's really a shame that "what we have" for the web is JavaScript, so it's sort of impossible to work in web and ignore it. In my particular industry, "what we have" is C++. I'm not sure whether I should feel fortunate or not compared to web programmers. C++ has it's own particular nightmare of complexity, but the good news is that with C++, you can protect yourself from stupid mistakes with enough self-discipline, and the language has improved remarkably in the last 6 years.

    • Weak scoping rules? How do you differentiat between strong and weak scoping? Either an identifier is in scope or it's not.

      • Re: (Score:2)

        by mikael ( 484 )

        I believe it is to do with web browser clients connecting to remote servers and making transactions:

        http://knowledgebase.progress.... [progress.com]

      • Re: Accidental complexity (Score:5, Informative)

        by UnknownSoldier ( 67820 ) on Saturday April 15, 2017 @05:28PM (#54241417)

        In JavaShit, variables can be used ANYWHERE in a function, even outside their _expected_ scoping.

        For example, weak scoping:

        function foo()
        {
            for( var i = 0; i < 3; i++ )
            {
                var bar = 42 + i;
                console.log( bar );
            }
         
            bar = 99; // An error in any sane language but JavaShit was designed by an moron so this is OK.
         
            bat = 99; // typo, but this OK in non-strict mode too, because JS is the new BASIC.
        }

        In contradistinction to C++ which has strong scoping:

        void foo()
        {
            for( auto i = 0; i < 3; i++ )
            {
                auto bar = 42 + i;
                printf( "%d\n", bar );
            }
         
            bar = 99; // ERROR: 'bar' was not declared in this scope
         
            bat = 99; // ERROR -- compiler catches this typo which is a potential bug being masked
        }

        Scoping helps prevent name collision and bugs.

        --
        Only an amateur defends JavaShit; professionals are too busy trying to work around the brain dead language designed in 10 days.

    • Also, I've never once felt any need for namespaces in JS. Whether you're using ES6, CommonJS, or require.js, you can name anything whatever you want, so there are no naming conflicts which require namespaces to address.

      Also, this is one example of how JS deters you from globals, and pushes you into DI.

      • None of those things I listed are *essential* for writing high-quality software. Those are just things that make life easier for the programmer, and help them to avoid mistakes.

        Also, the global namespace in JavaScript has certainly been the cause of many bugs, and more than a few security issues as well. Were you designing the language from scratch today, you'd certainly build in support to make it much easier to write code in protected "containers" of sorts, and make it much more difficult to breach thos

        • Tough to say. Global-everything is a valid paradigm for tiny projects. If tasked with re-doing JS, I'd think long and hard about invalidating a legitimate paradigm, even if it's a paradigm I wouldn't use. That said, until using JS, the thought would not have occurred to me that you might want that.

    • Yeah I got caught by something similar. An int set to None is False. Changed that variable to be a list and a corner case where I passed an empty list was treated as False where I expected it to be True. I as in the habit of treating None as False and it bit when I changed the type of my data.

  • Original submitter here (Score:5, Interesting)

    by cerberusss ( 660701 ) on Saturday April 15, 2017 @02:59PM (#54240875) Journal

    Original submitter here... I just came here to compliment the editor (EditorDavid). This is my first time submitting and thought my summary was pretty good. But EditorDavid just went above and beyond, extending it with stuff from Twitter, couple of sentences on Andy Hunt's work ethic cetera.

    It's been tradition to hate at the editors here, but this time I have to hand it to them, compliments are in order.

    • Thanks for the article submission, and good to hear some positive feedback for a change when the editors do a proper job. Just ignore acerbic bitter-balls that can't find anything better to do with their time than to lash out at strangers on the internet. It's really sort of sad, when you think about it.

      • and good to hear some positive feedback for a change when the editors do a proper job

        You'll always get positive feedback - or least, moderate surprise - when they do a proper job. The problem is that that is rarely ever.

    • It's been tradition to hate at the editors here, but this time I have to hand it to them, compliments are in order.

      It's been tradition to hate at the editors more than to compliment them because they've done more inattentive work than exemplary. My own experience with submissions has been mixed. In one case I thought my submission was much improved, and in one case I thought my submission was much better than what was posted. I'd call it a wash. I still blame the users for most failures.

      • I still blame the users for most failures.

        Well, if we're going to blame someone, I'd say it's that fucking asshole CowboyNeal, who's been ruining things since 1998. He should be quartered and flogged, or perhaps the other way around.

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close