Review: Almost Everyone's Guide to Science by John Gribbin

Sep 182010
 

Almost Everyone’s Guide to Science is a science book for non-scientists. John Gribbin is a popular-science writer who has a clear writing style, yet his words keep you turning page after page. However let me state right off the bat that the book assumes some familiarity with many of the scientific concepts. As such, the book is not for the uninitiated. This issue is heightened by the fact that the book contains no illustrations or photos. While this may not be a real issue for the scientifically savvy, it may be challenging to the rest.

The book starts by some history and background to major scientific breakthroughs and achievements. It then progresses to the atomic theory, quantum mechanics and the physics revolution around the turn of the 20th century. The narrative takes one deeper and deeper into the physical world. Specifically, we look at the atom from its early models, down to the discovery of its components. Gribbin then goes on to describe the electrical and chemical properties of atoms and what makes an element active and some inert. This progression takes us well into the realm of chemistry and chemical reactions. Organic molecules are described and the difference between organic and inorganic is clarified. At this point the book has covered the Hydrogen, Carbon and Oxygen atoms to a great degree. Gribbin explains why the Carbon atom is so unique in terms of its ability to make bonds and participate in chemical reactions unlike any other element.

The last section of the book takes us through yet another transition from the world of simple molecules to polymers and very, very complex molecules. This transition is not trivial, as it takes us from the realm of chemistry into that of biology, or at least molecular-biology. RNA and DNA are the building blocks of life, but until we get there, we need to understand what chemical matter is necessary and how they are formed. The complex elements that form the basis of DNA is explained and the book concludes with DNA and self-replicating molecules with millions upon millions of atoms in each one of them.

Overall, the book didn’t disappoint. At first I thought the length at which history and physics was presented put the book squarely in the physics department. I even thought at one point that he ought to have called the book “Almost Everyone’s Guide to Physics“. At least until we got to ions, chemical reactions and solidly into chemistry. However, I was delighted to see the transition and the connections made between these scientific domains. This is unlike any other book that I’ve read. Gibbin doesn’t disappoint. The book is well researched and well written. The narrative is fairly easy to follow, even when the subjects gets complicated and a bit hard to describe by words.

This was my second book by Gribbin, the first being Richard Feynman: A Life in Science,  and I must say both were very good reads.

Books

Aug 082010
 

Here, I keep track of the non-technical books I’ve read, I’m currently reading (or are on hold) and books I’d like to read next or in the future. I’ll try to write short reviews on some of them as time permits.

The list contains only complete books read in whole, no articles, interviews or previews. Some of the books in the wishlist were skimmed or read in part. They are listed so I’d read them in whole. Some others were read in part but I’ve since decided not to read them in whole; these are not listed at all.

Starred items have been read in whole or in part multiple times.

Books read:

Fiction:

  1. The Hitch-hiker’s Guide to the Galaxy (5 books)* (Douglas Adams).
  2. The Salmon of Doubt (Douglas Adams).
  3. The Godfather* (Mario Puzo).
  4. The Da Vinci Code (Dan Brown).
  5. Hearts in Atlantis (Stephen King).
  6. Oliver Twist* (Charles Dickens).
  7. Jane Eyre (Charlotte Brontë).
  8. Pygmalion (George Bernard Shaw).
  9. Jonathan Livingston Seagull (Richard Bach).
  10. The Little Prince* (Antoine de Saint Exupery).
  11. The Metamorphosis (Franz Kafka).
  12. Slaughterhouse 5 (Kurt Vonnegut).
  13. Ishmael (Daniel Quinn).
  14. The Diaries of Adam and Eve (Mark Twain).
  15. Brothers Karamazov (Fyodor Dostoevsky).
  16. The Snows of Kilimanjaro (Ernest Hemingway).

