Sorry to be so long replying. It was largely because I wasn’t sure what to say. But one answer just occurred to me: inventing the concepts people make programs out of. Aka language design.

Long it was. I wrote him Aug 24, 2007 and he replied yesterday. Amazing that someone doesn’t just forget about an email after all this time.

If you don’t know him, the language design he talks about is Arc and i know him, because of his great essays. At least his older writings are good. The newer stuff doesn’t always reach the old quality.

Once upon a time there was a little-known patent clerk in Bern who received a disappointing annual performance review in ’05

Did you guess who is meant?

If you did, you should read the full article! It features five of the most important papers of computer science and why they should be rejected from publishing.

In the year 2000 the mentality was similiar.

A year ago, Yahoo invested in Right Media, a New York company developing an online advertising network. Yahoo’s investment valued the company at $200 million. Six months later, when Yahoo acquired Right Media outright, the purchase price had swelled to $850 million.

What changed? According to Right Media’s co-founder Brian O’Kelley, very little, except for the fact that Yahoo’s rivals Microsoft and Google were writing billion-dollar checks to buy online advertising networks, and Yahoo felt that it needed to pay any price to keep up.

“I have to say I giggled,” O’Kelley, 30, said of Yahoo’s acquisition, which earned him $25 million. “There is no way we quadrupled the value of the company in six months.”

This excerpt is from Dot-com fever stirs sense of déjà vu. A more famous example than Right Media would be Skype.

EBay acknowledged this month that it had overpaid for Skype by about $1.43 billion

Assuming a cyclical up- and downswings we’re currently near the top of an upswing, like we were seven years ago. This means we will experience a downswing in the next few years. The “bubble will burst again”.

If you think about learning Rails (or any other web framework), because you think about a startup after graduation, think again!

The situation will be different then. It may be harder to find investors who throw money at you. It may be close to impossible to find someone to buy your small company that is rapidly running out of money.

Don’t misunderstand me! There is nothing wrong with learning Rails, if you want to create an interactive website and from what i know Ruby is pretty handy programming language. A web startup may still be a good idea. Just don’t expect to get rich quickly with this.

In short: Don’t bet your career on web engineering just because Facebook is so cool!

In the computer science world the attitude often is against marketing and commerce. The assumption is “marketing” means “selling shit to stupid people”. This assumption is false.

Marketing means to find out “what people want and how to satisfy them”.

In the case of blogging you probably already know what people want i.e. you know what you want to write about. The second part is to satisfy.

1. They need to know you exist. Get your blog public. My biggest success comes from submitting my posts to programming.reddit, but every single link is important. Comments on other blogs are very good too.
2. They need to understand how to get your articles. Subscribing via feed is the obvious way, but you probably can do better than you do now. It helps to get a big orange button or to encourage to subscribe after every article. Some people prefer email, cater them!
3. They need to enjoy it. Make your blog beautiful und useable. Some pictures are nice, too.

There is plenty of blogging advice available. For example ProBlogger. Read and follow! This post is motivated by his Birthday Bash action.

Get blogging! Especially if you write about computer science. I’d like to have some colleagues.

The scourge of his last days was his conviction as a homosexual. He was excluded from governmental cryptographic work for “security reasons” and focused on quantum physics in the last years.

In school the young Alan had a hard time, because he only the hard sciences appealed to him. He flourished, when he finally reached university and was particularly fascinated by the Principia Mathematica and how Gödel shattered that approach. Then he learned about the Entscheidungsproblem stated by Hilbert some years ago as one of the ten big problems in mathematics. This ultimatly lead to his invention of the Turing machine. Though Church also solved the halting problem with his lambda calculus, the Turing machine proof is easier to understand for most people.

When Britain joined the second world war, Turing joined the cryptoanalysis headquarter Bletchley Park and helped to break the german Enigma code. He was a lead developer of the “Bombe” a electronical device to decipher german naval communications.

His experience with electronic devices and his idea of the Universal Turing Machine made him one of the first to dream of “building a brain”. Shortly after the war he tried to build this machine, but got too frustrated with politics. He shifted to neurology and physiology and was an injury away from the Olympic marathon team.

