Every tutorial I've read for the last 30 years starts with the infamous 'Hello World' example. This could be one of the reasons we write crappy software.
"Hello World" is the first program we make in every language.
We can measure the complexity of language by counting the lines it takes to produce the desired output.
We can also time how much does it take to a newbie to figure out the solution (this is also known as Time to hello world" (TTHW)).
These two metrics are uncorrelated to productivity.
Many sites compile different Hello World programs in a lot of languages.
The Problems
The Hello Word example has a lot of problems introduced early when developers are making their first steps in programming.
- It uses globals in many languages. Global functions are a code smell. Teaching them to newcomers in theirs first example is conflicting.
Hello World yields side effects (on the console, file system, printers, etc.).
We write the code and we cannot test if it is working. We can manually check for the output but our software cannot assert it our outcome was right.
If our HelloWorld works today we cannot ensure it will keep working tomorrow.
The Solution
All developers should start with:
function testFalse()
{
Assert(1==2)
}
Advantages
- We start with a broken test. This is the first step to start developing software according to test driven development technique.
How to Squeeze Test Driven Development on Legacy Systems
Maxi Contieri ・ Nov 26 '20
We introduce developers to a Continuous Integration/Continuous Development pipeline with their very first instruction.
We use no Globals or side effects.
We show the importance of early testing.
We stress how important is to have working code and automated tests from the very first second.
Conclusion
We need to stop writing HelloWord as the first sentence of a language.
Next time you come across a new fancy language, please start with a broken test.
Top comments (7)
While I generally agree with your point, I find writing a very simple (shortest valid) program helps when setting up tooling for a new language ecosystem, sometimes it doesn't 'just work' after the bloatware/setup wizard has done it's worst to your file system!
There is always '99 bottles' for a little variety ;)
rosettacode.org/wiki/99_bottles_of...
Thank you for the article, I've enjoyed it. And I have couple of thoughts on the subject, that I'd like to share.
"Hello world" is more of a teaser than an actual introduction. Something to make you want to read "The book of {language}", which explains the pros and cons and the process in depth.
A generic "Hello world" example sets a simple task and gives you an immediate feedback, giving you a taste of the flow.
One more thing to add is that globals, monkey patching and side effects are not to be demonized. Instead we should promote right use for the right tool, expanding the possibilities and creativity of the newcomers.
Why do we write crappy code? Because we're tired, lazy or there was no time for the tests (hint: there's always time for the tests)
Interesting. I agree with you
Completely agree, a thought I've been pondering put into words
But there's the issue of scaring people off, over more in certain language that are more convoluted to start with...
Definitely something that can be thought from day one in simpler language like Python for say.
Maybe we can do this:
Yes. I try to write my articles in pseudo code. So everyone understand it
Of course i could have chosen any real language. But i write for humans, not for compilers.
If you see my code smell series their code is written in 12 different languages. I deliberately choose not to use a real one on this article.
But i agree maybe checking strings will be better than checking numbers
From a conceptual point of view, it's irrelevant if we are comparing numbers/ints or strings. It's the same thing.