Depends on the size of the class. For large lectures, the projection screen can be two or three times the height of the lecturer, and then drawing things on the local machine and having them mirrored is easier. It would also be nice sometimes to get students to draw something on the board without forcing them to come to the front.
That would only really work if you were allowed multiple votes. For example, in the last election here in the UK, I think most people in my constituency would agree that the BNP candidate was the worst choice (and only a handful of people thought him the best - he lost his deposit), but then what? If everyone who thinks that votes against him, then that leaves the 200 or so people who think he's the best candidate to spread their vote among the other candidates, so one of them will get the fewest. So you wouldn't actually get that, you'd end up with all of the Labour supporters voting against the Tory candidate, because they seemed like the one most likely to be real competition, and then the BNP candidate gets in because no one thought that it was worth voting against them...
That's part of the problem. The other part is that the members of the parties that do the firing don't see any censure from their employers (i.e. constituents). How many of Sen. Scott Brown's constituents wrote to him to say that he'd lost their vote over this? How many will actually vote against him next time because of this?
We've actually run a couple of experiments tracking building use and interaction by using badges that report their position to observe people in the building. In both cases, wearing the badges was entirely opt-in (and required signing a form saying you understood exactly what data would be collected), and even then the ethics committee imposed some restrictions on the data that could be collected and how it had to be anonymised. It amazes me that a deployed system would have far weaker privacy constraints than an experiment.
For the same reason that you'd set up an MX record pointing to Google's mail server, instead of running your own: that you're either lazy, stupid, or very trusting. The difference is, if you don't set up the MX record pointing to Google, but tell them that you want to run Google Apps for your domain, then no one can send email to you. If you don't set up the SRV records, you can still log in to GTalk with your domain name and use it, and other GTalk users can still message you, but no one on a non-Google XMPP server can.
Almost everyone on Google Talk. If you use Google Talk and don't set up SRV records pointing to Google's server for XMPP, other Google Talk users can talk to you, but other XMPP users can't.
Without indirection, via pointers or some equivalent, you can't create variable-sized data structures. The same applies to unbounded computations and recursion. You either use recursion, or you emulate it with a loop and some structure representing a stack.
I would say that you can't claim to be able to program if you can't write a program that can be run on a Turing-complete computing engine, but can't be run on a finite automaton, and for that you need to understand indirection and iteration.
There are two hard concepts in programming, and your list doesn't cover either of them. These are recursion (induction, for the theoreticians) and pointers (indirection, for the theoreticians). The idea of a pointer as something that is a name for a name for a name for a thing, at arbitrary number of levels of indirection, and that you can work with these instead of with identifiers (which are a single, fixed layer of indirection) is something that a lot of people, even those enrolled on computer science degrees, have problems with. The idea of induction is also one that a lot of people struggle with. The concept that you can define something for a simple case and then define it for every subsequent case by defining a rule that simplifies it by one step is the other concept that a lot of people struggle with.
Generally, people who grasp those two concepts in their first year have no problems completing their degree. Those that fail, tend to drop out. If you can understand them, then everything else is easy, but any list of everything that a programmer needs to know that misses them is flawed, to say the least.
You only hear that kind of talk from idiots who don't realise that the higher tax bracket only applies to the earnings over that threshold. If you earn more before tax, you always earn more after tax. It's just that the after-tax increment will be less than the pre-tax increment.
You can hammer in a nail with the end of a screwdriver. You can hammer in the end of a nail with the handle of a drill or a plane. That doesn't alter the fact that a hammer is a better tool for the job than either.
Just because you can implement the same algorithm in two languages doesn't mean that you can implement the same algorithm equally easily in both. In the real world, it is often significantly easier to implement any given approach in one language than another, especially if they are from different families. I would write quite different code to solve a problem in C, C++, or Objective-C, and they're all fairly closely related languages.
I half agree. A good workman doesn't blame his tools, but that's partly because a good workman has access to, and selects, the correct tool for the job. You can implement any algorithm in any language, but any language that you choose, but certain language encourage certain formulations, and some impose restrictions on the underlying platform. It's just as much of a mistake to think that all languages are interchangeable as it is to think that one is the best tool for every job.
I used feedbooks with my eInk device. They have all of the Project Gutenberg collection, as well as a load of CC works, and a nice typesetting engine for generating PDFs for your device (or ePub or other formats). For technical books, Safari Books Online carries all of the major publishers and lets you access chapters via a subscription, or download entire books in PDF or ePUB. If you just want to buy them, InformIT carries all of Pearson's books (Prentice Hall, Addison-Wesley, and so on), and they usually charge less for DRM-free ePUB + PDF than Amazon charges for a DRM'd Kindle book. Oh, and on my last book Amazon managed to fuck up the formatting of the Kindle version (the version on InformIT was fine)...
Brine was chosen because it's easier to get some impure water and make a saturated solution of salt than it is to get some impure water and make pure water. The human body is just stupid because the human body temperature changes over the course of a day (average is about 98F, so they even got that wrong) in a single human, let alone between humans.
SI units external relationships = semi-arbitrary (generally measures of physical phenomena that are roughly universal)
I'll accept physical phenomena, but not roughly universal. The second is based on the time it takes the Earth to rotate on its axis and the metre on the circumference of the Earth. They're both now retroactively defined in terms of the speed of light, but with a divisor that only really makes sense on Earth. They are certainly physical phenomena shared by anyone who lives on this planet (and so anyone relevant to the discussion), but that's a long way from universal.
The metric pint (the size of a typical bottle of ale) is 550ml, which is slightly less than the 568ml of a real pint, but quite a bit more than a US pint (473ml). I can't easily tell the difference between it and a proper pint, but the difference between a real pint and a US pint is quite noticeable.
I wouldn't buy one, but I would be very interested in a service like ZipCar, but with self-driving cars, so I'd be able to just schedule one to come and collect me and take me to my destination, or be available for me to use for a half day or day. This sort of usage would be too expensive in a taxi, but this sort of vehicle would be very affordable for occasional use (I live in a city where bicycles are the primary means of transportation, so I rarely need a car).
It's not quite so clear cut. On a modern chip, to get the kind of power usage that corresponds to an amount of heat they you can dissipate, you need to leave a lot of the chip idle at any time. This is true for data centres as well as mobile, although the amount of heat is more limited in mobile than in a well-ventilated rack in an air-conditioned room. This is why modern chips have a lot of dedicated circuitry for specialised uses.
Most high-speed connections these days are serial, not parallel. As you ramp up the speed, the complexity of keeping the signals from the different wires synchronised gets harder. Above a certain threshold, it's easier to make a serial connection ten times faster than to keep ten wires synchronised.
I don't know much about the Arduino, but my understanding is that it's basically a microcontroller with the I/O pins wired to something that it's easy to connect stuff to. As such, the CPU is probably on the same order of complexity as a 6502, so about as easy to program, although the tools have improved a lot. It also doesn't have any of the coprocessors (e.g. for sound and video) that a C64-era machine typically had. Note, however, that I was talking about fully understanding the machine, not about programming it. One of the major developments in computing over the past couple of decades is that it is now easy to program computers while only having a very abstract idea of how they work.
A modern ARM system, even an oldish one like the RPi (which, by the way, is designed two floors up from me) is vastly more complicated. In the middle of the RPi, there's an ARM11 CPU. This is pretty old by computing standards, but still fairly modern. It's about the only ARMv6 implementation still shipped (everything else is ARMv7, with ARMv8 just about to appear), and lacks the atomic operations and some of the nicer FPU support of the newer CPUs, but you still have a basic CPU design that supports multiple nested interrupt levels, virtual memory, write-through or write-back caching. The ARM ARM is a lot shorter than the IA32 manual, but it's still a pretty hefty book. By itself, it's longer than the manual that came with my BBC Model B, which included an explanation of the BASIC dialect, full descriptions of the video modes (including text and teletext modes), a complete description of the 6502 instruction set, and diagrams of the circuit boards. The RPi also has a fairly nice GPU, which is not even publicly documented, so good luck understanding how that works, and a few other coprocessors. The video output is DVI, which is a fairly complicated specification: quite understandable, but a lot more complex than the unmodulated analogue video out of TV-connected microcomputers from the '80s. You couldn't, for example, build a light pen for the RPi (even if you did connect it to a CRT), because the position of the photon beam is not exposed. You could for the BBC, and it was quite easy.
And that's ignoring all of the other hardware on the RPi's SoC, such as the UARTs, programmable interrupt controller and the DMA engines, each of which is of the same order of complexity as a 6502.
The main difference between ARM and x86 is ARM's willingness to phase out legacy cruft. The PC comes with a BIOS (or EFI that can emulate a BIOS), implementing the same set of BIOS interrupts (effectively system calls) that the original IBM PC implemented and all of the integrated peripherals that had analogs in the IBM PC support this interface (e.g. keyboard, mouse, text-based video console). It comes with a CPU that supports a protection model that is 100% backwards compatible with real-mode 16-bit code, and also with protected mode 32-bit code for the 80386. In contrast, an ARMv6 implementation can run any user-mode ARM code, but it won't boot an OS written for ARMv5 and will need new drivers for things like the console, display, USB, and so on (ARMv6 didn't even specify the interrupt controller. Neither does ARMv7, but the Cortex-A9 and newer all do).
This is exactly what Objective-C does. The method lookup function (objc_msgSend() and friends) contain a short-circuit path that returns 0 if the receiver is nil.
That is very implementation dependent. What you say is true for C++ (on most modern systems, which use the 'zero-cost' exception model. I think iOS is the only exception, which uses setjmp() / longjmp() and so has expensive exceptions, unless they've fixed it recently). In Java, because exceptions are so common, this is often significantly slower and so functions return two values and the call is followed by a (statically hinted as not taken) branch on the 'an exception was thrown' value, which then jumps into the catch / finally block and checks what the exception was.
Return 0, or -1? The fault isn't that of the libc developers, of course, it's the fault of the specification writers, who wanted to make it possible to save a few bytes. The other one that always irritates me is strcmp(), where it should be trivial to say that two NULL inputs are the same, but otherwise NULL comes before any other input and then you wouldn't need to bracket every single call in a NULL check. And since it's not part of the standard, even if one libc did do something sensible, you couldn't rely on it and so you'd end up with NULL checks before and after the call, so that libc would seem slower.
Slashdot Mirror
Depends on the size of the class. For large lectures, the projection screen can be two or three times the height of the lecturer, and then drawing things on the local machine and having them mirrored is easier. It would also be nice sometimes to get students to draw something on the board without forcing them to come to the front.
That would only really work if you were allowed multiple votes. For example, in the last election here in the UK, I think most people in my constituency would agree that the BNP candidate was the worst choice (and only a handful of people thought him the best - he lost his deposit), but then what? If everyone who thinks that votes against him, then that leaves the 200 or so people who think he's the best candidate to spread their vote among the other candidates, so one of them will get the fewest. So you wouldn't actually get that, you'd end up with all of the Labour supporters voting against the Tory candidate, because they seemed like the one most likely to be real competition, and then the BNP candidate gets in because no one thought that it was worth voting against them...
That's part of the problem. The other part is that the members of the parties that do the firing don't see any censure from their employers (i.e. constituents). How many of Sen. Scott Brown's constituents wrote to him to say that he'd lost their vote over this? How many will actually vote against him next time because of this?
We've actually run a couple of experiments tracking building use and interaction by using badges that report their position to observe people in the building. In both cases, wearing the badges was entirely opt-in (and required signing a form saying you understood exactly what data would be collected), and even then the ethics committee imposed some restrictions on the data that could be collected and how it had to be anonymised. It amazes me that a deployed system would have far weaker privacy constraints than an experiment.
Yes, but the question is to what should you feed them...
For the same reason that you'd set up an MX record pointing to Google's mail server, instead of running your own: that you're either lazy, stupid, or very trusting. The difference is, if you don't set up the MX record pointing to Google, but tell them that you want to run Google Apps for your domain, then no one can send email to you. If you don't set up the SRV records, you can still log in to GTalk with your domain name and use it, and other GTalk users can still message you, but no one on a non-Google XMPP server can.
Almost everyone on Google Talk. If you use Google Talk and don't set up SRV records pointing to Google's server for XMPP, other Google Talk users can talk to you, but other XMPP users can't.
I would say that you can't claim to be able to program if you can't write a program that can be run on a Turing-complete computing engine, but can't be run on a finite automaton, and for that you need to understand indirection and iteration.
There are two hard concepts in programming, and your list doesn't cover either of them. These are recursion (induction, for the theoreticians) and pointers (indirection, for the theoreticians). The idea of a pointer as something that is a name for a name for a name for a thing, at arbitrary number of levels of indirection, and that you can work with these instead of with identifiers (which are a single, fixed layer of indirection) is something that a lot of people, even those enrolled on computer science degrees, have problems with. The idea of induction is also one that a lot of people struggle with. The concept that you can define something for a simple case and then define it for every subsequent case by defining a rule that simplifies it by one step is the other concept that a lot of people struggle with.
Generally, people who grasp those two concepts in their first year have no problems completing their degree. Those that fail, tend to drop out. If you can understand them, then everything else is easy, but any list of everything that a programmer needs to know that misses them is flawed, to say the least.
You only hear that kind of talk from idiots who don't realise that the higher tax bracket only applies to the earnings over that threshold. If you earn more before tax, you always earn more after tax. It's just that the after-tax increment will be less than the pre-tax increment.
You can hammer in a nail with the end of a screwdriver. You can hammer in the end of a nail with the handle of a drill or a plane. That doesn't alter the fact that a hammer is a better tool for the job than either.
Just because you can implement the same algorithm in two languages doesn't mean that you can implement the same algorithm equally easily in both. In the real world, it is often significantly easier to implement any given approach in one language than another, especially if they are from different families. I would write quite different code to solve a problem in C, C++, or Objective-C, and they're all fairly closely related languages.
I half agree. A good workman doesn't blame his tools, but that's partly because a good workman has access to, and selects, the correct tool for the job. You can implement any algorithm in any language, but any language that you choose, but certain language encourage certain formulations, and some impose restrictions on the underlying platform. It's just as much of a mistake to think that all languages are interchangeable as it is to think that one is the best tool for every job.
I used feedbooks with my eInk device. They have all of the Project Gutenberg collection, as well as a load of CC works, and a nice typesetting engine for generating PDFs for your device (or ePub or other formats). For technical books, Safari Books Online carries all of the major publishers and lets you access chapters via a subscription, or download entire books in PDF or ePUB. If you just want to buy them, InformIT carries all of Pearson's books (Prentice Hall, Addison-Wesley, and so on), and they usually charge less for DRM-free ePUB + PDF than Amazon charges for a DRM'd Kindle book. Oh, and on my last book Amazon managed to fuck up the formatting of the Kindle version (the version on InformIT was fine)...
Brine was chosen because it's easier to get some impure water and make a saturated solution of salt than it is to get some impure water and make pure water. The human body is just stupid because the human body temperature changes over the course of a day (average is about 98F, so they even got that wrong) in a single human, let alone between humans.
SI units external relationships = semi-arbitrary (generally measures of physical phenomena that are roughly universal)
I'll accept physical phenomena, but not roughly universal. The second is based on the time it takes the Earth to rotate on its axis and the metre on the circumference of the Earth. They're both now retroactively defined in terms of the speed of light, but with a divisor that only really makes sense on Earth. They are certainly physical phenomena shared by anyone who lives on this planet (and so anyone relevant to the discussion), but that's a long way from universal.
You're citing a US government web site for the correct spelling of a French standard?
The metric pint (the size of a typical bottle of ale) is 550ml, which is slightly less than the 568ml of a real pint, but quite a bit more than a US pint (473ml). I can't easily tell the difference between it and a proper pint, but the difference between a real pint and a US pint is quite noticeable.
I wouldn't buy one, but I would be very interested in a service like ZipCar, but with self-driving cars, so I'd be able to just schedule one to come and collect me and take me to my destination, or be available for me to use for a half day or day. This sort of usage would be too expensive in a taxi, but this sort of vehicle would be very affordable for occasional use (I live in a city where bicycles are the primary means of transportation, so I rarely need a car).
iTunes 10 is actually quite nice. After about 4.2, each release made it worse until 10, so it was quite a surprise.
It's not quite so clear cut. On a modern chip, to get the kind of power usage that corresponds to an amount of heat they you can dissipate, you need to leave a lot of the chip idle at any time. This is true for data centres as well as mobile, although the amount of heat is more limited in mobile than in a well-ventilated rack in an air-conditioned room. This is why modern chips have a lot of dedicated circuitry for specialised uses.
Most high-speed connections these days are serial, not parallel. As you ramp up the speed, the complexity of keeping the signals from the different wires synchronised gets harder. Above a certain threshold, it's easier to make a serial connection ten times faster than to keep ten wires synchronised.
I don't know much about the Arduino, but my understanding is that it's basically a microcontroller with the I/O pins wired to something that it's easy to connect stuff to. As such, the CPU is probably on the same order of complexity as a 6502, so about as easy to program, although the tools have improved a lot. It also doesn't have any of the coprocessors (e.g. for sound and video) that a C64-era machine typically had. Note, however, that I was talking about fully understanding the machine, not about programming it. One of the major developments in computing over the past couple of decades is that it is now easy to program computers while only having a very abstract idea of how they work.
A modern ARM system, even an oldish one like the RPi (which, by the way, is designed two floors up from me) is vastly more complicated. In the middle of the RPi, there's an ARM11 CPU. This is pretty old by computing standards, but still fairly modern. It's about the only ARMv6 implementation still shipped (everything else is ARMv7, with ARMv8 just about to appear), and lacks the atomic operations and some of the nicer FPU support of the newer CPUs, but you still have a basic CPU design that supports multiple nested interrupt levels, virtual memory, write-through or write-back caching. The ARM ARM is a lot shorter than the IA32 manual, but it's still a pretty hefty book. By itself, it's longer than the manual that came with my BBC Model B, which included an explanation of the BASIC dialect, full descriptions of the video modes (including text and teletext modes), a complete description of the 6502 instruction set, and diagrams of the circuit boards. The RPi also has a fairly nice GPU, which is not even publicly documented, so good luck understanding how that works, and a few other coprocessors. The video output is DVI, which is a fairly complicated specification: quite understandable, but a lot more complex than the unmodulated analogue video out of TV-connected microcomputers from the '80s. You couldn't, for example, build a light pen for the RPi (even if you did connect it to a CRT), because the position of the photon beam is not exposed. You could for the BBC, and it was quite easy.
And that's ignoring all of the other hardware on the RPi's SoC, such as the UARTs, programmable interrupt controller and the DMA engines, each of which is of the same order of complexity as a 6502.
The main difference between ARM and x86 is ARM's willingness to phase out legacy cruft. The PC comes with a BIOS (or EFI that can emulate a BIOS), implementing the same set of BIOS interrupts (effectively system calls) that the original IBM PC implemented and all of the integrated peripherals that had analogs in the IBM PC support this interface (e.g. keyboard, mouse, text-based video console). It comes with a CPU that supports a protection model that is 100% backwards compatible with real-mode 16-bit code, and also with protected mode 32-bit code for the 80386. In contrast, an ARMv6 implementation can run any user-mode ARM code, but it won't boot an OS written for ARMv5 and will need new drivers for things like the console, display, USB, and so on (ARMv6 didn't even specify the interrupt controller. Neither does ARMv7, but the Cortex-A9 and newer all do).
This is exactly what Objective-C does. The method lookup function (objc_msgSend() and friends) contain a short-circuit path that returns 0 if the receiver is nil.
That is very implementation dependent. What you say is true for C++ (on most modern systems, which use the 'zero-cost' exception model. I think iOS is the only exception, which uses setjmp() / longjmp() and so has expensive exceptions, unless they've fixed it recently). In Java, because exceptions are so common, this is often significantly slower and so functions return two values and the call is followed by a (statically hinted as not taken) branch on the 'an exception was thrown' value, which then jumps into the catch / finally block and checks what the exception was.
Return 0, or -1? The fault isn't that of the libc developers, of course, it's the fault of the specification writers, who wanted to make it possible to save a few bytes. The other one that always irritates me is strcmp(), where it should be trivial to say that two NULL inputs are the same, but otherwise NULL comes before any other input and then you wouldn't need to bracket every single call in a NULL check. And since it's not part of the standard, even if one libc did do something sensible, you couldn't rely on it and so you'd end up with NULL checks before and after the call, so that libc would seem slower.