Instead of building computers he focused on using them. He made some important contributions in what he called “the mathematical theory of morphogenesis: the theory of growth and form in biology”.

Unfortunatelly now follows the sad end, you read in the beginning.

You can find a memorial of Alan Turing in Sackville Park, between the University of Manchester building on Whitworth Street and the Canal Street ‘gay village’.

A quantum computer is any device for computation that makes direct use of distinctively quantum mechanical phenomena, such as superposition and entanglement, to perform operations on data. In a classical (or conventional) computer, information is stored as bits; in a quantum computer, it is stored as qubits (quantum bits). The basic principle of quantum computation is that the quantum properties can be used to represent and structure data, and that quantum mechanisms can be devised and built to perform operations with this data.

What is a superposition? What is entanglement? Can quantum computers compute NP problems in P? It’s hard get started in this strange field.

First the basics: Quantum Computing for High School Students by Scott Aaronson is an easy to read introduction to quantum computing in general.

You’ve heard quantum computers can break RSA? Theoretically you’re right. Using Shors Algorithm they can. I won’t explain this here, because Scott Aaronson again has written a beautiful and readable explanation.

Those two links should give you a good start. If not, just read on through Scotts blog.

What you should know about quantum computers: They are not a magic weapon to make computers faster. They can’t compute all NP problems in polynomial time. They are no silver bullet. Quantum computers can solve specific problems due to the quantum phenomenons. Some problems (like breaking RSA) can be reduced to these specific problems.

Currently scientists can build small quantum computers consisting of 7 qubits and have successfully factorized 15 into 5 and 3 in 2001. It’s an engineering problem to scale up the qubits to factorize bigger numbers.

My prediction: It’ll take some time, but eventually (probably decades) we will build quantum computers and scale them up to thousands of qubits. They won’t replace traditional CPUs though, but will work as a coprocessor like Cell.

The scary sidenote for a good discussion (recommended to combine with some drinks): What will happen with the world, once we break RSA? Public key encryption won’t work anymore. No online banking, no e-commerce, no cheap and secure communication anymore. Economy breaks down and world war III wipes out all humans?

He corrected my use of the quotes and then goes on to reply to my question “what are the most important problems in computer science?“, inspired by a talk of Richard Hamming.

I admire Dick Hamming enormously, but I disagree that his first question is “good”. Everybody knows famous, unsolved, “big” problems, which tend to be thought important because of their fame. And perhaps those problems are indeed important … although when they are finally resolved (like the question of deciding equivalence of deterministic languages) I find to my surprise that I don’t get very excited by the result, rather by the method used to get there

I firmly believe that computer science advances by thousands of people solving small problems, which go together and create a massive edifice. Every year that goes by, hardly anything is done that appears to be a milestone worthy of mass attention; yet after five or ten years pass, the whole field has changed significantly. So I’m no fan of “top ten” problem lists.

Let’s hear it for the people who work on and solve small problems based on their judgement of peer pressure. Like for example Hamming.

I agree that the progress in year seems insignificant, but I don’t want to agree that we can’t see where we’re heading with computer science. This blog is my try to get an overview, to get a form stand on the shoulders of the giants and see a littler further.

The drawing is simple, but the humor is great. You’ll need some geekyness to understand the jokes.

Hint: There is always an additional text hidden in the title attribute of the img tag. Your browser probably pops up a text box, if you keep the mouse on the comic for a second.

This means it’s about cold, hard facts. Most of these talks are bad and boooring. A good presentation is hard work, no trick.

1. Buy a book about rhetoric

It is not enough to read one article to give an interesting presentation. Who wants to be a good speaker has to look into speaking.

You could start with the classical The Quick and Easy Way to Effective Speaking.

2. Content is king

You need content. If you don’t have anything to say, keep quiet. Many presentations are quite unsubstantial and need a flashy presenter. This doesn’t apply to us.

The content must be tailored to the audience. What knowledge can you take for granted? Underestimate the knowledge, but never underestimate the intelligence of your audience!

Fill your presentation! Every minute they listen to you, should be worth it. Every sentence must be important.

You often hear the first n seconds are important. They are not. Nobody will leave the room after 60 seconds, but often i know after 60 seconds, whether the speaker intends to fill or use his time.

