- Build something you actually need right now. This could be either a tool you can use in your day job, or something useful you can make use of at home.
Consider these example projects ...- Write a simple unit testing framework. Many new languages don't have any unit testing frameworks available when they are first introduced. This project will force you to use areas of the language like reflection and meta-programming. Once completed, it becomes useful straight away, for unit testing your future work in the language.
- Implement a disk usage tool; it summarizes the disk usage of all directories on a disk and outputs to the console. It doesn't require overly complex algorithms but touches a lot of the basics: recursion, filesystems, command line parsing and output formatting.
- Implement a backup/archive script which has command line switches to exclude certain file extensions. It should place the backup into a single .zip or .tar.gz file. The project will touch on the following: recursion, filesystems, command line parsing, compression libraries and regular expressions.
- Port an existing, well known program to the new language. Since you are porting it, you already have the application design work done. This frees up your mind to focus on the specifics of the new language. After you've finished you'll then have a good reference to which you can refer back to, when comparing the old with the new language.
- Find a decent book on the language and read through it all as fast as you can. The goal is not to memorize everything, but to soak up the ideas and idioms of the language. Then write some small but non-trivial project. When you get stuck, hopefully it'll trigger a memory of something from the book, and you can go back to refer to it.
Many of the "in a Nutshell" and "Head First" series of books, both published by O'Reilly, are highly rated by readers - they are available for many popular languages (C, C++, C#, Java, Python, JavaScript, PHP). - Mix action with equal parts learning (reading books/tutorials). Too much action without learning, and you get a lot of poor quality code. Too much learning without enough action, and you fail to absorb the material to a deep enough level.
- Study reference works on public repositories. Find a medium sized project on GitHub which is written 100% in the language. Read though the code and try to understand it. Look for projects written by the language designers or an acknowledged expert.
As an example, with Go, the standard libraries for the language are written in Go and are open source, e.g. here is part of the strings package. In addition, Brad Fitzpatrick and other members of the Go team have several projects on GitHub that you can read and learn from, e.g. here is a Go client for Memcache. - Devote large, uninterrupted chunks of time, at least half a day, to learning the new language. Brief, half hour sessions over the course of the week aren’t really useful, because most of the time would be spent just getting back up to speed on what you previously studied.
- Learning a language shouldn’t just be a solitary endeavor. There are plenty of people who have made the same mistakes that you have, so asking for help is a great way to overcome problems when you get stuck. Some possible sources of help online: Language-specific IRC channels, StackOverflow, Twitter, Facebook groups, Quora, Google+, Google groups. You can also submit your finished code to these forums after you've completed a project; people more experienced with the language than you will often be able to identify areas which can be improved or simplified.
- Use an editor with syntax highlighting. Perennial favorites such as Vim and Emacs, plus newer editors such as Sublime Text, feature support for most if not all programming languages and are available for all major operating systems. Some languages are often associated with specific IDEs; these are a good idea when learning a new language. These are generally ...
- Eclipse IDE for Java and Android development.
- Xcode for Objective-C and iOS development (on Mac OSX only).
- Visual Studio IDE for C#, C++, VB.NET, F# (on Windows only).
- Working on a real project with real customers and deadlines is a white hot crucible for learning a new programming language. If you really need to learn a language quickly, then consider taking on a new job which requires it. Once you've got the job, you'll have no other choice but to learn it quickly.
- Finally, a tip from The Pragmatic Programmer, Tip #8 "Invest Regularly in Your Knowledge Portfolio":
"Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet."
Saturday, February 2, 2013
How to learn a new programming language
Here's some tips on learning a new programming language. They aren't listed in any specific order. Hopefully you'll gain from this at least one new tip that will help you to become proficient in the next language you learn.
Tuesday, January 15, 2013
Big Ball of Mud Design Pattern
In "Big Ball of Mud", Brian Foote and Joseph Yoder propose that the default (and most common) software architecture in use is the "Big Ball of Mud" pattern and go on to discuss six additional patterns and activities that it gives rise to: "Throwaway Code", "Piecemeal Growth", "Keep it Working", "Shearing Layers", "Sweep it Under the Rug" and "Reconstruction".
Their original article is located here and can be downloaded in PDF form here: Big Ball of Mud by Brian Foote and Joseph Yoder [PDF download]
I have picked out what I think are the highlights of their article ...
Big Ball of Mud ... alias Shantytown or Spaghetti Code
Shantytowns are usually built from common, cheap materials with simple tools and using unskilled labor. The construction and maintenance of the shantytown is labor intensive, and there is little or no labor specialization - each builder must be a jack of all trades. There's no overall planning, or regulation of future growth.
Too many of our software systems are, architecturally, little more than shantytowns. Investment in tools and infrastructure is often inadequate and the tools that are used are primitive. Parts of the system grow unchecked, and the lack of architecture and planning allows problems in one part of the system to erode and pollute adjacent portions. Deadlines loom like monsoons, and architectural elegance seems unattainable.
The time and money to chase perfection are seldom available and there is a survival at all costs attitude, to do what it takes to get the software working and out the door on time. The biggest cost borne by the Big Ball of Mud development is the lack of a decent architecture.
Common features of Big Ball of Mud Code
- Data structures are haphazardly constructed, or non-existent.
- Everything talks to everything else.
- Important state data is global.
- State data is passed around though Byzantine back channels that circumvent the system's original structure.
- Variable and function names are uninformative and misleading.
- Functions use global variables extensively, as well as long lists of poorly defined parameters.
- Functions themselves are lengthy and convoluted, and perform several unrelated tasks.
- Code duplication.
- The flow of control is hard to understand, and difficult to follow.
- The programmer’s intent is next to impossible to discern.
- The code is simply unreadable, and borders on indecipherable.
- The code exhibits the unmistakable signs of patch after patch at the hands of multiple maintainers, each of whom barely understood the consequences of what he or she was doing.
- Did we mention documentation? What documentation?
Some software engineers come to regard life with the Big Ball of Mud as normal and become skilled at learning to navigate these quagmires, and guiding others through them. Over time, this symbiosis between architecture and skills can change the character of the organization itself, as swamp guides become more valuable than architects.
As per Conway's Law, architects depart in futility, while engineers who have mastered the muddy details of the system they have built, prevail. The code becomes a personal fiefdom, since the author care barely understand it anymore, and no one else can come close. Once simple repairs become all day affairs, as the code turns to mud.
Throwaway Code ... alias Quick Hack or Protoduction
While prototyping a system, you're normally unconcerned with how elegant or efficient your code is. You plan that you will only use it to prove a concept and once the prototype is done, the code will be thrown away and written properly. As the time nears to demonstrate the prototype, the temptation to load it with impressive but utterly inefficient realizations of the system’s expected eventual functionality can be hard to resist. Sometimes, this strategy can be a bit too successful. The client, rather than funding the next phase of the project, may slate the prototype itself for release.
This quick-and-dirty coding is often rationalized as being a stopgap measure. More often than not, the time is never found for this follow up work. The code languishes, while the product flourishes. It becomes a protoduction - a prototype that gets used in production.
Once it becomes evident that the throwaway code is going to be around for a while, you can turn your attention to improving its structure, either through an iterative process of Piecemeal Growth, or via a fresh draft, as discussed in the Reconstruction pattern below.
Piecemeal Growth ... alias Refactoring
Successful software attracts a wider audience, which can, in turn, place a broader range of requirements on it.
When designers are faced with a choice between building something elegant from the ground up, or undermining the architecture of the existing system to quickly address a problem, architecture usually loses.
In the software world, we deploy our most skilled, experienced people early in the lifecycle. Later on, maintenance is often relegated to junior staff, and resources can be scarce. The so-called maintenance phase is the part of the lifecycle in which the price of the fiction of master planning is really paid. It is maintenance programmers who are called upon to bear the burden of coping with the ever widening divergence between fixed designs and a continuously changing world.
Piecemeal growth can be undertaken in an opportunistic fashion, starting with the existing, living, breathing system, and working outward, a step at a time, in such a way as to not undermine the system’s viability. You enhance the program as you use it. Massive system-wide changes are avoided - instead, change is broken down into small, manageable chunks.
Keep It Working ... alias Continuous Integration
Businesses become critically dependent on their software and computing infrastructures. There may be times where taking a system down for a major overhaul can be justified, but usually, doing so is fraught with peril. Therefore, do what it takes to maintain the software and keep it going. Keep it working.
This approach can be used for both minor and major modifications. Large new subsystems might be constructed off to the side, perhaps by separate teams, and integrated with the running system in such a way as to minimize disruption.
A development build of each product can be performed at regular intervals, such as daily or even more often via an automated build tool. Another vital factor in ensuring a system's continued vitality is a commitment to continuous testing, which can be integrated into the automated build process.
Shearing Layers
Software never stands still. It is often called upon to bear the brunt of changing requirements, because, being as that it is made of bits, it can change.
Over time, the software's frameworks, abstract classes, and components come to embody what we've learned about the structure of the domains for which they are built. More enduring insights gravitate towards the primary structural elements of these systems and change rarely. Parts which find themselves in flux are spun out into the data, where users can interact with them. Software evolution becomes like a centrifuge stirred by change. The layers that result, over time, can come to a much truer accommodation with the forces that shaped them than any top-down planning could have devised.
Sweeping It Under The Rug
At first glance, a Big Ball of Mud can inspire terror and despair in the hearts of those who would try to tame it. The first step on the road to architectural integrity can be to identify the disordered parts of the system, and isolate them from the rest of it.
Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. If you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring.
Reconstruction ... alias Total Rewrite
One reason to start again might be that the previous system was written by people who are long gone. Doing a rewrite provides new personnel with a way to reestablish contact between the architecture and the implementation. Sometimes the only way to understand a system it is to write it yourself. Doing a fresh draft is a way to overcome neglect. Issues are revisited. A fresh draft adds vigor. You draw back to leap. The quagmire vanishes. The swamp is drained.
When a system becomes a Big Ball of Mud, its relative incomprehensibility may hasten its demise, by making it difficult for it to adapt. It can persist, since it resists change, but cannot evolve, for the same reason. Instead, its inscrutability, even when it is to its short-term benefit, sows the seeds of its ultimate demise.
The above are highlights from the original article, which is located here ... Big Ball of Mud by Brian Foote and Joseph Yoder [PDF download]
Some further reading on Programmers.StackExchange ...
I've inherited 200K lines of spaghetti code — what now?
How to convince my boss that quality is a good thing to have in code?
How to keep a big and complex software product maintainable over the years?
Techniques to re-factor garbage and maintain sanity?
When is code “legacy”?
What is negative code?
Some related books ...
Working Effectively With Legacy Code ... by Michael Feathers [Amazon]
Refactoring: Improving the Design of Existing Code ... by M. Fowler, K. Beck, et al. [Amazon]
Design Patterns: Elements of Reusable Object-Oriented Software ... by the Gang of Four [Amazon]
Patterns of Enterprise Application Architecture ... by Martin Fowler [Amazon]
Domain Driven Design: Tackling Complexity in the Heart of Software ... by Eric Evans [Amazon]
Head First Design Patterns by E. Freeman, E. Freeman, et al. [Amazon]
Thursday, January 3, 2013
The first right answer is the only answer
Reading through David B. Stewart's paper entitled "Twenty-Five Most Common Mistakes with Real-Time Software Development" (PDF, 131 KB).
There's an interesting nugget of advice at number 8, "The first right answer is the only answer";
So he suggests adapting this into a new practice:
There's an interesting nugget of advice at number 8, "The first right answer is the only answer";
Inexperienced programmers are especially susceptible to assuming that the first right answer they obtain is the only answer. Developing software for embedded systems is often frustrating. It could take days to figure out how to set those registers to get the hardware to do what is wanted. At some point, Eureka! It works. Once it works the programmer removes all the debug code, and puts that code into the module for good. Never shall that code ever change again, because it took so long to debug, nobody wants to break it.As David suggests, when dealing with complex, mission critical or concurrent sections of code, that first success is often not the best solution. Weeks later, you might find that its not performing as well as it should be in production and you have to revisit the section of code again looking for a better solution. But the best time to develop a better solution was back when the job was fresh in your mind, when you developed the original solution.
Unfortunately, that first success is often not the best answer for the task at hand. It is definitely an important step, because it is much easier to improve a working system, than to get the system to work in the first place. However, improving the answer once the first answer has been achieved seems to rarely be done, especially for parts of the code that seem to work fine. Indirectly, however, a poor design that stays might have a tremendous effect, like using up too much processor time or memory, or creating an anomaly in the timing of the system if it executes at a high priority.
As a general rule of thumb, always come up with at least two designs for anything. Quite often, the best design is in fact a compromise of other designs. If a developer can only come up with a single good design, then other experts should be consulted with to obtain alternate designs.
So he suggests adapting this into a new practice:
As a general rule of thumb, always come up with at least two designs for anything.There's multiple problems with this advice:
- YAGNI, you ain't gonna need it. Develop an extra solution only if and when you need it; don't create extra work where it might not be needed.
- Premature optimization is the root of all evil. Knowing when you need to optimize a solution further is almost impossible to do at design time, before any benchmarking or code profiling have been done.
- Lastly, if your solution passed the unit test, yet fails further down the line (in production for example), then that suggests there was a problem with your unit test, and not with your solution. If required, you should add some specific concurrency and/or performance testing to your unit test. This will mean you can then optimize your code, while maintaining a TDD approach.
I notice the original article is actually from 1999, which I believe is before test driven development came into prominence. I think this particular piece of advice ("come up with two designs for anything") might have been ok for some projects back then, but would now be considered flawed and certainly not advisable.
Friday, December 28, 2012
Pricing hacks of online retailers
1. Free stuff
When retailers offer products and services for "free" there's usually an ulterior motive. For online shops, "free" provides the initial incentive for buyers to use their web site, and may be effective in retaining customer loyalty. One of the most common uses of "free" is free delivery.Example
UK-based The Book Depository is without doubt using the power of free. The title of their home page is "Free delivery worldwide on all books from The Book Depository". This title shows up in google when searching for "book depository", along with the site's description, which is "The Book Depository offers over 8 million books with free delivery worldwide". The site's byline is "The Book Depository. Free delivery worldwide on all our books". Also in a prominent position on the home page is: "Free worldwide delivery" which links to a page listing all of the countries where they offer free delivery.
2. Per customer limits and the perception of product scarcity
Per customer limits leads buyers to think that a product is scarce, and increases their incentive to buy now. It also entices people to buy more than they originally intended. The legitimate reason for doing this - to avoid products getting sold on the gray market - is hardly ever a real concern. Retailers will also impose a time limit during which the product is available, along with a ceiling on the number of products that can be sold, after which the deal will end.Example
Living Social Deal - Laser Nail Therapy Clinic - 70% Off Laser Nail Fungus Removal for Feet ($450)
This group buying deal shows a "Limit 4 per customer" in the fine print. Most group buying sites have per customer limits for all their deals. In additon to the per customer limit, there is an absolute limit on how many deals can be sold, as well as the deal only being available for a limited amount of time, in this case, 7 days.
3. The 9 factor - prices ending in 9, 99 or 95
Using prices that end in 9, 99, or 95 is called 'Charm Pricing' or 'Psychological Pricing'. We've been culturally conditioned to associate these prices with discounts. And because we read numbers from left to right, we mentally encode a price like $7.99 as $7, especially when we quickly glance at the price. That's called the "left-digit effect" - it's encoded in our minds before we have finished reading all of the digits.Example
Pricing of the Amazon Kindle family of products - $499, $199, $119.
As opposed to $500, $200, $120.
4. Easy math
Most sites, when putting a product on sale, will show you what price it was marked down from. It might be "was $20, now $15". You will rarely see something like, "was $20, now $14.22." The reason is that if the difference is easy to calculate, we tend to think it's a better deal. It's called "computation fluency". Another method employed by many sites is to display the amount of the total saving along with the percentage saved.Example
The Body Shop USA - 50% off Sitewide - After Christmas Sale. Everything is 50% off, making the amount you are saving obvious; you don't need to check any prices or fineprint. Anything you buy on their site will include a significant saving.
5. Sale price font size and color
A common practice in online sales is to display the sale price in a different font size and/or color to the original list price. Typically, the original list price will be shown in strike-though.Example
Amazon uses red text to denote a sale price, shown below the original list price, which is struck out and shown in light gray. However, products which are not on sale and are being sold at the original list price continue to use this red (sale price) font. One theory says that customers will become accustomed to seeing red text as a saving, and will be more inclined to buy, even when the product is actually not on sale.
6. Dynamic Pricing (also known as Time-Based Pricing)
The airline industry is often cited as a dynamic pricing success story. It employs the technique so well that most of the passengers on any given airplane have paid different ticket prices for the same flight. By responding to market fluctuations or large amounts of data gathered from customers - ranging from where they live to what they buy to how much they have spent on past purchases - dynamic pricing allows companies to adjust the prices of identical goods to correspond to a customer’s willingness to pay.Example 1
During Thanksgiving week, The New York Times tracked the price of Dance Central 3, a popular Xbox game, as it dropped on Amazon from $49.96 to $24.99 to $15.Example 2
Coca-Cola tested dynamic pricing in automated vending machines where prices would fluctuate based on the surrounding temperature. Their theory was a soft drink would be worth more when it is hotter outside, and correspondingly, demand for soft drinks would decrease if it were cold outside. It was an unpopular idea and luckily, Coca-Cola abandoned it.Sidenote
Oren Etzioni, a computer science professor at the University of Washington, became incensed when he found out that the traveller sitting next to him on a flight got a much better price for his ticket than he did. Etzioni started collecting online price data from all US airlines, then he created his own formula that could predict when the airlines would raise or lower their prices. His company was bought by Microsoft. And today, when you search for flights on Microsoft's Bing Travel site, you'll see colour coded arrows (called the "price predictor") letting you know you if the price of that ticket is likely to head up or down.
7. Pay what you want
Pay what you want is a pricing system where buyers pay any desired amount for a given product or service, sometimes including paying nothing (i.e. free). Sometimes a minimum (floor) price may be set, or a suggested price may be indicated to the buyer. The buyer can also pay an amount higher than the standard price.It has the benefit of reducing buyer's remorse, which is what happens when you decide afterwards that you've paid too much for a product. It also can result in a viral increase in popularity or visibility for a product when used in highly competitive markets.
It is often used for products which use digital delivery, such as software and music. There is usually no additional cost per download to the seller anyway, since the site's bandwidth would usually be paid for on a capped, monthly basis.
Example 1
Freeware software is often distributed under this model. For example, on the home page of Paint.net is the message "Show your appreciation for Paint.NET and support future development by donating!". Typically, a PayPal donate button is used.
In October 2007, Radiohead released their seventh album, In Rainbows, through the band's website as a digital download and requested fans just pay whatever amount they thought it was worth.Example 3
Introduced during May 2010, the Humble Bundle was a set of six downloadable indie games which were distributed using a pay what you want system (with inclusion of a buyer-controllable charitable contribution).
8. Freemium
Freemium is a business model that works by offering a base product or service free of charge (typically digital offerings such as software, games or online software - software as a service). A premium is then charged for advanced features, functionality, or for related products and services.Example 1
LinkedIn - Basic features of the social network are available for free. For the ability to see the profile of members outside your network, and to access advanced features, you'll need to pay.
Example 2
The New York Times paywall. A limited number of news articles can be read for free per month. To get full access to the site, you'll need to pay.Example 3
Zynga publishes games for Facebook and the major smartphone/tablet app stores. Typically there are in-game actions (e.g. farming) which result in being rewarded with an in-game currency (e.g. loot/coins/points). The in-game currency can then be used to buy additional game features, or to progress further in the game. The in-game currency can be topped up, via a payment to Zynga in real dollars via an in-app-purchase.
9. No dollar signs
A 2009 Cornell University study found that diners in upscale restaurants spent significantly less when menus contained the word "dollars" or the symbol "$". Restaurants use the technique of omitting dollar signs to get you to focus on the product being sold (the food) rather than the price. They may also mention or profile the chef who is cooking the food. Apart from the websites of restaurants, its difficult to see this being used much in general online retailing.Example
Gramercy Tavern, New York City
According to Urbanspoon this is the most popular fine dining restaurant in New York City.There's no dollar signs at all on their website, and their a la carte lunch menu (pdf) doesn't feature any dollar signs either, only numbers.
10. "X for $X"
Buyers will often buy more of a product than they originally intended, if it means they will secure a bargain.Example
Bath and Body Works - 5 for $5 sale
In this case you need to buy 5 products to realise a saving of 33% off the original list price.
Follow @dodgy_coder
Subscribe to posts via RSS
Monday, December 17, 2012
Defensive copy and paste coding
I've got into the habit of doing this check at the end of any
development which has involved some copy & pasting of
existing code. It's been useful for me in picking up issues before
build/test/commit.
It just involves getting a reference count of all occurrences the new variable (or function) compared with the old variable (or function)...
- Select the newly added variable (or function) name
- Right-click to bring up the context menu
- Select the "Find all references" option
The screenshot shown is from Visual Studio, but this feature is also
available in other IDEs and editors, such as Eclipse (via the "References" context menu). Alternatively,
if you're not using an IDE, a simple text search across all files in
your project will be just as useful, assuming that the search string is unique within your project.
Often, you'd expect the reference count should match with the one
you've copy & pasted from (as shown above). If it doesn't match, then by looking
at the references which are different, you should be able to easily
reason about why, and whether its expected or not. If its unexpected, that could mean there's an
error in your code.
So who admits to copy & paste coding - isn't it a sign of bad programming? ... if you can copy & paste big blocks of code, followed by only a few small changes then that's a code smell - you should probably extract the common code into a new function and call it twice. Agreed on that, but there is still many cases where you do have a valid reason to copy existing code. One example is to make fine grained changes to some logic, when it might not be worth the additional complexity of creating a generic function to handle both cases. Or in the case shown above, when I'm copying the declaration of a collection member.
This is a pretty simple and obvious technique, and it might be well known to many already, but I thought I'd mention it anyway. It can also be used outside of the copy & paste case - just mentioning it here because that's the case I've used it more often.
Sunday, November 4, 2012
The slow decline of PCs and the fast rise of Smartphones/Tablets was predicted in 1993
I've just read some predictions for the future of the PC, written in 1993, by Nathan P. Myhrvold, the former Chief Technology Officer at Microsoft.
His memo is amazingly accurate. Note that his term "IHC" (Information Highway Computer) could be roughly equated with today's smartphone or tablet device, connecting to the Internet via WiFi or a cellular network. In his second last paragraph, Myhrvold predicts the winners will be those who "own the software standards on IHCs" which could be roughly equated with today's app stores, such as those on iOS (Apple), Android (Google, Amazon) and Windows 8 (Microsoft).
The only thing you could say he possibly didn't foresee would be the importance of hardware design in the new smartphone and tablet industry. I'd suggest that Apple achieved such a head start on their competition through a combination of both cutting edge hardware design along with their curated app store model for distributing software. Interestingly, Microsoft has only last month entered the hardware game with their new Surface brand tablets for Windows 8 and Windows RT, and also announced a shift to focus on becoming a "Devices and Services" company.
Note: the term "Cairo" used below is the code name for a Microsoft Research project which lasted from 1991 to 1996. It resulted in some features that were eventually rolled into Windows 95, IIS and SQL Server.
The below is an extract from a memo written by Nathan P. Myhrvold, titled "Road Kill on the Information Highway". September 8, 1993. Full Source.
Personal Computers
I've saved the best for last. Our own industry is also doomed, and will be one of the more significant carcasses by the side of the information highway. The basic tasks that PCs are used for today will continue for a long as it makes sense to predict, so it isn't a question of the category disappearing. The question is one of who will continue to satisfy these needs and how?
As a case in point, consider that the fundamental category needs for mainframes and minicomputers also still exists and will continue to do so for a very long time. Despite this, the companies involved are dying and the entire genre is likely to disappear. The reason is that a new breed of machine - the PC - came along which out flanked them. In the early years PCs were not particularly good at what minis and mainframes did, but they were terrific at a whole new set of problems that the traditional computing infrastructure had basically ignored.
Personal productivity applications drove PCs onto millions of desks and created a very vital industry which grew faster - both in business terms and price/performance - than the mainframe and minicomputer markets. The power conferred by this growth made PCs the tail which wagged the dog; free to ignore the standards which existed for mainframes and minis and move off on their own. Over time the exponential growth in computing has finally (after 17 years) given the PC industry the technical ability to beat minis and mainframes in their own domain. Although the early software platforms for PCs had to be extended to fully realize this potential (DOS to Windows to NT to Cairo), it turned out to be far easier to do this than to make mainframe or minicomputer systems address the new needs and applications. Even within the heart of minicomputer and mainframe's domain - giant transaction processing applications etc., the old standards will not be used.
I believe that the same thing will happen again with PCs playing the role of mainframes and minis, and the computing platforms of the information highway taking over the role of the challenger.
The technical needs of computers on the information highway, or IHCs are quite different than for PCs. The killer applications for IHCs in the early years will include video on demand, games, video telephony and other distributed computing tasks on the highway. It is hard to classify this as either higher tech or lower tech than the software for PCs, because the two are quite different. Most IHCs will certainly need to be cheaper than PCs by an order of magnitude and this will inevitably cause them to be less capable in many ways, but some of their requirements are far more advanced.
Another way to say this is that the rich environment of software for PCs is largely irrelevant for IHCs. Windows, NT, System 7 and Cairo do not solve the really important technical problems required for IHC applications, and it is equally likely that the early generations of IHC software won't be great platforms for PC style apps. This isn't surprising because they are driven by an orthogonal set of requirements.
The IHC world will almost certainly grow faster than PCs, both in business terms and in price/performance. The PC industry is already reaching saturation from a business perspective. Technically speaking, the industry is mired in hardware standards (Intel and Motorola CISC processors) with growth rates that are flattening out relative to the state of the art - just as the 360/3090 and VAX architectures did. The Macintosh and Windows computing environments may be able to survive the painful transition to new RISC architectures, but they will lose time and momentum in doing so.
PCs will remain paramount within their domain for many years (we'll still have a computer on every desk) but IHCs will start to penetrate a larger and larger customer base on the strength of its new and unique applications. The power of having the worlds information - and people - on line at any time is too compelling to resist. For a long time people will still have a traditional PC to handle traditional PC tasks - in precisely the same way that they have kept their mainframes and minis for the last 17 years. One day however people will realize that their little IHCs are more powerful and cheaper than PCs - just as we have finally done with mainframes. There will be a challenge for the IHC software folks to write the new systems and applications software necessary to obviate PCs, just as we had to work pretty hard to come up with NT, but this battle will clearly go to the companies who own the software standards on IHCs. The PC world won't have any more say about how this is done than the companies who created MVS or VMS did about our world. Of course, some of the VMS people were involved, but as discussed above it is very hard for organizations to make the transition.
This may sound like a rather dire prediction, but I think that for the most part it is inevitable. The challenge for Microsoft is to be sufficiently involved with the software for the IHC world that we can be a strong player in that market. If we do this then we will be able to exploit a certain degree of synergy between IHCs and PCs - there are some natural areas where there is benefit in having the two in sync. The point made above is that those benefits are not sufficiently strong that they alone will give us a position in the new world. We'll live or die on the strength of the technology and role that we carve out for ourselves in the brave new world of the information highway.
Many thanks to Reddit user erpettie who originally submitted a link to this memo on /r/technology,which is how I came across it.
Follow @dodgy_coder
Subscribe to posts via RSS
Saturday, September 8, 2012
Q&A With Nine Great Programmers
This Q&A article is originally from 2006, published on the blog of Polish developer Jaroslaw "sztywny" Rzeszótko (AKA "Stiff"). That original blog post is no longer online. Gratefully republished with his permission.
On a hot, boring afternoon I got an idea. With the help of publicly accessible e-mail addresses, I asked 10 questions to a bunch of programmers that I consider very interesting people and I respect them for various things they created. Coming out with the questions was a 5 minute job for me - these are things I would ask about if I could speak with them personally for, let’s say, 10 minutes, and I didn’t have time for thinking too much. The last two question don’t have anything to do with programming, this is simply something I like to know about everyone I talk to, lets say that’s my hobby. Not everyone wanted to answer them, and that’s fine. It was the first "interview" I ever made, so I also made some mistakes, which went out as people started answering. But despite this, I learnt a lot of interesting stuff, so it was definitely a valuable experience.
Not everyone responded to my e-mail, not everyone agreed to answer the questions, maybe I will also get some answers after I published this, I didn’t have the patience to wait longer, so new things may appear here over time (Update: Bjarne Stroustrup was added on 03.08.2006).
-- Jaroslaw
Starring
Linus Torvalds - The Linux kernel author.
Dave Thomas - Author of the "Pragmatic Programmer", "Programming Ruby" and other great books about programming. One can read his mainly programming-related thoughts here.
David Heinemeier Hansson - Author of the Rails Framework - the new hot web development framework. He has a blog here.
Steve Yegge - Probably one of the least known guys here, but he also sent most interesting answers. He has a popular blog about programming. He is also the author of a game called "Wyvern".
Peter Norvig - Research Director at Google, a well known Lisper, author of famous (in some circles at least) books about AI. See his homepage here.
Guido Van Rossum - The Python language creator.
Bjarne Stroustrup - C++ language creator, has a homepage here.
James Gosling - The Java language creator.
Tim Bray - One of the XML and Atom specifications author and a blogger too.
Q 1: How did you learn programming? Were any schools of any use? Or maybe you didn’t even bother with ending any schools :) ?
Steve Yegge
I taught myself to program on an HP calculator using their RPN stack language when I was 17 years old. I’d tried to learn programming a few times before that but never really "got" it. The HP 28c and 48g scientific calculators were pretty powerful and had great docs. I wrote a 3D wireframe viewer for the 48g — I got a book on 3D graphics and painstakingly translated an example program in Pascal into the RPN stack language. It was pretty sweet when I got it running. After that I bought a PC and Turbo Pascal, and started studying programming in earnest. I was a decently good programmer by the time I went into the CS program in college.
I went to the University of Washington and got an undergrad degree in CS. It was definitely worthwhile, and I recommend that all programmers should try to get a CS degree if possible.
Linus Torvalds
I didn’t learn programming in school, but mostly on my own reading books and just doing it (initially on a Commodore VIC-20, later on a Sinclair QL).
That said, I think especially University was very useful. Rather than go to an engineering school, I went to Helsinki University, which is pretty theoretical, so there the teaching concentrated not so much on programming (which was just a small part, and which I ended up doing more of "on the side" anyway), but most of the courses tended to be on fundamental concepts and things like complexity analysis. Which can seem boring and even a waste of effort at times, but I think it was useful, and I mostly enjoyed it. And I think I’m probably a better programmer for it.
David Heinemeier Hansson
I learned programming by starting to put together my first web page in HTML. Then I wanted to make some dynamic pieces and picked up first ASP then PHP. After I already knew how to program, I then started on a joint computer science and business administration degree.
Peter Norvig
I took courses in high school and college, but always felt I learned more on my own.
Dave Thomas
During my secondary schooling I took a class in a local technical college on computers. It got me totally hooked: I fell in love with programming, and looked around for colleges offering courses in software. Eventually I went to Imperial College, part of London University. It was only the second year they’d offered a course in software, and it was absolutely marvelous: the staff and students worked together to make the materials better, and everyone learned a lot. The undergraduate course there gave me an incredibly strong background in software development. I stayed on to start a PhD, but got lured away by a startup.
But the overall question is "how did you learn programming?" The real answer to that is "I’m still learning programming." I think any good developer continues to learn throughout their careers. It isn’t just a question of picking up new languages and libraries: good developers also refine their techniques and practices over the years.
Guido Van Rossum
I went to university where they had a big mainframe and there were various computer courses. This was very important for me.
James Gosling
Initially, I was self-taught. I got my first programming job before I went to college. But I’m glad I did. I had a lot of fun. I kept going until I had a PhD.
Bjarne Stroustrup
In university (Aarhus and later Cambridge). The universities taught me much that was useful, incl. most of the bases for my future work. In addition, I learned a fair bit from programming for money - where understanding of real-world problems, correctness, maintainability, on-time delivery, etc. were more pressing than in an educational setting.
Tim Bray
I thought I was going to be a math teacher. The math program at University required a few computer science courses.
Q 2: What do you think is the most important skill every programmer should posses?
Steve Yegge
Written and verbal communication skills. You’ll never make it very far as a programmer in any field unless you can get your ideas across to people effectively. Programmers should read voraciously, practice writing, take writing courses, and even practice at public speaking.
Linus Torvalds
It’s a thing I call "taste".
I tend to judge the people I work with not by how proficient they are: some people can churn out a lot of code, but more by how they react to other peoples code, and then obviously by what their own code looks like, and what approaches they chose. That tells me whether they have "good taste" or not, and the thing is, a person without "good taste" often is not very good at judging other peoples code, but his own code often ends up not being wonderfully good.
But hey, it’s not the only thing. One thing that is very useful, especially in an open source project, is simply the ability to communicate well what you want to do, and how you are going to do it. The ability to explain to others why you do something a certain way is very important, and not everybody has that ability.
That said, in the end there are also the people who just churn out good code. They may not be good at explaining it, and they may not even have great taste, but the code works well. Sometimes you need another person (one that does have that hard-to-define "taste") to maybe massage the code into a form where it’s useful in the bigger picture, but just the ability to write clear code for difficult problems is obviously a fairly fundamental part of any programmer.
David Heinemeier Hansson
A strong sense of value. The ability to ask yourself the question: Is it worth doing what I’m doing right now? So many programmers seem to waste oceans of time on stuff that just doesn’t matter. And not enough on the stuff that does.
Peter Norvig
I don’t think there’s one, but let’s say concentration.
Dave Thomas
Passion.
Guido Van Rossum
Your questions are rather general and hard to answer. :-) I guess being able to cook an egg for breakfast is invaluable.
James Gosling
To be self motivated. To be really good, you have to be in love with what you do.
Bjarne Stroustrup
The ability to think clearly: A programmer has to understand problems and express solutions.
Tim Bray
Ability to prefer evidence to intuition.
Q 3: Do you think mathematics and/or physics are an important skill for a programmer? Why?
Steve Yegge
There is a large branch of mathematics that’s very important for programmers called "discrete math" or "concrete math". It includes disciplines such as probability, combinatorics, graph theory, induction proofs, and other useful tools. I would encourage all programmers to study discrete mathematics to whatever extent they can. Even a little is better than none at all.
As for more traditional math, well, I don’t use it as often, but it comes in very handy when I need it. For instance, I’ve only used calculus once in the past year as part of my job. I had to estimate loads for the peak traffic hour of the day for a service whose load "follows the sun" in an approximate sine curve. The simplest way to make the estimate was to integrate over 1/24th of the curve at a specific time. If I hadn’t known calculus, I would not have known how to make a reasonably accurate estimate.
When I was writing my game, Wyvern, having a solid working knowledge of basic planar geometry was incredibly helpful. And it’s quite common to use algebra and linear algebra on a regular basis. But I rarely use trigonometry or differential equations on the job, and not much calculus either.
I’d say my basic math foundation has made me maybe 5% to 10% better as a programmer. If I knew a lot more math, I’d undoubtedly be a much better programmer than I am today, so I study and practice math several hours a week.
I love physics and I have an ongoing, lifelong quest to try to understand the underpinnings of quantum mechanics. But I’ve never personally found any physics very useful towards my job as a programmer. That would, of course, be diffferent if I were doing something in a physics domain, such as 3D game programming, or certain types of simulation.
Linus Torvalds
I personally think a fairly strong math background is a good thing. I’m not as sure about the physics side, but I’m convinced that understanding math and having a good background in it helps you to be a better programmer. If only because the mental models are similar - you can build up any kind of set of rules you want, but it should be self-consistent.
David Heinemeier Hansson
Not at all. At least not for the kind of business programming needed for web applications. I consider it much more important that someone is a good writer.
Peter Norvig
Yes. Many ideas are inherently mathematical: induction, recursion, logic, etc.
Dave Thomas
Maybe. But, to be honest, I haven’t seen much of a correlation either way between these types of discipline and good software developers.
However, I have seen a strong correlation between people who have some music in their background and programming skills. I have no idea why, but I suspect that some of the areas of the brain that make someone musical also make them good at software development.
Guido Van Rossum
Math, yes (for some parts; I don’t care for differential equations, but algebra and logic are important). Physics, I don’t think so except it’s always useful to be interested in many different things.
James Gosling
Yes! They teach you logic & deduction... To have an analytical eye. And there’s no replacement for mathematics when it comes to analyzing algorithms.
Bjarne Stroustrup
Depends on the programmer and the programming tasks. Some forms of math are frequently useful; physics less often so, but then learning physics is one of the best ways of learning practical math.
Tim Bray
In my case, I’ve almost never used my university-level math to support my programming.
Q 4: What do you think will be the next big thing in computer programming? X-oriented programming, y language, quantum computers, what?
Steve Yegge
I think web application programming is gradually going to become the most important client-side programming out there. I think it will mostly obsolete all other client-side toolkits: GTK, Java Swing/SWT, Qt, and of course all the platform-specific ones like Cocoa and Win32/MFC/etc.
It’s not going to happen overnight. It’s very slowly been going that direction for ten years, and it could well be another ten years before web apps "win". The tools, languages, APIs, protocols, and browser technology will all have to improve far beyond what you can accomplish with them today. But each year they get a little closer, and I’ve finally decided to switch all my own app development over to browser-based programming from now on.
Microsoft and Apple definitely don’t want this to happen, so a necessary first step will be for an open-source browser such as Firefox to achieve a dominant market position, which will in turn require some sort of Firefox-only killer app. (A killer app would be something like iTunes, something that everyone in the world wants to use, badly enough to download Firefox for it.)
Linus Torvalds
I don’t think we’ll see a "big jump". We’ve seen a lot of tools to help make all the everyday drudgery easier - with high-level languages and perhaps the integration of simple databases into the language being the main ones. But most of the buzz-words have been of pretty limited use.
For example, I personally believe that "Visual Basic" did more for programming than "Object-Oriented Languages" did. Yet people laugh at VB and say it’s a bad language, and they’ve been talking about OO languages for decades.
And no, Visual Basic wasn’t a great language, but I think the easy DB interfaces in VB were fundmantally more important than object orientation is, for example.
So I think there will be a lot of incremental improvements, and the hardware improvements will make programming easier, but I don’t expect any huge productivity help or revolutions in how people do things.
At least not until you start approaching real AI, and I don’t think real AI is going to be anything you will ever "program".
David Heinemeier Hansson
I try not to predict the future. I’m not a big believer in fortune telling. The best way to predict the future is to implement it.
Peter Norvig
Large-scale distributed processing.
Dave Thomas
The next big thing in computer programming will be eclipsed by the next–next big thing in programming, and so on, and so on. I’m kinda tired of the endless search for the big things, because while doing it people tend to forget about the real issues: getting the fundamentals right. We need to get a whole lot better at talking with our customers, focussing on delivering value, and taking pride in what we do. A developer who can do these things can deliver great software with any tool set, and won’t need to worry about tracking the fads and fashions.
Guido Van Rossum
Sorry, I’m not much of a crystal ball person. I predicted CGI about 5 years after it had been invented. :-)
James Gosling
The two issues I’m most concerned about now are coping with parallelism and complexity.
Bjarne Stroustrup
I don’t know, and I don’t like to guess.
Tim Bray
No idea.
Q 5: If you had three months to learn one relatively new technology, which one would you choose?
Steve Yegge
I do happen to have 3 months (part-time), and I’m spending it learning Dojo (http://dojotoolkit.org) and advanced AJAX and DHTML. I’m learning it by writing a fairly ambitious web application. Dojo’s really cool, and I’m sure it will only improve with time.
Linus Torvalds
Hmm. I’d really love to do FPGA’s, but I’ve always been too busy to really sit down and start learning. I love the notion of playing with hardware: it’s obviously one of the reasons I ended up doing operating systems, since that (along with compilers) is about as close as you can get to playing with the hardware, without actually designing or building it yourself.
David Heinemeier Hansson
Cocoa programming for the Mac.
Peter Norvig
I’d like to know Javascript better. Also flash.
Dave Thomas
If "new" means "new to Dave Thomas" then I think I’d take intensive piano lessons.
If "new" means technology stuff, then I guess I’d choose technologies related to accessibility for people with disabilities.
Guido Van Rossum
Snowboarding.
James Gosling
For fun, I’d catch up on the latest in 3D rendering. I’d probably write a photon-map renderer.
Bjarne Stroustrup
There are very few things of any importance that you can learn in three month. I think you must be thinking of training in a well established field.
Tim Bray
Security, encryption, digital signatures, identity, etc. It’s a big problem for me that I’ve never learned this stuff.
Q 6: What do you think makes some programmers 10 or 100 times more productive than others?
Steve Yegge
I think if you pause to consider why not all atheletes are equally good, you’ll have your answer(s). Thomas Edison has a relevant quote about genius that might also provide you some clues.
Linus Torvalds
I really have no idea. I think some people are just better able to concentrate on the things that matter, and I think a lot of it is just doing it. Most of the really good programmers I know started doing it fairly young.
David Heinemeier Hansson
The ability to restate hard problems as easy ones.
Peter Norvig
The ability to fit the whole problem into their heads at one time.
Dave Thomas
They care about what they do.
Guido Van Rossum
Genetically different brain structure.
James Gosling
They think about what they do. They don’t rush in and slap things together. They have a holistic picture of what is to be built.
Bjarne Stroustrup
First a general lack of professionalism and adequate training. that sets the base level too low. Secondly, some people have a combination of "smarts" (ability to think clearly and get to the heart of things), experience, and knowledge of tools. Programming leaves more scope for that because it is a combination of theory and practice - neither of which is much use without domain knowledge.
Tim Bray
The surprising variability of the human mind.
Q 7: What are your favourite tools (operating system, programming/scripting language, text editor, version control system, shell, database engine, other tools you can’t live without) and why do you like them more than others?
Steve Yegge
OS: Unix! I use linux, cygwin, and darwin all about equally often now. You just can’t beat it for productivity tools. Every programmer should learn how to use every tool in /bin and /usr/bin.
Scripting language: Ruby. I’m proficient with just about every major scripting language out there: Perl, Python, Tcl, Lua, Awk, Bash, and others I’m forgetting. But I’m really lazy, and Ruby’s by far the easiest, so it’s a match made in heaven.
Programming language: I don’t have a favorite; I think they all suck. I tend to prefer Java because it’s a strong, portable platform with good tools and good libraries. But the Java language will evolve or die; it’s not good enough as-is to hold the lead indefinitely.
Text editor: Emacs, because it’s the best thing out there today.
Version control: SVN. Perforce is better, but it’s very expensive.
Shell: Bash, because I’m too lazy to learn a better one.
Database engine: MySQL, of course. Nothing else comes close.
Others: I find the GIMP invaluable, and also maddeningly unintuitive. I’ve been using it for years and can still barely do anything with it. But I couldn’t live without it, ironically enough.
Firefox is becoming an increasingly critical part of my tools lineup. I feel suffocated when I’m forced to use IE or Safari.
Note that all these tools (Unix, Emacs, Firefox, GIMP, MySQL, Bash, SVN, Perforce) have something in common: they’re extensible; i.e., they all have programming APIs. Great programmers learn how to program their tools, not just use them.
Linus Torvalds
I actually don’t end up having that many tools I work with, and for the many of them I have spent some time of my own to just make them work for me. The OS part is clearly the biggest one, but I’ve obviously also written my own version control system (git), and the text editor I use (micro-emacs) I’ve ended up customizing and extending upon too.
Other than those three parts, the only thing I care deeply about is my email reader. I use "pine" - not because it’s necessarily the greatest email reader ever, but because I’m used to it, and it does what I need it to do with a minimum of fuss.
David Heinemeier Hansson
OS X, TextMate, Ruby, Subversion, MySQL. That’s the combo currently keeping me happy. I like tools that exhibit good taste and a focus on the stuff that matters.
Peter Norvig
I dislike all three major OS - Windows, Mac, Linux. I like Python and Lisp. Emacs.
Dave Thomas
I switched to Macs a couple of years ago after being a Linux person for more than 10 years. The tools are not necessarily better, but they don’t have to be sharpened or maintained as often, which lets be concentrate on just using them.
I'm not a great believer in single tools: I tend to switch around quite frequently just so I can get experience with as many tools as possible. Right now I’m using OSX, Emacs, TextMate, Rails, Ruby, SVN, CVS, Rake, make, xsltproc, TeX, MySQL, Postgres, and a whole lot of small productivity aids. Who knows what I’ll be using next year.
Guido Van Rossum
Unix/Linux, Python, vi+emacs, Firefox.
James Gosling
These days I live in NetBeans. It does everything I want, very cleanly simply and efficiently. It’s the nicest environment I’ve ever lived in.
Bjarne Stroustrup
Unix, sam (a very simple text editor), and a good C++ compiler, of course.
Tim Bray
I like Unix-like operating systems, dynamic languages like Python and Ruby and statically-typed languages like Java (in particular the Java APIs), Emacs, whatever, bash, whatever, NetBeans.
Q 8: What is your favourite book related to computer programming?
Steve Yegge
Man, that’s a tough one. Maybe "Gödel, Escher, Bach: an Eternal Golden Braid" (Hofstadter)? Although it’s not strictly about programming. If you specifically mean "favorite book about programming", then maybe SICP (mitpress.mit.edu).
Linus Torvalds
Heh. When I read these days, I tend to either read fiction, or non-computer-related stuff (oldie but goodie: "The Selfish Gene" by Richard Dawkins).
When it comes to programming, the only real programming book that comes to mind is actually the classic Kernighan & Ritchie "The C Programming Language" book, because it’s such an incredibly useful book while being so very readable and short. Considering that you can basically learn one of the most important programming languages of our times from it, the fact that it’s thin and readable is just a wonder.
That said, many other books I enjoyed a lot were not about programming per se, but about computer architecture and hardware. There’s obviously Patterson & Hennessy’s computer architecture book, but for me personally perhaps even more Crawford & Gelsinger’s "Programming the 80386?, which was what I used when I started with Linux.
For similar reasons, I have a soft spot for Andrew Tanenbaum’s "Operating Systems: Design and Implementation".
David Heinemeier Hansson
I like Extreme Programming Explained for its rejection of common thinking about programming practices and Patterns of Enterprise Application Architecture for striking the right balance of abstract and concrete.
Peter Norvig
Structure and Interpretation of Computer Programs
Dave Thomas
It depends on what you mean by "favorite." Probably the best written book I’ve read in the area is IBM’s "IBM/360 Principles of Operation."
Guido Van Rossum
Neil Stephenson’s Quicksilver.
James Gosling
Programming Pearls by Jon Bentley.
Bjarne Stroustrup
K&R.
Tim Bray
Bentley’s Programming Pearls
Q 9: What is Your favourite book NOT related to computer programming?
Steve Yegge
Just one book? You’re asking for the impossible. There are too many great books out there to choose just one.
My favorite books that I’ve read this month are "Stardust" (Neil Gaiman) and "The Mind’s I" (Hofstadter/Dennet).
My favorite writers are Kurt Vonnegut, Jr. and Jack Vance.
Linus Torvalds
Well, I already mentioned the Selfish Gene by Dawkins. On the fictional side, there’s just a lot of books I’ve read and enjoyed, but few I’d say were my "favourite" one. I tend to not often re-read the books, and the selection would change over time. It’s mostly science fiction and fantasy, eg "Stranger in a Strange Land" by Heinlein was my favourite one as a teenager, but it’s a bit less clear-cut for me these days..
David Heinemeier Hansson
1984, George Orwell.
Guido Van Rossum
Neil Stephenson’s Quicksilver.
James Gosling
Guns, Germs & Steel by Jared Diamond
Bjarne Stroustrup
It changes over time. Currently O’Brian’s Aubrey/Maturin series.
Tim Bray
One Day in the Life of Ivan Denisovich
Q 10: What are your favourite music bands/performers/composers?
Steve Yegge
Favourite genres: classical, anime soundtracks, video-game music
Favourite composers: Rachmaninoff, Chopin, Bach
Favourite performers: David Russell (classical guitar), Sviatoslav Richter (piano)
Favourite anime OSTs: Last Exile, Haibane Renmei
Linus Torvalds
I'm actually not very much into music, but when I listen to it, I tend to listen to various classic-rockish things, ranging from Pink Floyd to the Beatles to Queen and The Who.
David Heinemeier Hansson
I like a lot of genres. Beth Orton, Aimee Mann, Jewel, Lauryn Hill. Actually, all those examples would fit under Girls with Guitars ;).
Guido Van Rossum
Philip Glass.
James Gosling
I tend to like folk musicians: Christine Lavin, Woody Guthrie, Pete Seeger...
Bjarne Stroustrup
Band: The Dixie Chicks. Composer: Beethoven.
Tim Bray
Read my blog.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Postscript
How I found this: I was reading this post by Jeff Atwood, titled "Linus Torvalds, Visual Basic Fan" where the source article he linked to was: "STIFF ASKS, GREAT PROGRAMMERS ANSWER". But that link was dead, and doing a search didn't find any trace of it anywhere on the net. So I resorted to an archive.org search and sure enough, up popped this incredible blog post by Jaroslaw Rzeszótko.
Due to it no longer being available on the net, I thought it should reposted again so others can enjoy reading it. I requested permission from the original author to do this, and he happily obliged - thanks again Jaroslaw!
Follow @dodgy_coder on Twitter
Read a Chinese translation of this blog post << Thanks to the guys at CoolShell.cn for this!
Read a Turkish translation of this blog post << Thanks to Seval for this!
Subscribe to:
Posts (Atom)