I mean seriously. This is like:

>Hey there new programmer
Err, Hello?

>Weren't you supposed to be here at 9:30 ?

Umm, yes but I couldn't come up the elevator.

> Why not?

Well I didn't know which floor.

> Isn't the floor written on that big board near the elevator?

Oh ah, well I suppose it could have been

> So how did you get here?

I just walked up the stairs and stopped on each floor to see if I saw the company name

> But we are on the 32nd floor?

Yes, it did seem to take a while, especially the knocking

> The knocking?

Well, yes, some of the doors were locked, so I had to knock to ask someone if this was 'AX7121 Systems'

> But, didn't it occur to you when they said NO, to ask them if they knew which floor AX7121 Systems was on?

Ah, yes I did, that caused me to go back down to the 7th floor three times.

>What?

I went back down to the 7th floor three times

>What?

Well someone said you were on the 7th floor, in total I went to the 7th floor 4 times, the 9th floor 3 times, and the 13th floor twice

>But if you had checked the 7th floor on the way up didn't it occur to you that we probably couldn't suddenly move in and appear there so you didn't need to recheck it?

Uh, well now you mention it, but I wanted to use a SAFE algorithm

> Hang on a minute I read your resume, you said you have a 4 year degree in computer science

Yes, I do, I graduated from #blah blah# last summer

> Did you guys ever cover elevator seeking problems?

Oh yes, we did - lots of work on that, it's related to reflection in Java, I know all about that!

> How is it related to reflection in Java?

I could reflect from my Elevator instance to find out what kind of elevator it is, and then I could call the .goToFloor method with a flor

> How would that have helped?

Well, I could have ridden the elevator instead of using the stairs, which would have sped things up lots and made the algorithm more efficient

> Are you joking?

Why would you ask that? It would definitely speed up the algorithm a little bit don't you think?

> I have a terrible pain in the side of my head, by the way, what is your name?

Clouseau

Please. All of that TNG crap. I wanted them to die. I wanted the scene to go like this:

Picard> Yes, but the question is *should* we kill them?
Data> Killing is not ethical
Blah>
Blah>
Blah>
  Enterprise blown from the stars

Enemy captain> If you're going to shoot, shoot, don't talk

Aw you're just jealous because you live across the ditch.

I wonder what Joss Whedon would do with it? He did a smash-up job on firefly.

I apologize to the 'recent' fans, I really *really* wanted to like the 'new' episodes but they sucked. Horribly. I mean terrible horrible waste of all that ILM CPU cycles on digital effects and acting crap.

The reboot of Star Trek was awesome even die-hard trekkies I know who hated it on first viewing got to love it. Well that's all of them except the TNG kids who well let's face it - they just aren't cool and are namby-pamby overly politically correct crap.

So yeah, maybe he can fix it because pretty much after Empire Lucas clearly lost the plot entirely - I mean Ewoks and Jar Jar sucked so badly it was sad.

He needs to learn:

Just because something is different doesn't make it bad or wrong.

For all we know the guy he's complaining about is a demon APL programmer. Or a guy who was partitioning FORTRAN so it ran decently on a super. Or maybe the guys an oldtime LISP dude and all the languages he's coding in makes him lament the loss.

Tracks Suck. Tubes Suck. They are one massive long single point of failure.

One day I was riding on the Acela and I realized the fatal flaw with high speed land transports. Your moving fast and there's no buffer. Now imagine doing 4000 mph. One part of that tube is bad - or there's an earthquake or a cave-in and guess what? Your doing 4000 mph straight towards a large piece of earth that moved into your path. Even a tornado doesn't compare to that. You could fly your 2000 mph aircraft right through the eye-wall of a hurricane and it's almost certainly more survivable than that 4000 transit-pod.

Oh, and in an aircraft you wouldn't have to fly right into the hurricane because you can divert. We know where hurricanes are. We know where thunderstorms are so we can avoid them too. How would you avoid an earthquake?

I'd much rather have a nice buffer of air which even in it's most turbulent state is infinitely more forgiving than solid earth.

Step 1. Close the Leet Javascript serverside apps page you were reading.
Step 2. Wait for the Mark 1 computer to reload it's pipelines. Does it seem like it's working well now? Great! Go on to step 3.
Step 3. Open Wikipedia. Pick a processor architecture. Intel x86, x64, MIPS, ARM, SPARC, PPC, ...
Step 4. Read the page. Notice in many cases different companies make chips that are the same Architecture. Notice how many different IMPLEMENTATIONS of those architectures exist. Are they all the same? No. Just like javascript interpreters there are differences.
Step 5. Only attempt if your Mark 1 computer is working properly: Investigate timing attacks against microprocessors. Hint look at multicore cache information leakage.
Step 6. Only for the polymaths! Now consider, if you wrote some code that managed to determine what code was running in another core due to a shared cache and timing analysis, would that work on all implementations. Hint notice that some implementations don't share caches.