3. Slow and clear

We’re talking technical presentations. Not wedding oration, not sales pitch, not advertisement, not political speech. This means to omit the filling stuff and go right to the core. This should be also true for the other occasions, but it’s essential here.

Don’t say the same three times in a row with different phrasing. It is better

to speak

slooowly

and clearly

one sentence

after another.

Don’t read your content. Not from paper, not from beamer, not from screen. You have practiced enough to know your text by heart, haven’t you?

4. A good presentation has a climax

A good presentation has one -exactly one- climax. Try to summarize your content into one sentence!

Now minimize that sentence! It should have no comma and no “and”. Imagine your audience would memorize only one sentence from your talk – what would that be? You can say this. “If you keep just one thing in mind from my talk, keep this: A good presentation is hard work, no trick.”

A good presentation has one -exactly one- climax. Don’t fear repetitions in this case. A good presentation has one -exactly one- climax.

The climax determines the rest of the content. Thus if you have your climax, you have a criteria, where you could shorten your talk.

5. Humor is permitted

Yes, you can joke. A funny picture to lead to another topic is permitted, as long as it isn’t too much and on topic.

Don’t laugh yourself! A speaker better has a wry sense of humor.

6. Slide design

You can find good tips at Presentation Zen. A nice rule of thumb is 6×6, though i favor 1×6.

Especially with a technical topic one is ensnared to use bullet points. It doesn’t help. It doesn’t stick. As the speaker, you will read the list point by point, with some intermediary “and” and “uh”, and bore the audience. Do it like Steve, not like Bill!

Animations? Cease and desist!

7. Darned technology

Beamers video projectors and laptops sometimes don’t get along with each other. Computers break. Shit happens.

Show up early and test the real equipment! Don’t trust this test and always carry an USB stick and your slides in pdf form with you.

Live demos are risky because of this. Sometimes it is worth this risk, sometimes it is not.

If it breaks, it’s your fault. Maybe it isn’t, but from the audiences point of view, it’s only you on stage. That directly leads to the next point:

8. Don’t apologize

Who is on stage doesn’t apologize. At least don’t say more than a quick “sorry”.

It doesn’t matter who or what is at fault. It is the responsibility of the speaker to cope with it. It only hurts your presentation in the end.

If you are quick-witted, you may joke about yourself, but return to the agenda as soon as possible!

9. Practice, practice, practice

You can’t practice enough.

The only exception is that you sound like you have practiced more than enough.

If you haven’t practiced enough , you can’t watch your audience. You can read people, whether they have understood, what you just said, or whether you should repeat that. Eye contact happens automatically. Even the “uh” will disappear.

A good presentation is hard work, no trick.

We probably agree that software development should be engineering. Building a software application should be like building a bridge. The problem is that it is not.

Joel Spolsky talks about three phases in software development:

1. Design needs an artist
2. Building needs an engineer
3. Debugging needs a scientist

When the building part is already engineering, we just need to figure out, whether design and debugging can be made engineering or (mostly) optional. If you use a framework like Rails, you don’t need to design (apart from CSS and URLs). Type checking and verification could help to make debugging disappear.

A software developer describes the requirements for a job as a software developer:

1. communication skills “The best developers are often the ones who can explain problems and solutions the most clearly to others”
2. teams “Very few developers really work alone”
3. analytical skills, particularly around ambiguous problems “It’s important that developers understand the intention of what they’re being asked to do as well as the implications of a solution they’re thinking of and can weight and communicate these”
4. development processes “Not a theoretical one—they need to work on teams that use formal, top-down development process, agile development, teams with other developers, teams with test processes, and so on”
5. an ability to learn on the fly
6. competence in several programming languages “C++ is typically a must; C# or some other managed-code language is also mandatory, competence in one dynamic language, such as JavaScript, should also be present and the graduate should have the ability to know which to use when.”

No need for insight into algorithms or math. This may help, but isn’t mandatory.

There is still a big part, where computer science and software engineering intersect. Somebody has to build the standard and extension libraries. Somebody has to understand the math for multimedia and implement it.

For the common (web or desktop) application development, you don’t need to study computer science. This leads me to the conclusion that a software engineering education could be separated from general computer science. Do you agree?