Non-Fiction:

  1. A Brief History of Time* (Stephen Hawking).
  2. Black Holes and Baby Universes (Stephen Hawking).
  3. The Universe in a Nutshell* (Stephen Hawking).
  4. A Short History of Nearly Everything* (Bill Bryson).
  5. Dreams of a Final Theory (Steven Weinberg).
  6. Kinds of Minds (Daniel Dennett).
  7. Captain Scott (Ranulph Fiennes).
  8. Surely You’re Joking Mr. Feynman* (Richard Feynman).
  9. What Do You Care What Other People Think? (Richard Feynman).
  10. Perfectly Reasonable Deviations from the Beaten Track (Richard Feynman).
  11. Richard Feynman: A Life in Science (John and Marry Gribbin).
  12. T Rex and the Crater of Doom (Walter Alvarez).
  13. The Red Limit (Timothy Ferris).
  14. The Universe in a Single Atom (Dalai Lama).
  15. ABC’s of Quantum Mechanics* (V. Rydnik).
  16. Einstein’s Unfinished Symphony (Marcia Bartusiak).
  17. A Beautiful Mind (Sylvia Nasar).
  18. Pale Blue Dot (Carl Sagan).
  19. The Demon Haunted World (Carl Sagan).
  20. The Ancestor’s Tale (Richard Dawkins).
  21. The Greatest Show on Earth (Richard Dawkins).
  22. The God Delusion (Richard Dawkins).
  23. God is not Great (Christopher Hitchens).
  24. The Portable Atheist* (Christopher Hitchens).
  25. Articles and Essays* (Bertrand Russell).
  26. Religion & Science* (Bertrand Russell).
  27. The End of Faith (Sam Harris).
  28. Letter to a Christian Nation (Sam Harris).
  29. The Pluto Files (Neil Degrasse Tyson).
  30. The Truth About Muhammad (Robert Spencer).
  31. Jesus Interrupted (Bart D. Ehrman).
  32. Why Evolution Is True (Jerry A. Coyne).
  33. Why People Believe Weird Things (Michael Shermer).
  34. The Borderlands of Science (Michael Shermer).
  35. Philosophy: A Very Short Introduction (Edward Craig).
  36. The Physics of Star Trek (Lawrence Krauss).
  37. Almost Everyone’s Guide to Science (John Gribbin).
  38. Stuff of Thought (Steven Pinker).
  39. The Antichrist (Friedrich Nietzsche).
  40. Dialogs Concerning Natural Religion (David Hume).
  41. God’s Problem (Bart D. Ehrman).
  42. A History of God (Karen Armstrong).
  43. Death By Black Hole (Neil deGrasse Tyson).
  44. The Moral Landscape (Sam Harris).
  45. Collapse (Jared Diamond).
  46. How The Mind Works (Steven Pinker).
  47. Fermat’s Last Theorem (Simon Singh).
  48. Before the Dawn (Nicholas Wade).
  49. The Problems of Philosophy (Bertrand Russell).
  50. History: A Very Short Introduction (John Arnold).
  51. Physics of the Impossible (Michio Kaku).
  52. Last Words (George Carlin).
  53. How We Decide (Jonah Lehrer).
  54. Confessions of an Economic Hitman* (John Perkins).
  55. Existentialism: A Very Short Introduction (Thomas Flynn).
  56. How To Argue And Win Every Time (Gerry Spence).
  57. River out of Eden (Richard Dawkins).
  58. The Pleasure of Finding Things Out (Richard Feynman).
  59. The Rational Optimist (Matt Ridley).
  60. Zen and the Art of Motorcycle Maintenance (Robert M. Pirsig).
  61. Meditations on First Philosophy (Rene Descartes).
  62. The Shock Doctrine (Naomi Klein).
  63. The Age of Reason (Thomas Paine).
  64. Dreams from my Father (Barack Obama).
  65. The Grand Design (Stephen Hawking).
  66. Hitch-22 (Christopher Hitchens).

In Progress:

  1. Our Inner Ape (Franz de Waal).
  2. Biblical Nonesense (Jason Long). 54/181
  3. The Liar Paradox and the Towers of Hanoi (Marcel Danesi). 120/259
  4. Kepler’s conjecture (George G. Szpiro). 40/306
  5. To Kill A Mockingbird (Harper Lee). 1/11
  6. God According to God (Gerald L. Schroeder).

On Hold:

  1. The Satanic Verses (Salman Rushdie). 1/30
  2. The Character of Physical Law (Richard Feynman). 1/6
  3. The Selfish Gene (Richard Dawkins).
  4. Paradise Lost (John Milton).

Fiction Wish List:

  1. Candid (Voltaire).
  2. Micromegas (Voltaire).
  3. Pagan Christianity (Frank Viola).
  4. Labyrinths (Borges).
  5. Atlas Shrugged (Ayn Rand).
  6. Animal Farm (George Orwell).

