371 posts • joined Thursday 21st September 2006 08:40 GMT
For flying too close to the sun and burning its wings, Icarus would be a better name for ISON.
If you wanted to make a terrorist attack, why wait until you are through airport security? Airports are so crowded outside security that exploding a bomb there would kill as many as doing it on a plane. Or do it in a mall during Black Friday, at a train station or in a zillion of other crowded places that has little or no security checks. The chain is only as strong as the weakest link, so why make this particular link so much stronger than the rest?
I suspect that one of the reasons for all the restrictions on what you can bring of liquids etc. is to increase sale in the "Tax Free" shops. In many airports half a litre of bottled water costs around €2, for example. This also explains the apparent contradiction that you can buy stuff that you wouldn't be allowed to bring in.
You don't need 64 bits
to address more than 4GB. Cortex A15 has an address bus of 48 bits (IIRC), but uses only 32-bit registers. This means that a single program using more than 4GB will need to use the MMU to switch between banks of memory (much like old 8-bit computers used banked memory to have more than 64K total). But phones and tablets usually run many programs at once, and each of these can use their own 4GB out of a larger total RAM without needing to do fancy tricks -- the OS does the bank switching.
On a longer time scale, I don't see much future in huge, flat address spaces: The future is parallel, so instead of a few cores sharing a large flat memory space, you have many cores each with their own memory communicating over channels. So 64 bit registers for memory addressing is not all-important. You can more easily operate on large integers, though, which is an advantage for cryptographic applications and a few other things. So it is by no means irrelevant, but the importance has been hyped a bit when Apple released their new phone.
All astronomers can see are the size of the planets and the approximate distance from their suns. If a planet is at a distance that allows liquid water and it is not gas-giant sized, it is deemed potentially habitable. But it takes more than potential liquid water to make a planet habitable: It takes real liquid water and an atmosphere with sufficient oxygen. The latter implies life, as free oxygen reacts with other substances so it needs to be continually renewed, and life is AFAIK the only realistic mechanism for that.
However, discounting gas giants ignores the possibility of habitable moons orbiting these. A large fraction of known exoplanets are much more massive than Jupiter and many of these are quite close tor their stars. Probably not because they really are more common, but because such planets are easy to find because they make the stars wobble visibly. Some of these super-massive planets are in the "Goldilocks zone", where liquid water may exist. While the planets themselves are hostile to human life, they may have Earth-sized moons that could be habitable. In our own solar system, gas giants have sizeable moons, though none are near Earth size. But it is not unreasonable that larger planets may have larger moons, so moons of super-massive planets may be a better bet for habitation than planets. A single super-massive planet may even have several habitable moons.
Is ARM slower than x86?
While Intel leads in speed in the current crop of processors, there is nothing inherent in the architectures that implies that ARM processors must be slower than x86 processors. When ARM first came out, it was faster than the x86 processors of the time. In the 90s, Intel caught up and surpassed ARM, but that was mainly because the focus for ARM processors shifted from desktop to mobile systems, in particular phones and PDAs. In the last decade, Intel has had the advantage of a 64-bit architecture, but now ARM has one too, and one that is simple enough to be implemented for high speeds at modest cost.
Since anyone can buy an architecture license and implement their own ARM processors, it is entirely possible that a big server producer will do that to make fast servers.
Word has grown in complexity to such an extent that even the save format (.docx) requires more than 7000 pages to specify its form and behaviour (http://en.wikipedia.org/wiki/Office_Open_XML#ISO.2FIEC_29500:2008). 99.9% of all users would be happy with something much less complex, such as HTML. HTML 4.01 requires less than 400 pages of specification (http://www.w3.org/TR/REC-html40/). And 99% would probably be happy with much less than even HTML.
HTML has the advantage of being readable and editable by humans without using a WYSIWYG editor (though many of these exist), so power users can get the precision and flexibility of editing raw HTML + CSS while most will be happy with selecting a predefined style and editing via a WYSIWYG editor.
HTML is not perfect, but is is a widespread standard having many implementations and is readable by anyone who has a browser (which even telephones have these days). The relatively simple format allows external tools to process documents fairly easily (compared to processing .docx files), so you don't need to have stuff like versioning, bibliography reference support, table-of-content generation and so on built in to the format: Just apply an external tool, similar to how you with LaTeX apply BibTeX and MakeIndex as external tools.
I will still continue to use LaTeX for my own use, but if forced out of it, I would much rather work with HTML-based text processors than with Word or derivatives like Open Office and Libre Office.
2nd hand sales
While really old models aren't very sellable, iPhone 4 and 4S still fetch reasonable prices on the2nd-hand market and there are quite a few for sale on EBay and similar sites. So Apple doesn't need to introduce cheaper models to expand their market: They can rely on 2nd-hand sales to do so. While a 2nd-hand sale does not directly give Apple any income, sale of apps will do so over time, and purchasers of a 2nd-hand iPhone are likely to upgrade to a new model in the future.
Am I the only one who thinks that passing obstacles 20% it own height is less than impressive? A house cat can jump over two meters up -- from standstill. So until the robot becomes a high jumper and a proficient climber of trees, I would not call it cat-like.
I'm pretty sure you mean that the show starts 8pm on 18 May rather than 8pm today..
Usually, such claims are based on maximum theoretical performance -- driving all processing units at full load. You may be able to get very close to that with specially-designed benchmark programs, but it is not realistic to get anywhere near this in "real" code.
My guess is that the actual performance gain is around x2 for graphics-intensive tasks and x1.5 for tasks that mostly involve the CPU alone. Not a bad gain, but not x3 overall.
Rockets and cars
Comparing a modern rocket to a V2 is like comparing a Fort T to a modern car: Both run gasoline-burning piston engines with a transmission shaft and mechanical gears. Even modern electric cars are not fundamentally different from those that were designed 100+ years ago.
The reason is that the basic design works well. The same is true for rockets. And that is why viable alternatives are still stuff of the future.
One idea that hasn't been mentioned is using ionised air as the main propellant: The motor is a linear accelerator that ionises the incoming air, accelerates it and expels it at the other end. The energy could come from a nuclear reactor or (for a slower acceleration) solar panels. A solar powered craft could use traditional propellers for a first stage to lift the craft to high altitude, where the next stage (with smaller wings) uses the linear accelerator motor. Eventually, the air would be too thin, at which point you could switch to air you brought along (e.g, liquid nitrogen).
Though, sadly, it never went into production, I found Acorn's Phoebe design quite distinctive.
I also liked the design of the Newbrain: http://www.theregister.co.uk/2011/11/30/bbc_micro_model_b_30th_anniversary/page3.html
The right tool for the job
Spreadsheets are excellent when you need to add up some columns and rows in an array of values, where some values are not filled in yet. But they are woefully inadequate for the more complex tasks that many people use them for. It is a bit like writing in assembly language: You can do it, but the result is unreadable and even simple errors will not be caught -- neither at compile time nor at runtime.
It is not hard to write domain-specific languages for financial analysis that have build in checks such as preservation of money: You don't accidentally use the same $ twice, and you don't forget that you have them somewhere. Basically, all the money (or streams of interest payments) that get into the system is accounted for exactly once in the what comes out. This gives a safety that spreadsheets do not. You can, of course, still write nonsensical derivations, but a lot of common mistakes are caught. A bit like static versus dynamic types: The latter require you to write a lot more tests to catch bugs. This is no problem if you programs are small and simple enough, but once you get above a certain degree of complexity, you are likely to miss cases that would have been caught by a good static type system.
Also, by being designed specifically for the task, solving a problem in that language is usually easier and faster even than doing it in a spreadsheet (which is faster than doing it in Java).
Warning labels instead of censorship?
I can't see who Apple is trying to protect (apart from their own image). You need an Internet connection to use their bookstore, and it is not exactly hard to find sexually explicit images on the Internet.
I would much prefer warning labels ("This work contains nudity, swear words and violence" and so on) and a rating system. The default could very well be that you are only shown works with a "child-safe" rating, but you should be able to set the filter details yourself, so you, for example, can avoid violence but accept nudity (or the reverse, which seems to the American standard).
And, yes, I'm Danish, so censorship offends me more than nudity.
A couple of years ago I predicted that this would happen, and I have seen nothing to change that opinion. The main reason I see for Apple to do this is to get full control of the hardware, like they have on their iOS devices. A secondary reason is to get iOS apps running on MacBooks. I think iOS and MacOS will merge much in the same way Windows 8 have merged the desktop and phone operating systems from MS. MS has stayed with x86 on the desktop/laptop version of Win8, but that is (IMO) mainly because many Windows applications have parts written in x86 assembler or C that assumes x86 behaviour (such as endianness and non-aligned memory transfers), which makes them harder to port to a new platform. Having learned from past experience in moving to new processor platforms, Apple have far fewer assumptions about processor in their code. And, as another poster said, they are increasingly relying on LLVM in a move that mirrors Microsoft's increasing reliance on .NET, both of which makes changing platform easier.
With the upcoming 64-bit processors, ARM should be powerful enough to compete with 64-bit x86 processors, but the licence model that allow other companies to build their own SoCs around ARM cores (and even design their own cores) is probably the main reason: With Intel, they have to use the SoCs that Intel make. With ARM, they can make a SoC that does exactly what they need and want. And make sure no one else can use this SoC to make clones.
As for Apple buying AMD, I doubt that. But I wouldn't be surprised if ARM bought AMD.
An updated Elite! would be very interesting. I have tried Oolite, but I found that (apart from visuals), too little was added. Yes, that made the feel very close to the original Elite!, but, frankly, that is a bit dated. I haven't played Frontier or any of the official sequels, so I can't really comment on these.
Things I would like to see are:
- More realistic economy. In the original Elite!, prices fluctuated with every jump, so by jumping back and forth between close systems, you could select your prices. Fluctuations should be slower and prices should depend more on distance. Also, you very quickly found out what to trade: Computers from high-tech to low-tech and food, liquor and furs the other way. I would prefer all goods to be viable and some systems to specialize in certain goods. And alien artefacts should be REALLY worthwhile to grab, unlike in the original where the price is just average.
- A 3D star map. The original galaxies are flat and rectangular. A 3D local map and spiral-galaxy global map would be nice. One galaxy should be enough, though, if it is large enough.
- Worm holes: A few connections that allow you to travel long distances to specific destinations.
- No "ultimate" weapons like energy bombs.
- More choice of player ships and upgrades.
- Possibility to buy or hire escort ships.
- Exploration: Earn income by surveying unexplored systems.
Sometime between the first two films, Lucas announced that he had plans for three trilogies, one set before the first film (which was, accordingly, renamed to "Episode IV") and one after the original trilogy. It took ages for him to make the prequel trilogy (and he messed that up pretty badly), so he thankfully dropped the idea of the third trilogy. Given that the title of the first Disney film is "Episode VII", my guess is that they will make the third trilogy.
In a way, Star Wars has always been in a Disney-like style, so I can't see anything horrible coming out of this.
As far as I recall, the hardware on big.LITTLE processors can do the transition from low-power to high-power processors and vice-versa without intervention from the OS. Essentially, the processor state is saved in local memory and read by the other processor. That makes the situation different from Tegra3, where you have to write software to explicitly exploit the 5th core.
Reasons for decline
In my estimation, it was not the unfamiliarity of the OS that led to the failure of Acorn. It was a mixture of price (the cheapest RISC OS computer was much more expensive than the cheapest Wintel PC) and lack of software. While there were excellent applications for most tasks, there were applications on Windows and MacOS that had no decent equivalent on RISC OS -- the market would simply be too small. This led to a downwards spiral where developers would move from RISC OS to Windows to get more customers and this would reduce the uptake of RISC OS computers and so on.
In retrospect, Acorn should have done as Microsoft did: Licensed their OS so anyone could have made hardware using it. This would have given people who felt that Acorns prices were too high a cheaper entry and, possibly, kept the market large enough to attract software developers. Apple was able to survive on a non-license policy and high prices, but that was because they were dominant in a market that was willing and able to pay a premium: Graphics design and publishing. Acorns main market was education, a market that is neither willing nor able to pay premium. Their secondary market (hobbyists) has a segment that will and can pay premium, but this was not enough to keep Acorn alive. And after the death of Acorn, development of RISC OS was much too slow, and was hampered by ARMs shift in focus from performance to low power, which meant that ARM-based computers could no longer compete with x86 ditto.
As for ARM vs x86 instructions sets, ARM is in the CISCy end of RISC and x86 in the RISCy end of CISC, so you should not use them as defining instances of these terms. Rather, you should compare the instruction sets on their own merits. IMO, ARM assembly language is much easier to program than x86 ditto and also a lot easier to compile to. x86 code is slightly more compact, but with the Thumb extension ARM got the advantage here again. ARM suffered for a long time in not having a unified floating-point instruction set over all processors but, again, that problem is solved. Now the main failing of ARM is lack of a true 64-bit processor, but even that is coming soon. And in any case, the advantage of 64 bits is mainly that a single program can easily use more than 4GB of RAM, but that is (as yet) not a problem for personal users. Saying it will never be is, however, as silly as saying taht 640K is enough for everyone.
Instead of rotating the engines proper, you can rotate the exhausts as on the Harrier jet. Possibly also the intake vents.
I think the idea og a rotating plane makes a lot of sense. I don't think passengers will mind sitting sideways when the plane is at top speed -- the speed will be fairly steady, so you won't feel any pressure. Turbulence will throw you in random directions regardless of how you face, so that won't make any difference. Declining seats are IMO a nuisance more than a service, so I would actually prefer seating arrangement like in trains: Two rows facing each other, so you can stretch your legs if you can agree with the person opposite which way to turn. Tables can be pulled out of the arm rests, like they are in the emergency-exit seats now. If seats are made back-to-back and non-reclining, they can be made sturdier at less weight. Seat belts should, IMO, be made more like in cars with a strap over one shoulder and self-adjusting. This is also easier if seats are fixed.
Re: I wonder...
boltar says: "Thats the problem with proving software - how do you know the tests or the proof is correct? In theory you could end up in an infinite regression of testing - prove the software, prove the proof, prove the proof of the proof etc etc. I guess at some point you just have to draw a line and say "its as good as its humanly possible to get"."
It is actually not as bad as that. Proof systems usually have a very small set of primitive rules and combining forms that are verified by hand, and then all proofs are build up from this set of primitive rules and combining forms. This means that errors in the code that generates the proofs can not generate faulty proofs (at least not without triggering run-time errors). Basically, the worst a programming error in the proof generator can cause is failure to produce any proof, but faulty proofs can not be made. Assuming, of course, that the small kernel of primitive rules is correct, but great effort has been made to ensure this.
When proving behaviour about programs, a much larger problem is whether the formal specification of the programming language actually corresponds to the behaviour of running programs: The compiler may not conform to the specified standard. Hence, you often verify the generated machine code instead of the source code. That way, you don't have to trust the compiler and you don't need a formal language specification for the high-level language. What you need instead is a formal specification of the machine language, but that is often easier to make. A problem is, though, that the machine language does not have information about the types of values (are they integers or pointers, and pointers to what?). So you sometimes make the compiler generate typed assembly language. The types can be checked by the proof system and help verification of the correctness of the code relative to a specification. Obviously, few "standard" compilers generate typed assembly language that can be verified this way.
While there is a lot of "religion" in choice of programming language, I find C a particularly bad choice for writing zero-defect software: There is not enough information in the types to catch even simple mistakes (such as writing x=y instead of x==y) at compile time, memory deallocation is unchecked and unsafe, lots of behaviour is specified as "implementation dependent" or "undefined" in the standard, and so on.
As a result, you have to throw a lot of complex analysis after the program just to catch errors that in most other languages would have given a compile-time error message or which could not even occur in these languages. And to make the analysis tractable, programmers are forced to use only the simplest parts of the language, as the more complex parts are too difficult to analyse. Of course, this allows Stanford researchers to write a few scientific papers and Coverisity to earn a few bucks. But that seems like a very costly solution.
I don't suggest using one of the newer mainstream languages, because while they have better type systems, they are not suited for small computers running real-time software. But there are plenty of languages designed for ease of verification and control of resources. Some of these even have compilers that are verified to generate correct code, which I don't think any (full) C compiler is.
District 9 has basically the same premise as Alien Nation: Aliens are stranded on Earth and become a new lower class.
As for War of the World adaptations, I quite like the Marvel comic book series that shows Earth under Martian rule after a 2nd invasion. It started out being called "War of the Worlds" but was later named after its lead character "Killraven". A similar premise is used in John Cristopher's Tripod series. So it would be fairly safe to say that WotW has been the inspiration of quite a few alien invasion stories.
Not so fast
One of my friends bought a Newbrain, and I recall that it wasn't really that fast, at least not when it came to graphics. One reason may be that it used real numbers as coordinates rather than integers and allowed arbitrary scaling factors for the coordinates (so you could, for example, define your screen as going from -pi to pi horisontally and from 0 to 1e20 vertically). It did have some (for the time) advanced graphics primitives, including a flood fill (which worked in a way that gave associations to Tron lightcycles).
The keyboard, in spite of its odd look, was actually quite good, as I recall it.
In any case, after I bought a BBC B, my friend sold his Newbrain and bought a BBC too. I dont' think he ever regretted that decision.
More pixels mean more light?
For backlit screens, the amount of light needed is a function of screen area and not the number of pixels on said screen. So increasing pixel density will not affact power use for backlight. What it will affect, however, is the power required to show movies or pictures in full screen resolution, as more data needs to be moved and processed.
Even with LED displays,the power needed to provide a certain brightness will not increase if you double the number of pixels while keeping the same total area, as the pixels will be smaller and each use less power. After all, the brightness is the combined energy output of the pixels. so unless there is a higher power loss by increasing density, the power needed to display a picture at a certain brightness should be the same.
The Danish Kings used to have a throne called the "Unicorn Throne" because it was made partly of alicorns (http://en.wikipedia.org/wiki/Unicorn#Alicorn), which were in reality narwhal tusks (which Denmark, being the sovereign of Greenland, had easy access to). But why say this when it was more impressive to claim they were from unicorns?
Re: Good luck with that
"In most of the US, the Metric system is still seen as some kind of commie plot."
Or even as ungodly. "If inches and feet were good enough for Jesus, they are good enough for us!"
The idea of using existing languages (in particular C and C++) for massively parallel computing is doomed: These languages are inherently sequential and rely on a flat shared memory, which is very far from what massively parallel machines look like. Sure, you can use libraries called from C or C++, and you can even program these libraries in something that superficially resembles C, but the fact is that C and related languages are hopelessly inadequate for the task.
So we need languages that move away from languages with implicit sequential dependencies through updates to a shared state towards languages that do not have shared state and where the only sequential dependencies are producer-consumer dependencies. This means that you don't have traditional for-loops, as these over-specify a sequence on iterations of the loops. Instead, you have for-all constructs that allows the "iterations" to be done in any order or even at the same time. And to replace a for loop that, say, adds up elements in an array or other collection, you have "reduce" constructs that do this in parallel.
You might think of map-reduce, but it goes further than that. The proper reference is NESL.
This image viewer and editor is one of the first things I download when I or one in my family gets a Windows PC. Personally, I don't use Windows much myself anymore, but Irfanview is one of the few programs I miss.
"Miscopied genes" is sort of the definition of mutation, so it should be no surprise that this is behind human evolution (including intelligence). The interesting bits are that plausible specific genes have been pin-pointed and approximate dates for the mutations found.
IMO, another problem with "traditional" ways to teach programming to kids is that the teachers want the programs to be about real-world problems. While this is realistic and can motivate some students, it also adds another layer of complexity: Abstracting a real-world problem to a level that allows solution on a computer. So I think the students should initially work on problems that do not require an abstraction step. This can either be by not pretending at all that the problems have anything to do with real life or by working in a domain that is already abstracted using an abstraction that the students know well already: Numbers. For example, the data domain can be simple integers and a grid of pixels that can be turned on and off individually and problems can be of the form: Make a program that makes checker-board pattern on the screen. Pixels should be big enough that you can see each individual pixel, so you can better see what goes wrong when something does. Also, make it easy to read the value of a pixel on the screen -- a feature that was found on most 80's home computers, but which is complicated or impossible to do in many modern graphics libraries.
How to teach programming to kids
Many of the efforts to teach programming to kids has suffered from the desire to allow the kids to make cool stuff (animations etc.) happen on their screens within a few minutes after teaching starts. This is supposedly to motivate the kids to go on exploring their tools.
But in order to get this stuff on the screen so quickly, the tools that are used do a lot of things under the hood that the kids have no control of or understanding of. It is a bit like thinking you can learn electronics by plugging together two black boxes to make a radio. The kids can see the cause and effect (if I put together these boxes, sound comes out of one of them), but they have no understanding of why this happens.
So, instead, the kids should use extremely simple languages where every minute step is explicit. It might take a while before they can make something "cool", but they will understand what happens when they do.
In Denmark ...
... we have towns called "Tarm" (intestine) and "Lem" (a slang word for penis). These have not considered changing their names. There is also "Kværkeby" (strangling town), "Mørke" (darkness) and "Ringe" (inferior). English-speakers might find "Middelfart" amusing.
I'm nowhere near London this weekend, otherwise I would have come. Had I known about it a few weeks ago, I might have arranged a trip. Oh, well.
I agree that the 6502 took a bit of getting used to, if you wanted to program in assembler. But the 6502 in the BBC was quite fast, so it was worth it. And the BASIC on the BBC was far ahead of BASICs on contemporary machines, both in terms of features and speed -- and that even though the BBC used 32-bit integers while the rest nearly all used 16-bit integers.
A few years ago, I had the students for my compiler class write a BASIC compiler. It targeted MIPS (as that is the architecture they were familiar with after the architecture course) and it didn't have nearly all the features of BBC BASIC. But the students thought it a fun exercise.
Not real steganography
"Real" steganography is hiding a message in an already constructed text or picture in a way that does not obviously change that text or picture. What is described is a form of cryptography.
Text steganography could, for example, be by varying the amount of space between words to encode a hidden message: On the surface, the text is unaltered and looks perfectly natural, but there is a message hidden. If you actually have to construct a message specifically to encode the message, it is not really steganography -- it is just low-density cryptography similar to texts where the initial letters of the words encode a message or texts where the length of the words encode digits (like "How I wish I could recollect pi. "Eureka!" cried the great inventor: Christmas pudding, Christmas pie, is the problem's very centre"). The challenge of these is to make the text seem natural, while it has to obey non-trivial constraints. Real steganography should have no such constraints, but be able to encode any text (or picture) to hide a message.
There have been a lot of controversy over whether Homo Sapiens and Neanderthals could (and did) interbreed or not. The opinions range from "not possible" over "sterile offspring (like mules)" to "Some European human characteristics are inherited from interbreeding with Neanderthals".
Which is true I can't say. I'm inclined towards the "sterile offspring" theory, since AFAIK genetic analysis of Sapiens and Neanderthal DNA have not shown any difference in European, African and Asian DNA that could be explained by genetic material inherited from Neanderthals.
But it is equally obvious that speciation is a gradual process, so there will in the past have been differently-looking hominids that could interbreed so hybrids appeared. It is only when groups have been isoated long enough that interbreeding stops being possible. There are theories that state that early Sapiens at some point got nearly extinct, which reduced the gene pool sufficiently to prevent viable interbreeding with other hominids and that all present humans are descendants of this small group (which may have numbered only a few hundred individuals).
How this affects the possibility of the skeletons in question being a separate species or not, I can't say.
Move to ARM
While I agree with the comments that say that you can't conclude anything from the student project, it makes very good sense for Apple to move to ARM for their laptops and desktop computers:
1. They can share low-level code with IOS.
2. They can reduce power-use, which was the main stated reason for the previous move (to x86).
3. They can run IOS applications natively on laptops and desktops.
4. They can make their own SoC, which prevents people from installing MacOS X on non-Apple machines.
I think reason 4 may be the most compelling for Apple, as they have (almost) always been unhappy about clones and about people running MacOS on their cheap PCs.
I saw a wooden keyboard in a shop the other day. It looked nice, but the price was around 2000 dkr (ca. 150 gbp).
I agree with David that a Minecraft-like game based on Lego would be an obvious step. Lego didn't have much success with its MMORPG, but something closer to Minecraft would have been both a lot closer to the original Lego philosophy and probably a bigger success. Now that Minecraft has that market more or less carved out, there may not be as much room for a Lego variant as would be the case if Lego had done something like it earlier. But it could still work.
The list is, indeed, not very exciting, and I agree with nearly every objection stated above. For example, TVs with built-in Internet technology sounds to me a lot like TVs with built-in VHS or DVD players. And while ultrabooks look nice, there is nothing much new here.
What I find more exciting in 2011 is the spread of non-Wintel technology to laptop, desktop and servers. We may finally see an end to the de-facto Wintel monopoly.
And the gradual replacement of LCD with newer screen technologies (LED, Mirasol, ...) is also a thing to look for.
Finally, the return of the hobby computer (in the form of Raspberry Pi) might be a more important thread than any of the above -- even if it didn't make CES.
iPhone and Android?
Surely these platforms should be considered as well? And what about browser games? Some of them actually cost money to play (in the full version), so you could calculate the sales of these too.
Or is it unfair to compare a game that you can buy on Android Market or App Store for $1 to a console or PC game that costs $20 or more?
Problem solving is a skill that is not taught well enough in the modern school system. There are lots of so-called "problem-oriented exercises", but what these really are are just simple applications of formulae to problems where the numbers are given units instead of being abstract numbers. Completely absent is the idea of breaking a complex problem down to smaller problems, solving these and combining the results to a solution of the complex problem and then judging if the solution makes any sense in the original context.
But that is maybe not so surprising: Problem solving is very down-played in the national curriculum of the UK, and you can easily pass exams with no skill whatsoever in problem solving. Students that give up on problem-solving without making a real effort are just shown how to solve the problem, and are never required to do the process without help, let alone required to judge their own efforts.
That said, a programming course should teach the basics of problem solving if the students do not possess these skills when they start. In the first few lectures, you might not even use the computer or write any code -- just solve some abstract problems that are amenable to analysis and decomposition.
What to teach?
No kids today need to learn how to _use_ a computer -- most do that even before they start school. So if ICT teaching has to make any sense, it should be about something else.
Programming is one such thing. But it should not be programming animations or games using some fancy GUI point-and-click interface. That may be a lot of fun, but they don't really learn much from that that they haven't already learned by playing Sims, Minecraft or other games. I agree with the Raspberry Pi people that you need to go down to a lower level where you essentially direct the flow of every bit rather than have most things happening under the hood: You don't learn to read a map by using a GPS navigator, and the same applied here: If the essentials are automated so you only have to select between a set of preprogrammed behaviours, you don't understand what goes on. Sure, the end results can be pretty convincing: With GPS navigation, you can get quickly and surely to your destination, and with Scratch and similar game-builders, you can quickly get coloured icons moving and interacting on the screen. But both decouples you from understanding what navigation or programming is really about.
Hardware-wise Raspberry Pi is much more than needed, and programming it on a low level only gets you so far: Graphics and sound are done by complex and opaque graphics and sound processors, and even Linux gets between you and the machine, so you are not really in touch with the hardware. So you really need to emulate a simpler machine and programming model if you want to teach programming at a level of understanding higher than cut-paste-modify.
So forget about graphics and sound to begin with and start with the basics: Bits and numbers. And then show how you can build more complex data from simpler components and how programming is very much a game of defining data structures and making decisions based on structured decomposition and inspection of data. Don't try to motivate by solving "real world" problems. That just adds the complication of abstracting concrete problems to abstract data, which, while an important issue, is something you should not learn until you are thoroughly familiar with manipulating abstract data. (Abstract in the sense of not having an inherent "meaning").
Programming isn't the only thing to teach in ICT. There are all the non-technical aspects such as ICT in society, ethics, law, and so on. But programming -- especially at a low level -- imparts systematic problem analysis and solving and how to work in uncompromising environments, which are skills that are useful even outside ICT.
The 6502 on the BBC was 2MHz, twice as fast as on the C64. The C64 could, of course, exploit the hardware sprites to overcome some of the speed difference, but 3D games like Elite and Sentinel (that don't use 2D sprites) ran more smoothly on the BBC than they did on the C64.
While the BBC only had 32 KB compared to the 64 KB of the C64, all of this was easily accessible, unlike on the C64, where the BASIC ROM shadowed a large part of the 64 KB. Some extensions to the BBC added "shadow RAM" that shared logical address space with the ROM but could be used for, e.g., extra screen memory. No games exploited this, however, as not all machines had it.
I agree that the C64 had better sound than the BBC, but you could still make fairly good music on it and someone even used it for speech synthesis.
But the C64 had a much larger user base and, hence, more money and time was put into making good games, good music and good demos. This is helped by a still thriving fan community that continues to make new demos and even play C64 game music at concerts.
As other people have mentioned, the BASIC in C64 was terrible -- no real support for graphics or sound except through PEEK and POKE. Also, the way the screen memory was organised also made use of colour a bitch: The colour attributes were for blocks of 8x8 or 4x8 pixels instead of individual pixels. In contrast, the BBC Micro had an excellent BASIC with full graphics and sound support and you could set the colour properties of individual pixels. The latter meant that colour modes required more memory for similar screen resolutions, but the freedom of controlling individual pixels was liberating. And when you wanted to use assembler, there was no need to POKE the instruction codes into memory -- you could write in textual assembler with names labels etc. There was even a Pascal compiler written in BASIC that used this to compile to machine language. And while the BBC didn't have hardware sprites (except the cursor, which was used in some games as a sprite), the 6502 in the BBC was clocked at twice the speed of the 6510 in the C64, so things were pretty smooth anyway.
C16 and Plus/4
The Plus/4 was not a cut-down C64. It was a more advanced machine with a much improved BASIC interpreter and better graphics (121 different colours, IIRC). A "smaller brother", the C16 was supposed to replace the Vic20. I won a C16 at a competition at a computer fair, but since I already had a BBC B, it saw little use and was loaned out to a cousin and eventually sold.
Neither were very successful, partly due to lack of software compared to C64 and partly because they did not represent sufficient advance over the C64. 121 colours is all very well, but not enough to compensate for the lack of software. It would take something like the Amiga to do so.
Why doesn't Sony allow the 3G-enabled version to be used as a phone? It has all the required hardware (excepting, possibly, a microphone), so it should not be that hard to do. And it would avoid you having to carry two devices. It might not be as good a phone as a dedicated device, but not a terrible one either.
The Beeb did have hardware scrolling, which was used for scrolling text in bitmapped modes and for sideways-scrolling games like Planetoid. Due to the memory layout of the bitmapped screens, vertical scrolling was always a multiple of 8 pixel rows (= one line of text), which made it ill suited for vertically scrolling games, where you would want a smoother scroll. I tried twiddling the vertical sync to move the picture up smoothly and then down again while scrolling vertically. This sort-of worked, but was a bit wobbly.
There were no hardware sprites, but you could do it reasonably fast in software, as evidenced by games like Nevryon, which moved a lot of sprites around at blinding speed.
- Apple's spamtastic iBeacon retail alerts launch with Frisco FAIL
- Submerged Navy submarine successfully launches drone from missile tubes
- Pix Astroboffins spot HOT, YOUNG GIANT where she doesn't belong
- Cache in the Attic El Reg's contraptions confessional no.2: Tablet PC, CRT screen and more
- Developer unleashes bowel-shaking KILLER APP for Google Glass