How to make a bike in 20 languages

Want some silly programmer humor ? Here’s a quick attempt at explaining how people would build a bicycle using the real-world equivalent of the programming languages I know of.

  • Ada: A bike is a very complex piece of mechanical engineering on which the life of people depends, so such a project should definitely be approached with care. You hire the best bike engineers you know of and define with them what constitutes the perfect bicycle for your purpose, then you establish a very detailed requirements document for your project, buy the components that best match the requirements (or make them yourself if none fits), and have them assembled by a team of highly skilled mechanics. The project will take very long and cost a lot, but in the end you will probably be satisfied with the result.
  • Assembly: You believe that real engineering shouldn’t need many sophisticated tools, so you buy large crates of raw material, a blowtorch, and a diamond saw, then you set out to design and build every single part of your bike. If your project works, it will probably be the most optimal bike ever for your purpose, but it will take ages, you will hurt yourself a lot, and your product will have many manufacturing defects in the early stages.
  • C: Mocking the miserable attempt of the assembly user, you end up doing essentially the same thing with a set of slightly more sophisticated tools. Maybe you will add a caliper to the list above. Unlike the assembly user’s bike, your bike might possibly run on other streets that those you designed it for, if you took sufficient care to ensure this is the case.
  • C++: Like all low-level bike builders, you have a somewhat unhealthy obsession of building an absolutely perfect bike that makes no compromise. However, you also acknowledge that there is a tradeoff between final product performance on one side, and development time and comfort on the other. So you find within your area a workshop full of highly sophisticated tools that you feel best match your task, and try to use them with all safety bypassed (“Who needs safety ? It gets in my way !”). If you have both the design and manufacturing skills, you might build something great in much less time than the others. Otherwise, you will likely end up in the hospital in a worse state than the C and Assembly users.
  • C#: You are torn. You are somewhat attracted to the Ada ways of careful design, but at the same time you also want to build something fast and cheap without much care at times, like the C family users. In the end, your development process ends up being a very strange mess, where you use a little bit of all the other approaches without really commiting to one specific methodology. Unlike the C++ user, you tend to use your tools with the safety on unless there’s a good reason not to, but even with this it is hard to guess whether your project will work or not because of how disorganized you are.
  • CSS: In the end, you decide that building a bike is too complicated, and probably a pretty drawing of a bike will satisfy you. However, you end up getting the colors wrong, as any time you change them somewhere in your drawing, you forget to change them somewhere else. Also, you have a very hard time getting feedback on your work as for some strange reason, there are not two people in the world who see your drawing in the exact same way;
  • CUDA: You find riding a bike pretty tiring, you are not in that much of a hurry, and you also happen to live in a castle where thousands of servants obey your command. Therefore, you decide that the best answer to your problem is not a bike, but a giant throne on wheels which is dragged by your servant army on the command of a whip. You have a very hard time teaching your servants to move all together, though, and many of them sadly end up crushed by the machine’s wheel during the development process. Still, you can certainly brag about how many friends you can take with you on that rolling throne without slowing down your trip in any way.
  • Delphi: You master mysterious magic powers which allow you to summon bikes directly out of blueprints, provided that you have a sufficiently good idea of how a bike works. The resulting bike does not have the sophistication of custom-built bikes, and it only works on cycling tracks, but many other bike builders envy how easily and quickly you can summon bikes out of thin air.
  • Fortran: You learned old school bike engineering. You do not draw blueprints on a computer, but using paper and a set of carefully chosen pencils. You do not use many automated tools, but make sure your tools are top-notch. This gives you a great understanding of the bike building process that you like to brag about, but some question your continued refusal to use more modern approaches where it would fit your problem better than the old ways.
  • Go: You are attracted to the CUDA ways, but you do not have that many servants handy. So you bribe Tour de France riders so that the one who ends up on the finish line claims that he has used one of your bikes, and then you wait for the competition to finish. Some say that what you are doing is not real engineering, but you concur that unlike others, you do your best to leverage teamwork.
  • Haskell: The thought that bikes are unsafe has always tortured you. You cannot spend a day without thinking about all the poor cyclists who end up killed on the road. So you want to build a bike that is provably impossible to drive in an unsafe way, and to this end, you set out to explore thousands of academic papers on how to build self-driving bikes. You find out that this is an open research problem, and although very elegant, your development process takes ages. In the end, people are not very satisfied with your bike as it refuses to move anywhere, yelling with a robotic voice that due to the laws of physics, any kind of useful motion is fundamentally unsafe.
  • HTML: Bikes are useless without good documentation, so you set out to write some. However, you quickly find out that you end up repeating yourself constantly, and that any kind of change to your plans is difficult because of this. Consequently, at some point down the road, you give up and use some kind of automated documentation generator instead of writing it directly yourself.
  • Igor Pro: You do not have much time, so you have your favorite mechanic build the bike for you, telling him about all you need him to do in clear terms. Sure, it won’t be perfect, the mechanic will charge you an awful lot considering the quality of the work he is doing, and the result is so strangely built that you will subsequently be locked in to that mechanic for any servicing operation. But when it works, this approach is certainly a bliss.
  • Java: You agree with the Ada developer that builing a bike is Serious Business. However, unlike him, you never took the time to actually understand the rules of good engineering, and you end up rigidly always applying a methodology that very clever people guaranteed to be foolproof, without actually thinking about how appropriate it is for your problem. The positive side of your approach is that you will easily find workers who know your methodology and your highly consistent blueprints will be easy to understand. On the other hand, much pain will await you when you will want to do something that your methodology of choice is bad at, and overconfidence in your method might lead you into some stupid mistakes. The result is pretty much an average industrial bike : not particularly good nor bad, and developed in an average time. Managers love you because your approach is so predictable. However, users dislike that your bikes are quite heavy, insecure, and come plastered with ads.
  • Javascript: You don’t understand why people keep confusing you with the Java guy, as your way of doing things is obviously very different. All your engineering work is actually done not by you, but by an incredibly smart 7 year old kid to whom you simply do your best to describe what you want. The main problem is that being a kid, your genius engineer is overly trusting of others, and will tend to think that he has understood your problem when in fact it hasn’t. Also, the distance you take from manufacturing may lead you to misunderstand the bike building process and ask for stupid things, which your kid engineer will not warn you about. Still, if you are careful enough, you can certainly build wonderful bikes in a short time with this approach, although they will be somewhat heavyweight compared to competition.
  • LabVIEW: Like the Igor guy, you hired a mechanic in order to save time and effort. However, your mechanic is a bit different: he is a requirements freak. You should never tell him how you want something done, or he will yell at you for hours about how this is not good engineering. Instead, just tell him what needs to be done, in clear language, and he will find the best way to do it. As everyone knows, however, a problem with natural language requirements is that they quickly get messy, so if you are not careful you will end up lost in your own explanations. Still, that is certainly an interesting way to build a bike.
  • PHP: You are the one that the HTML guy turns to first after giving up, but you can actually do a lot more than just writing documentation. Although your tools are not very adequate, you could certainly build a bike if you wanted to. However, to this end, you would have to strengthen your somewhat messy engineering process, as right now no one understands your work and that is a real problem whenever one of your products turns out to be faulty.
  • Python: Your approach is somewhat related to that of the Javascript fellow, although you certainly do not want to be associated with him. And like the C# guy, you like to experiment with many tools and processes, and can never truly settle on a relatively clearly defined way of doing things. But you know better than to hire a 7 years old kid, so you work with a 13 years old genius teenager instead. That teenager is a lot better at understanding your mistakes, but due to spending too much time sitting in front of the TV eating potato chips he is quite a bit overweight and doesn’t quite realize that the bikes he is producing are way too heavy for the average cyclist. So if you want him to build a high-performance road bike, your only hope is to convince him to work together with a more performance-focused engineer.
  • SQL: You work at a big bike company, within the logistics department. You are not so much concerned about building bikes, but you are very concerned about sending lots of bikes to the right place, avoiding the annoyances of real-world travel such as traffic jams or plane pilot strikes. Unfortunately, your dedication and high quality work comes at the cost of being sometimes naive, and company customers who are aware of this keep tricking you into delivering bikes to them for free, or sending large amounts of expensive bikes to a dumpster. Managers who are aware of this will usually try their best to prevent people from directly contacting you, instead forcing them to contact more trusted people first.
  • SPARK: You like the Ada guy, and in fact you two are closely related. But you think he doesn’t go far enough. Like the Haskell guy, you have a strong fantasy of producing bikes that cannot fail, but unlike him your thinking is somewhat more down-to-earth : regular bikes are good enough, we just need to make them in the right way. Consequently, you end up always reading research papers as a way to improve your manufacturing process, cross-check what your employees are doing, and overall formalize a very elaborate and costly product validation process. In the end, though, your bikes will really remain as safe as the people driving them.

3 thoughts on “How to make a bike in 20 languages

  1. cmia11 October 23, 2015 / 11:55 am

    That is funny :)

  2. Membeth September 9, 2016 / 6:05 pm

    Nice comparison, I have an add-on:

    Component Pascal: You are a single well-educated developer and no other developer team was faster to create a market-ready bike since you never had to debug the derailleur gears or the handlebar during operation. The bike is extremely safe and reliable as well as very durable and easily maintainable. Unfortunately nobody does buy your bike since for clients it seems absolutely impossible to create such an outstanding, comfortable and fast vehicle in such a short time.

  3. Hadrien September 10, 2016 / 12:40 pm

    Sounds similar to my memories of Object Pascal and Delphi then : a total bliss as long as you can find what you want in the standard library :)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s