Non-Fiction Wish List:

    Philo

  1. The Republic (Plato).
  2. A History of Western Philosophy (Bertrand Russell).
  3. Thomas Paine’s Rights of Man (Christopher Hitchens).
  4. Discourse on the Method (Rene Descartes).
  5. Philosophy Who Needs It (Ayn Rand).
  6. Capital (Karl Marx).
  7. Dialogues (Plato).

    8. Theo

  8. Atheism, A Very Short Introduction (Julian Baggini).
  9. Milestones (Syed Qutb).
  10. Islam Unveiled (Robert Spencer).
  11. Why I am not Muslim (Ibn Warraq).
  12. The Christ Conspiracy (Acharya).

    13. Bio

  13. The Making of the Fittest (Sean Carroll).
  14. Origin of Species (Charles Darwin).
  15. Genome (Matt Ridley).
  16. Evolution and Extinction (Stephen Jay Gould).

    17. Physo

  17. The Black Hole War Susskind vs Stephen Hawking (Susskind).
  18. The Fabric of the Cosmos (Brian Greene).
  19. The Whole Shebang (Timothy Ferris).
  20. Just Six Numbers (Martin Rees).
  21. E=mc2 (David Bodanis).

    22. Scio

  22. The Language Instinct (Steven Pinker).
  23. The Blank Slate (Steven Pinker).
  24. Guns, Germs and Steel (Jared Diamond).
  25. The Oxford Book of Modern Science Writing (Richard Dawkins).

    26. Socio

  26. Infidel (Ayaan Hirsi Ali).
  27. Nomad: From Islam to America (Ayaan Hirsi Ali).
  28. The Audacity of Hope (Barack Obama).
  29. The Snowball (Warren Buffet).
  30. Moab is My Washpot (Stephen Fry).
  31. Mein Kampf (Adolf Hitler).
  32. Genius (James Gleick).
  33. Feynman’s Rainbow (Leonard Mlodinow).

To Checkout:

  1. Modernity (Jurgen Habermas).
  2. Shakespeare’s Universal Wolf: Studies in Early Modern Reification (Hugh Grady).
  3. Time and the Other (Emmanuel Levinas).
  4. History of Madness (Foucault).
  5. ().

The Perfect Coffee

Mar 292009
 

I love coffee. I want my coffee to smell and taste perfect! Nothing less than perfect. If it’s not, don’t want it. So how do you go about making one?

A photo of a cup of coffee.

Image via Wikipedia

  1. Fresh Coffee!
    Nothing will kill the taste of good coffee faster than age (pun intended) and humidity. Make sure the coffee you use is fresh, stored in a dry place. If you prefer to grind them yourself, buy fresh ones and make sure they were stored properly.
  2. Oily Coffee!
    Coffee gets its smell and taste from the oily elements in it. Look for oil “stains” floating in your cup when you make one. The more there are, the richer the coffee!
  3. No boiling water!
    Coffee changes its taste if over-cooked. When hot water is added to coffee it cooks. However, boiling water over-cooks coffee. So no boiling water. Instead, boil the water, then leave it to cool down for a bit. 90C or 194F is about the right temperature.
  4. Keep it warm!
    Coffee tastes best when it’s hot. Not burning hot, but not cold either. The taste changes with the temperature and people have different preference as to how they like their coffee to taste. Granted, some even like it rather cold, but most don’t. Make sure the coffee stays warm for the longest time by first warming up the cup. After boiling the water, pour some into the cup, and leave it for a few seconds. This will keep the coffee warm for the longest time, and it won’t get cold faster as you drink it.
  5. How much Coffee?
    Too little coffee and it will taste like dirty hot water, too much and it will be too thick to drink. As a rule of thumb, try 2 tea spoons per 200ml cup. Some go 2 spoons per 250ml (standard mug), others need more caffeine-per-sip do 2 spoons per 150ml.
  6. How much Sugar?
    Again, it depends. But as a good guide, try to use less sugar than coffee. You don’t want your coffee to taste like jam!
So there you have, perfect coffee in 6 easy steps. Did I forget something? Got it all wrong? Drop a line or two in the comments.

Getting up to speed on Django

Mar 282009
 

Recently I’ve been interested in web dev and web standards after disappearing from the scene for about a decade. Back in ’97 I was enjoying the ride of the web technologies, design, server and client-side programming, browser wars and what not. But all that had to end someday and that day came in mid 2000. I have a performance craze and wanted to dive deep into the world of desktop applications, servers and particularly highly scallable architecture, low-level (read: assembly) optimization and advanced algorithms. So I left the world wide web only to come back and rediscover it a decade later.

Finally interactive-web is here. Finally! Looking back at static HTML and how boring they looked, how hard and complicated it was just to get feedback from users and, even with that much primitive functionality, how incompatible web browsers were, gives me a shiver.

