The Secret Life of Programs: Understand Computers -- Craft Better Code - Softcover

Steinhart, Jonathan E.

 
9781593279707: The Secret Life of Programs: Understand Computers -- Craft Better Code
Softcover
ISBN 10: 1593279701 ISBN 13: 9781593279707
Verlag: No Starch Press, 2019

Inhaltsangabe

A primer on the underlying technologies that allow computer programs to work. Covers topics like computer hardware, combinatorial logic, sequential logic, computer architecture, computer anatomy, and Input/Output.

Many coders are unfamiliar with the underlying technologies that make their programs run. But why should you care when your code appears to work? Because you want it to run well and not be riddled with hard-to-find bugs. You don't want to be in the news because your code had a security problem.

Lots of technical detail is available online but it's not organized or collected into a convenient place. In The Secret Life of Programs, veteran engineer Jonathan E. Steinhart explores--in depth--the foundational concepts that underlie the machine. Subjects like computer hardware, how software behaves on hardware, as well as how people have solved problems using technology over time.

You'll learn:

  • How the real world is converted into a form that computers understand, like bits, logic, numbers, text, and colors
  • The fundamental building blocks that make up a computer including logic gates, adders, decoders, registers, and memory
  • Why designing programs to match computer hardware, especially memory, improves performance
  • How programs are converted into machine language that computers understand
  • How software building blocks are combined to create programs like web browsers
  • Clever tricks for making programs more efficient, like loop invariance, strength reduction, and recursive subdivision
  • The fundamentals of computer security and machine intelligence
  • Project design, documentation, scheduling, portability, maintenance, and other practical programming realities.

    • Learn what really happens when your code runs on the machine and you'll learn to craft better, more efficient code.

    Die Inhaltsangabe kann sich auf eine andere Ausgabe dieses Titels beziehen.

    Über die Autorin bzw. den Autor

    Jonathan E. Steinhart has designed graphics hardware and software, and built CAD systems, graphics workstations, circuit simulators, power plants, and languages for integrated circuit design. He has consulted for Apple, Intel, Sun, Welch-Allyn, Lulu, and many others.

    Auszug. © Genehmigter Nachdruck. Alle Rechte vorbehalten.

    Introduction
    A few years ago, I was riding on a ski lift with our Swedish exchange student. I asked her if she had thought about what she was going to do after high school. She said that she was considering engineering and had taken a programming class the previous year. I asked her what they taught. She replied, “Java.” I instinctively responded with “That’s too bad.”

    Why did I say that? Took me a while to figure it out. It’s not that Java is a bad programming language; it’s actually pretty decent. I said it because of the way in which Java (and other languages) are typically used to teach programming today—without teaching anything about computers. If this strikes you as a bit odd, then this book is for you.

    The Java programming language was invented by James Gosling, Mike Sheridan, and Patrick Naughton in the 1990s at Sun Microsystems. It was modeled in part after the C programming language, which was widely used at the time. C doesn’t include automatic management of memory, and memory management errors were a common headache at the time. Java eliminated that class of programming errors by design; it hid the underlying memory management from the programmer. That’s part of what makes it such a good programming language for beginners. But it takes much more than a good programming language to produce good programmers and programs. And it turned out that Java introduced a whole new class of harder-to-debug programming problems, including poor performance resulting from the hidden memory management system.

    As you’ll see in this book, understanding memory is a key skill for programmers. When you’re learning to program, it’s easy to develop habits that become hard to break. Studies have shown that children who grew up playing at so-called “safe” playgrounds have a higher rate of injuries later in life than those who didn’t, presumably because they didn’t learn that falling hurts. Programming is an analogous situation. Safe programming environments make getting started less scary, but you also need to prepare for the outside world. This book helps you make that transition.

    Why Good Programming is Important
    To understand why it’s problematic to teach computer programming without also teaching about computers, first consider how ubiquitous computers have become. The price of computers has fallen so dramatically that using them is now the cheapest way to build many things. For example, using a computer to display an image of an old-fashioned analog clock on a car dashboard costs much less than a mechanical clock. This is a result of how computer chips are manufactured; they’re more or less printed. It’s no longer a big deal to stamp out a chip that contains billions of components. Note that I’m talking about the price of computers themselves, not the price of things that contain computers. In general, a computer chip today costs less than the packaging in which it’s shipped. Computer chips are available that cost pennies. There will likely come a time when it will be difficult to find anything that doesn’t contain a computer.

    Lots of computers doing lots of things means lots of computer programs. Because computers are so ubiquitous, the field of computer programming is incredibly diverse. As in medicine, many programmers become specialists. You can specialize in areas such as vision, animation, web pages, phone apps, industrial control, medical devices, and more.

    But the strange thing about computer programming is that unlike in medicine, in programming you can become a specialist without ever being a generalist. You probably wouldn’t want a heart surgeon who never learned anatomy, but the equivalent has become normal for many programmers today. Is this really a problem? In fact, there’s plenty of evidence that this isn’t working very well, with almost daily reports of security breaches and product recalls. There have been court cases in which people convicted of drunk driving by breathalyzer have won the right to have the breathalyzer code reviewed. It turned out that the code was full of bugs, which resulted in overturned convictions. Recently, a piece of antivirus software crashed a piece of medical equipment in the middle of a heart surgery. Lives were lost due to design issues in the Boeing 737 MAX airplane. The large number of incidents like these don’t inspire a lot of confidence.

    Learning to Code is Only a Starting Place
    Part of the reason for this state of affairs is that it’s not all that difficult to write computer programs that appear to work, or work much of the time. Let’s use the changes in music (not disco!) in the 1980s as an analogy. People used to have to develop a foundation in order to make music. This included learning music theory, composition, and how to play an instrument; ear training; and lots of practicing. Then the Musical Instrument Digital Interface (MIDI) standard, originally proposed by Ikutaro Kakehashi of Roland, came along, which let anyone make “music” from their computer without ever having to develop calluses. It’s my opinion that only a small percentage of computergenerated “music” is actually music; it’s mostly noise. Music is produced by actual musicians—who may or may not use MIDI to build on their foundation. Programming these days has become a lot like using MIDI. You no longer have to sweat much or spend years practicing or even learn theory in order to write programs. But that doesn’t mean these are good or reliable programs.

    This situation is likely to get worse, at least in the United States. Wealthy people with vested interests, like those who own software companies, have been lobbying for legislation mandating that everybody learn to code in school. This sounds great in theory, but it’s not a great idea in practice because not everybody has the aptitude to become a good programmer. We don’t mandate that everybody learn to play football because we know that it’s not for everybody. The likely goal of this initiative is not to produce great programmers but rather to increase software company profits by flooding the market with large numbers of poor programmers, which will drive down wages. The people behind this push don’t care very much about code quality—they also push for legislation that limits their liability for defective products. Of course, you can program for fun just like you can play football for fun. Just don’t expect to be drafted for the Super Bowl.

    In 2014, President Obama said that he had learned to code. He did drag a few things around inthe excellent visual programming tool Blockly, and he even typed in one line of code in JavaScript (a programming language unrelated to Java, which was invented at Netscape, the predecessor to the Mozilla Foundation that maintains numerous software packages, including the Firefox web browser.) Now, do you think that he actually learned to code? Here’s a hint: if you do, you should probably work on honing your critical thinking skills in addition to reading this book. Sure, he may have learned a teensy bit about programming, but no, he didn’t learn to code. If he could learn to code in an hour, then it follows that coding is so trivial that there wouldn’t be a need to teach it in schools.

    Importance of Low-Level Knowledge
    An interesting and somewhat contrary view about how to teach programming was expressed in a blog post titled “How to Teach Computational Thinking” by Stephen Wolfram, the creator of Mathematica and the Wolfram language. Wolfram defines computational thinking as “formulating things with enough clarity, and in a...

    „Über diesen Titel“ kann sich auf eine andere Ausgabe dieses Titels beziehen.

    Verlag
    No Starch Press
    Erscheinungsdatum
    2019
    Sprache
    Englisch
    ISBN 10 
    1593279701
    ISBN 13 
    9781593279707
    Einband
    Taschenbuch
    Anzahl der Seiten
    504
    Kontakt zum Hersteller
    Nicht verfügbar
    Verantwortliche Person
    eucomplyOÜ
    hello@eucompliancepartner.com

    Pärnu mnt. 139b-14
    Tallinn
    11317
    Estland