Step 7. Give up. Context switch back to Javascript. Boy writing server side apps in Javascript is a GREAT IDEA. and Hey a new idea pops to mind - javascript is AWESOME - why not use it for the code in pacemakers, or autopilots, or antilock brakes! Wait! Maybe that new architecture is really a way to make a new vulnerability in javascript! Oh wow! Better post that now before someone else beats you to it!

Ask yourself - what is 'great' code. If you haven't seen 'great' code then you need to read more code. It exists. You will know it when you see it.

If you haven't already exposed yourself to languages that embrace re-factoring as a way of life you should. One of the best is Forth. Good Forth is like poetry. Chuck Moore has written several things about software and they are well worth consideration.

Good code I've read has usually got the following in common:

- It's correct - It does what it says it does and sounds like it does.
- It is side effect free.
- It has been re-factored extensively.
- It is as short as it can be without making it more difficult to understand or introducing structures which are fragile or do bad things if you don't use the correct magical incantations which may be non-obvious.

Here's a couple of concrete things you can do with your existing code:

Imagine you wrote a 1000 line program.

Ask yourself can this be a 999 line program? When you get to the 999 line program, ask the same question.

Eventually you will reach a point where you can't reduce the length of the program without making it less clear. At that point ask yourself, can I re-factor it in a larger sense to make it MORE clear while keeping it correct.

Ask yourself if each method, function, class does what it says it does, and sounds like it should do. Check the program is still correct. Is the program robust? How does the code behave when its inputs are changed. If it's production code that will get hammered on then maybe you should add a comment about the time and size complexity.

One of the worst places to find bad code is API's. Experienced programmers know it's truely difficult to write a good API for a non-trivial program that stands the test of time. A good API isn't just sticking a bunch of public methods like so many people think it is. Find an API that's stood the test of time. Read up on it. If the programmer has written about the design decisions then read up on them.

Finally, think critically about what you KNOW and don't KNOW. Learn something new. Don't just skim it, read it and study it till you grok it. It can be something others take for granted say floating point. Read up on floating point arithmetic. Read about its pitfalls. You'd be amazed how many people who say they are good programmers don't understand precision, accuracy or that floating point numbers are imprecise.

I keep meaning to dig into FPGA's more. They do look like loads of fun - thanks for the links BTW!

a machine with custom graphics chipset and custom sound like the Atari 800 / C64 / Amiga. Something open that could be programmed, that ran a fast light OS, and not with the GPU added as an after thought. Something with no spinning disks, just solid state.

Something that could make computing fun again like it used to be 20-30 years ago.
   

You do realize that Thorium is Nuclear too right?

The real fact is that the waste from a reactor is actually an upside. The processes described above, and by prior posters are much preferable to spewing radioactive material out into the atmosphere like coal plants do

The parent(s) are correct. Rocket launches are usually vertical and rapidly start 'pitching' the nose down so the flight is parallel with the earth. The main reason here is drag, but it's also important to understand that traditional bell nozzles are optimized for a specific atmospheric pressure (or lack thereof). That's why there has been so much interest in aerospikes (e.g. X-33)

A few comments about Skylon.

- Not hauling all that heavy oxidizer along is helpful. O2 is much heavier than H2 (See periodic table)

- The Specific Impulse of Jet engines is much greater than chemical rockets. The SSME's have an ISP about 1/5th that of a jet engine. Even the NERVA Nuclear Thermal Rockets had ISP/s about half that of a jet.

- You need to get to about 8 Km/s for orbit. The speed of sound from 10 Km to 30 Km is about 300 m/s. So you get:

A12/SR-71 (J57) was cruising at ~1Km/sec
Kingfisher (Marquard Ramjet) ~ 1.5 Km/sec

That still leaves you 7Km/s of velocity you need. If you figure the Sabre can get 2Km/sec of velocity, using atmospheric oxygen and then use the same engine (hint saves weight and cost) while burning on board oxygen it's pretty cool.

It's actually a pretty cool design, and I wouldn't be surprised at all if this technology hadn't already flown in a black project. The holy grail is a design that takes off horizontally and uses atmospheric oxygen as it accelerates and transitions through jet, ramjet, scramjet, rocket.

You certainly need a 'critical mass' for a new architecture to sell, but it's not all doom and gloom for the other players. We mostly don't write in assembler nowadays. We use compilers. If a good compiler is produced, and made available at a reasonable cost, and a vendor believes a port will be profitable in terms of amortizing the full lifecycle cost of the port then they may port.

To generalize - consider architecture A with resources rA applied to it achieves a performance (either raw or per watt) of pA. If a competitor can create an architecture B that with resources rB give similar performance, and rB is considerably lower than rA then the producer of rA has to absorb the delta of rA to rB or the market has to be such that the delta is outweighed by other factors.

Embedded != Desktop. Embedded engineers are already used to using many different architectures and lighting up different tool chains. They aren't stuck on x86 like many people are.

Disruptive technology may really shake things up. There are chips out there that solutions using them may out perform ARM in power usage by over a couple of orders of magnitude. I used to think the MSP430 was low power. Than I saw the GA144. That thing is awesomely low power.