Now I have to cover a lot of ground. So much has changed and so much to catch up with. I have some experience with Python, honestly I love it. I’ve been using it on and off for a few years now. I thought I’d start with Python-based solutions. Some simple pythong http server (web.py). I do enjoy reading code, so I started by reading web.py. Fun stuff.

Django Tutorials? How about one better: Screen Casts! If reading code is good, reading working-site code should be better. Last, but never least, I had to get dirty with some code and created a toy Wiki in Django. I should say, the learning curve was rather smooth. Django has some quirks (queries) and some things must be done is a very specific way (projects/apps, models/views/urls …) but the thing that I find a bit annoying (especially during development) is the lack of support to import/create initial data (in the DB). The syncdb command is handly, but doesn’t work as expected when you change existing models. Probably works for some trivial cases, but add/remove some column, or mark one as index (or remove an index) and it will silently ignore you.

It’s come a long way since ’05 though. So I’ll cut it some slack. Plus, it’s probably the best python web framework. Not to mean that it’s perfected, far from it. Version 1.0 is in the very recent past (current stable version is 1.0.2 with 1.1 beta just released.)

Django and Python, what next? jQuery, JSON and Ajax. Then jump to CSS, Selectors and HTML 5.0. Not that they all work properly on all modern browsers, but exciting technologies nonetheless.

Tech Savvy vs. MBA Project Manager

Jul 222008
 

Here is a story from the trenches…

Almost 3 years ago during a job interview one of the interviewers made a comment about how they never hire MBA’s for managerial positions. I didn’t get a chance to ask, when she continued to highlight the advantages (brag, really) of working with a superior who had worked as a programmer and climbed his/her way up the food chain. “We never have to talk to an MBA around here,” she added, and went on to finish with “everybody knows the code.”

The Ideal Project Manager?

You know, she’s talking about the kind of person who would know how to make time estimations and complexity assessment because, well, they had worked on similar things themselves. Not only that, imagine a supervisor who has actually worked on the very same projects that you’d be working on! No more lengthy meetings discussing time estimates and project plans, no more trying to hopelessly convince the manager why we need that extra person to pitch in to finish on time, no more wasted time attempting to find analogies of “spaghetti code” and hacks that must be refactored away before we add the next big thing, and more importantly, you’d have someone up the managerial food chain getting more realistic requirements and deadlines right off the bat before you even hear about the next project. After all, they know as much as the team everything there is to know about the codebase and software engineering… or so I thought!

I got hired alright. At first, I was rather amused by the idea; most everyone had worked on what I was working on at some time and every body seemed to have some idea about it. I imagined talking to the project manager about some project and how he’d point out some tricky part and that I should probably add in an extra week just to make sure it’s covered. I imagined hearing anecdotes and funny stories. In my mind I thought I would never have to talk the manager into anything; s/he would know what I’m talking about, and many times I expected them to tell me they’d extend the deadline because they know more testing would be needed. They know the code!

Enter Mr. MBA

Well, before I tell you what you probably expect anyway, let me tell you about an MBA who got hired at a time when there were no candidates for the position of a PM. They needed a PM, and they needed one immediately. So they hired Mr. MBA. Unlike what I had expected from an MBA, and unlike the typical Mr. MBA that I ran into throughout my career, this one was different. For a start his estimates were very realistic and often more accurate than the team’s! He was also very understanding. He’d get feedback from the team, make his own calculation (almost always to the team’s benefit) and take it up the chain. So often he’d take my estimates and add a 20 or 30% and make a comment to the effect of “QA is too busy, they’ll probably delay this project” or “we have external dependency; you can never know how effective they will communicate”. And almost always he was right on the money! The only times that he’d push for a shorter schedule or demand more aggressive results is when the success of the project directly depends on these factors and he thinks there is a way to optimize the project plan. And he’d find a way to reorganize things around and optimize things to get the right results.

How well do you think the other managers did? Needless to say they were a huge disappointment. They were the typical MBA I had in mind. Extremely rigid in their methods. Very opinionated and argumentative. Snobbish. Typically cutting any estimate by half and exclaiming why it would take that long to get such a trivial task done. Complaining and whining at every barrier or issue. Complete babies. And at the end of the day, they cared more about proving they were right than to get things done.

Why?

Here is why I think things turned out the opposite of what I expected. I think the reason that managers with technical background failed is because they almost always overestimate their abilities and undervalue their peers’ assessment. You see, where the MBA doesn’t try to imagine himself working on the tasks and projects, instead relies on historic data, experience, statistics and plain common sense, the tech manager tries to guess how long it would take him to do it.

Programmers are not the most humble. It’s easy to overestimate one’s abilities especially when you don’t want to look like you’re on the slow side in front of your once-peers, now subordinates. This is exacerbated by the fact that the manager in question probably hasn’t typed a single line of code in months. But even if they do, they still almost always undervalue the feedback of the team. In short, it’s very hard for someone who’s done a job to play a different roll and assume that s/he know nothing about the subject. After all, their advantage was supposed to be the very fact that they have been programmers. They are expected to use their experience! However, those who can’t get over the feeling of competing with their subordinates are doomed to do a bad job. While the tech manager is wasting energy completing with his/her subordinates, Mr. MBA was trying to solve real problems and work with the team.

Do you have a similar story? What’s your take on the subject? Are managers with programming experience better software PM’s or MBA’s know best?

REST Web Services Protocol

Jul 172008
 

I’ve been researching Web Services and Web API when I came across this cunningly-named protocol: REST*.

I’ll try to put together the key points and pointers that I collected in my journey and try to give an introduction to the whole affair.

What Services?

Web Services is the fancy name behind the simple idea of making documented requests to load/store some data from/onto a web server. The idea is simple because you could (and some did) do much of the same things if you were smart and determined enough., way before the name was invented. Consider getting some HTML page and parsing data from it. Same would be true if one knew the parameters of search queries, generate the POST or GET commands on HTTP and processed the returned HTML files. Through hackery, one could do quite a bit. But any change in the web site in question, and your code would break; you’d have to re-hack it.

The main advantage of web services I’ve already mentioned; they are documented. This is not a trivial fact. The details of the resources (or services, to use the new terminology) are well defined and documented (no need to guess the POST details or URI structure and naming) and not only that, but the results are in well-formatted and documented form (typically in XML, but YAML is making headway). So the whole thing can now safely be called API (Application Programmer Interface). In addition, more of the internal functionality are usually exposed, where before one would be limited to whatever public services were available.

At some point some web sites thought it would be a good thing for their business growth to give more power to the users and 3rd party vendors. They documented their service interface. More accurately, they added a 3rd party API to their internal system (typically as an afterthought). Many followed suit. Now it’s usually designed into new web sites and web applications.

Not surprisingly there are many ways to go about designing, implementing and accessing web services. The roughest approach is some form of RPC, while mature form would be something like SOAP. REST, on the other hand, is somewhere in between. Apparently there was a huge debate about it (I’m not sure it’s settled).

According to Wikipedia:

REST strictly refers to a collection of network architecture principles which outline how resources are defined and addressed. The term is often used in a looser sense to describe any simple interface which transmits domain-specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies. These two meanings can conflict as well as overlap.

So what is REST anyway?

REST (Representational State Transfer) is an architecture of structuring, organizing and managing (at runtime) a set of resources and services. REST overloads the existing resource identifiers to create, read, modify and pass state information from one to another.

REST Principles

Here are the main REST principles in a nutshell:

  1. URI’s are the API; create the missing, view/edit the existing, delete is terminal editing.
  2. The server is stateless; state transitions are in the URI’s.
  3. XML is not necessarily the format for input and output; use whatever is handy.
  4. HTTP is typically used for the communication layer; while canonical, HTTP is replaceable.

Conclusion

After reading many debates and comparisons between the REST approach, RPC and SOAP (and other WS-* protocols) I think I’m of the opinion that REST is the way to go. It has so many advantages that appeal to me that it’s hard to see why not use it. WS-* seem to have its use cases too, but it’s a rather limited one.

REST is very simple and is a natural fit for the web. If you have even the most static web site, it’s a rather retarded form of REST. However, to have the simplest working WS-* protocol, you’d have to invest an untold amount of time and energy. In addition, REST is the simplest thing that works, which translates into flexibility points. The more rigor and formality you put into a system, more robust it might seem, but also much harder to adapt and change. REST drives its rigor from the high-level principles that, when followed, give high predictability to the system.

It’s like your classic monolithic concrete building; once you poor the concrete in the casts, you can’t change without blowing it up and starting over. On the other hand, a more modular and componentised approach will give you the flexibility of changing the shape and form of your structure over time. As things mature and experimentation fades into a working system, one would undoubtedly need to make non-trivial changes. Any of the gorilla-sized WS-* architectures would be a liability at that point, when REST is ready for change.

* Generally speaking REST is how the web works. It’s not a novelty, just a fancy name given to the architecture.

Further Reading

Basic Programming Problems

Mar 292008
 

Programmers are by and large lucky for having the luxury of practicing what they enjoy virtually anywhere. Compare that to most engineering disciplines and you’ll see that you can’t go far in your garage. May be electrical engineering comes in next, but that’s about the closest you get. Programmers on the other hand can code anything. I mean, anything. The only costs are the hardware (dirt cheap, by the way) and the time to do it. Want to create your game, no problem. Try an OS! Crazy, but doable. And the thing that really tops it all, is that you don’t need to move from your chair, or bed!

A selection of programming language textbooks ...

Image via Wikipedia

This is not a tiny advantage. I’d argue it is the number one reason behind the boom that the field experienced. It’s still going strong. There was a time though when things weren’t any different from rocket science. But that was before the 80’s and the affordable generation of PCs.

So since anything is possible, let’s see what are the top problems any serious programmer should solve at least once (in many cases a dozen!). Here is my list of the top 5 problems that I think give the maximum benefit when solved per unit time spent solving them. These have the benefits of being limited in scope, touch on many areas and sub-issues and are potentially useful. Also, they require only the most basic knowledge and tools to solve. You can solve any and all of them in text mode. Even the games may be simulated with text-based interfaces (although that way you won’t learn about graphics).

1) Calculator

This is really simple. Just write a program that would do the 4 basic math operations: add, subtract, multiply and divide. Then add some more. The point of the exercise is of course parsing and operator precedence. You are exposed to the world of parser design, expression trees and possibly symbol tables (if you add variables or unknowns to the mix). What I like about this problem is that it’s very easy to get a basic version running and then add complexity. Also, you get to define the rules (such as precedence) and complexity (whether there are parens and variables or not). It pays off real quick.

2) Arcade Games

I’d say Tetris, but I don’t think it’s the only one that qualifies. There are so many games one can write that have the same basic features: Pacman, Arkanoid, Snakes and Sokoban just to name a few. The main benefit is to design a state-machine, real-time processing, AI, Graphics, collision-detection and much more. Yet another problem that may start with very limited features and extended as much as necessary. 3D worlds not being an exception. Besides being fun, games are so multi-faceted that you have to touch upon so many domains and problems that they are very educational. The experience is just unparalleled.

3) Maps and Trees

You can’t go far without arrays and list and queues and the numerous data structures. Most programmers have to write similar structures indirectly and unintentionally. Still, many try to dodge writing them by using standard libraries or 3rd party code. There is nothing like writing an abstract map based on a hash-table and another based on a binary search tree and put them head-to-head in performance comparison. Try programming a map that would beat your best alternative in both speed and space. Balancing trees is yet another complex problem. Many algorithms with many trade offs. The benefits of this problem is to learn more about the basic tools of the trade while learning all about complexity and efficiency along the way. Did I mention that you will use lists and arrays in maps and trees? Writing highly efficient maps and trees is one challenging task that is not even apparent until you start thinking about it.

4) Database

There are multi-million dollar databases out there. But can you create your home-grown version that has any number of the features the big guys have? Try something that is as flexible as storing any data type. Then add efficient searching features. Then try adding relations, hierarchies, indexing, even a query language! You’ll learn all about file formats, on-the-wire data types, serialization, complex data structures, sorting and searching, data manipulation and data mining to name a few. Furthermore, you’ll appreciate what it takes to create efficient and scalable data structures on and off the disk.

5) Programming languages

This is one of the most complex problems of the programming world. I’m of course talking about compilers and language design. Try writing an interpreter for a popular language or a dialect of one. Say Basic or Pascal. Try Lisp. Why not even go as far as inventing your own. You’ll learn about language design, parsing, symbol tables, optimization, simulation, automata and many, many more. This is not only fun, but it’s also a very challenging task. I can’t promise that it would become the next big thing, in fact, it probably will only be used by you. But this is one of the more challenging problems that may be limited in scope and extended as needed. And if you feel crazy, write a debugger for your interpreter.

I’m sure one may add other problems, replace some in my list or simply say there is no such list. Anyway, here you have it. This is what I’d recommend for practice.

 Newer Entries
QR Code Business Card
This website uses a Hackadelic PlugIn, Hackadelic SEO Table Of Contents 1.7.3.